Free tool

MCP 2025-06-18 Compliance Check

See which protocol revision your server actually negotiates, and whether a client expecting 2025-06-18 will work with it.

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 server URL

Any deployed MCP endpoint.

play_circle
We negotiate a real handshake

The initialize exchange reports the revision your server settles on, which is not always the one you built against.

checklist
Compare against 2025-06-18

Along with the transport, capabilities and full tool list.

Which revision does your server actually speak?

MCP revisions are dated rather than numbered, and client and server negotiate a shared one during the initialize handshake. That means the revision that matters is not the one in your dependency manifest — it is the one the two ends agree on at runtime, which this check reports.

Servers built against a newer SDK than they were tested with, or pinned to an old one by a transitive dependency, routinely negotiate something other than what their author expects.

What actually breaks between revisions

Rarely the core: tools, resources and prompts have been stable throughout. The differences that bite are in capability negotiation, authorization and — most of all — transports. The move to streamable HTTP accompanied the newer revisions, and a transport mismatch causes far more real-world failures than a revision mismatch does. If a client cannot see your server, check the transport before the revision.

Which one to target

Whatever your SDK currently supports, kept reasonably current. Chasing revisions ahead of your SDK gains nothing. Sitting several behind is how a server gradually stops working with newer clients, and because negotiation degrades quietly rather than failing loudly, it is usually noticed as "some people say it does not work" rather than as an outage.

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

One of the dated revisions of the Model Context Protocol. Clients and servers negotiate a shared revision during initialize, so what matters is not which one you built against but which one the two ends actually agree on.

Run the check above — the negotiated version is reported in the result. It comes from your server's initialize response, so it is what a real client would see rather than what your dependency manifest claims.

Not usually by itself; negotiation exists to handle it. Problems come from features that only exist in one revision, and from transports — a client expecting streamable HTTP against a server that only speaks the older SSE transport fails whatever revision they agree on.

Target what your SDK supports and keep it current. Chasing revisions ahead of your SDK gains nothing, but sitting several behind means newer clients gradually stop working with you in ways that are hard to diagnose.

That the handshake completes at all, which transport answered, and that the tool list is what you expect. The MCP Server Tester covers those as a pass/fail checklist.

More free MCP tools