Free tool

MCP SSE Tester

Check whether your MCP server actually answers on the HTTP+SSE transport — and whether that is still enough for the clients you care about.

Works with streamable HTTP and SSE endpoints, for example https://mcp.example.com/mcp
This server needs authentication
Used for this one request and never stored.

Working is not the same as sellable

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.

How it works

link
Paste your SSE endpoint

Usually the path ending in /sse, though servers mount it in various places.

play_circle
We connect the way a client does

Streamable HTTP first, then SSE — and the result tells you which one actually answered.

checklist
See what the transport supports

Handshake, protocol version and the full tool list, plus the raw request log.

What HTTP+SSE actually is

The original HTTP transport for MCP. The client opens a long-lived Server-Sent Events stream to receive server-to-client messages, and POSTs its own messages to a separate endpoint. Two endpoints, one direction each. It works, and it is awkward behind proxies and load balancers in exactly the ways you would expect.

Paste your endpoint above and this connects the way a real client does — streamable HTTP first, then SSE — and tells you which one actually answered.

Why an SSE-only server can vanish from a client

This is the failure worth understanding, because it produces no error message. Current clients try streamable HTTP first, and not all of them fall back. A server that only speaks SSE is then simply not there as far as that client is concerned — it reports an empty server or nothing at all, rather than a transport failure. Nothing in your logs will look wrong, because nothing reached you.

If your server used to appear in a client and stopped after an update, this is the first thing to check.

Should you migrate?

If you control the server, yes. Streamable HTTP is one endpoint instead of two, reconnects cleanly, and is what the ecosystem has settled on. Support both while you have users on older clients, then drop SSE. If you do not control the server, this page at least tells you which transport you are dealing with before you start debugging your client.

Related tools

The transport is not the hard part

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.

Frequently asked questions

The original HTTP transport for MCP: the client opens a long-lived Server-Sent Events stream for server-to-client messages and POSTs its own messages to a separate endpoint. It has been superseded by streamable HTTP, which does both over one endpoint.

It is superseded rather than removed. Plenty of servers still speak only SSE and plenty of clients still support it — but newer clients try streamable HTTP first and some no longer fall back, which is why an SSE-only server can silently disappear from a client that used to see it.

Almost always fallback behaviour. A client that tries streamable HTTP and does not fall back will find nothing at an SSE-only endpoint, and it will usually report that as an empty server rather than as a transport error.

If you control the server, yes — it is one endpoint instead of two, it survives reconnects better, and it is what current clients expect. Support both during the transition if you have existing users.

This tester reports it explicitly in the result summary, along with the negotiated protocol version. The request log below shows the actual calls if you need to see why one failed.

More free MCP tools