Check that your MCP server actually works. Paste the URL and get a pass/fail report on the connection, the handshake, the transport and the tools it advertises.
A green checklist proves your server works. It does not show a customer what it does. Point MCP Showcase at the same URL and get a live playground they can try in a browser.
A deployed endpoint, not a local process. Add a bearer token if the server needs one — it is used once and never stored.
A genuine MCP handshake, streamable HTTP first and SSE as a fallback — exactly what Claude, Cursor or VS Code will do.
A check-by-check report plus the raw request and response log, so a failure points at the step that broke rather than at a generic error.
Paste a Model Context Protocol endpoint above and this MCP server tester runs a real client
against it — the same sequence Claude Desktop, Cursor or VS Code run when they connect. It opens
the connection, performs the initialize handshake, negotiates a protocol version and
calls tools/list, then reports each step separately as a pass or a failure.
That separation is the point. A client that cannot see your server gives you one unhelpful error; this gives you seven answers, so you find out whether the endpoint is unreachable, the handshake is failing, the transport is mismatched or the tool list is simply empty.
initialize completes and a protocol version is
negotiated. A server that accepts TCP but fails here is running, but is not speaking MCP.
This is the most common reason people reach for a hosted tester, and it is almost always one of
three things. The endpoint is not publicly reachable — it is bound to localhost, or behind a
firewall, or the deploy has not finished. The deployed path differs from the local one: MCP
servers are variously mounted at /mcp, /sse or the root, and the path
that worked with mcp dev is not always the one your host exposes. Or the deployed
build is simply older than the one on your machine.
The request and response log under the result distinguishes all three. A connection refused looks nothing like a 404, and a 401 tells you the server is fine and wants a token.
No tool is ever called. This checks the layer underneath — connection, handshake, advertisement — which has to work before an agent can call anything at all. It will not tell you whether a tool validates its input or returns the right answer. If you want to see the tool schemas themselves, use the MCP Inspector; if you want to know whether the server is safe to point an agent at, run the security scanner.
mcp dev before you deploy.A green checklist tells you the plumbing works. It tells a prospective customer nothing at all — they cannot read a handshake, and a list of tool names is not a demonstration. That is what MCP Showcase is for: point it at the same URL and it produces a shareable playground page where anyone can try the tools in a browser, with generated documentation for each one and copy-paste setup for their own client.