SiftwrightIs your MCP server ready for agents?
Paste a remote MCP server URL. We connect the way a client does, then report the protocol version, session model, CORS, auth challenge and how clearly each tool is described, plus what the tool list costs in context tokens.
What the checker looks at
Only what any client can see from outside, using read-only calls. It never runs one of your tools.
Handshake
Does initialize succeed, which protocol revision comes back, and which capabilities (tools, resources, prompts) are declared.
Stateless or sessions
Whether the server issues an Mcp-Session-Id. Stateless servers are simpler to host on serverless platforms.
Auth challenge
For 401 replies: the WWW-Authenticate header and whether it points clients at OAuth protected-resource metadata.
Tool quality
Missing or very short descriptions, parameters without descriptions, invalid names, duplicates and schemas that are not objects.
Context cost
An estimate of the tokens your tool definitions occupy when a client loads them all, since a big catalogue crowds out working context.
Browser access
Whether CORS headers are present, which decides if browser-based clients can call the server directly.
Check it yourself with curl
The same first call, so you can compare with what the checker reports:
curl -s https://your-server.example/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'Want to connect agents to web data?
Siftwright runs its own hosted MCP server with tools for YouTube transcripts, screenshots, Google News, contact details, tech stacks, job listings and more.
Frequently asked questions
What does the MCP server checker do?
It sends the same two JSON-RPC requests a client sends when it connects: initialize, then tools/list, over HTTPS POST. It reports whether the server answers, which protocol revision and capabilities it declares, whether it is stateless or session based, whether browsers can reach it (CORS), and how its tools look to a model: names, descriptions, input schemas and the approximate token cost of the whole catalogue.
Which servers can it check?
Remote servers using the Streamable HTTP transport at a public https URL, such as https://example.org/mcp. Local stdio servers, legacy SSE-only servers, servers on custom ports, IP addresses and internal hostnames are not supported. Replies as plain JSON or as a text/event-stream are both understood. Because the checker runs on siftwright.com it cannot fetch siftwright.com itself.
My server needs an API key or OAuth. Will it work?
The checker does not take credentials, so it stops at the sign-in step. For a 401 it reports the WWW-Authenticate challenge and whether it carries resource_metadata, which the MCP authorisation spec uses so clients can discover how to sign in. To see the tool list of a protected server, test a copy without auth or read the tools in your own client.
What is the token estimate?
A rough count (about 4 characters per token) of every tool's name, description and input schema as returned by tools/list. Clients that put all tool definitions in the model's context pay this on every conversation, so a large catalogue leaves less room for the work itself. It is an estimate, not a tokenizer measurement, and your client may load tools lazily.
Does it call any of my tools?
No. It only calls initialize, a notifications/initialized notice and tools/list, which change nothing on a correctly built server. It never calls a tool.
What do you keep?
Nothing is stored beyond a 10-minute cache of the result keyed by URL. About 30 checks per day per network are allowed. Requests go out with the user agent SiftwrightMCPChecker/1.0.
Give your agents web data
One key, nine tools over REST or MCP. Plans from $29/month; failed requests are free.