Check whether your MCP server answers on streamable HTTP, the transport current clients try first and some no longer fall back from.
Once the transport is right, the remaining problem is that nobody can see what your server does. MCP Showcase turns the same URL into a live playground with documentation for every tool.
Usually the path ending in /mcp for a streamable HTTP server.
The same initialize call Claude, Cursor and VS Code make, on the same transport.
Protocol version, transport, server identity and the full tool list.
Streamable HTTP replaced the older two-endpoint HTTP+SSE design: one endpoint handles both directions, upgrading to a stream only when the server needs to push. That makes it far less awkward to deploy behind proxies, CDNs and load balancers, and it is what Claude, Cursor and VS Code attempt before anything else.
Paste your endpoint above and this runs the same initialize handshake they do, then reports which transport answered and what was negotiated.
That is worth knowing, and this tester reports it explicitly rather than quietly succeeding. An SSE-only server still works with many clients — but newer ones increasingly do not fall back, so it can be invisible to a client that supports MCP perfectly well. The symptom is an empty server, not an error, which is what makes it slow to diagnose.
Then the transport is fine and the problem is above it. The usual cause is authentication: a
server that returns 401 to an unauthenticated request is working correctly and
telling you it needs a token. The request log under the result shows exactly that. The
auth checker covers the case in more detail.
Once a client can reach your server, the remaining problem is that nobody can tell what it does. A tool list is not a demonstration, and a prospect will not install a client to find out. MCP Showcase points at the same URL and produces a live playground with generated documentation for every tool, so evaluating your server takes a click.