Is your MCP server ready for 2026-07-28?
MCP conformance · revision 2026-07-28
Is your MCP server actually ready for the stateless revision?
Test the server you actually run — not the SDK version you installed. One command probes real protocol behaviour and reports what fails, what to change, and whether the fix belongs to your code or your SDK.
npx mcp-stateless --stdio "node dist/server.js"No install. No telemetry. No tool execution. Point it at a running server.
- Your running server
- MCP Stateless Check
- 21 rules
- READY / NOT READY
$ npx mcp-stateless --stdio "node server.js"
mcp-stateless — checking against MCP 2026-07-28
target: node server.js (stdio)
Breaking (7)
× MCP001 server/discover is not implemented (SDK)
found server/discover returned JSON-RPC error -32601: Method not found.
expected Servers MUST implement server/discover, advertising supported
protocol versions, capabilities and identity.
fix Add a server/discover handler returning { supportedVersions,
capabilities }. Current SDKs do this for you once upgraded.
spec modelcontextprotocol.io/specification/2026-07-28/basic/lifecycle
× MCP002 Server still accepts the removed initialize method (SDK)
× MCP004 Results are missing the required resultType field (SDK)
× MCP005 List results are missing the required ttlMs field (SDK)
× MCP005 List results are missing a valid cacheScope (SDK)
× MCP006 The removed ping method is still implemented (SDK)
× MCP009 subscriptions/listen is missing despite advertised listChanged (SDK)
Deprecations and advisories (1)
! MCP018 Results do not identify the server via _meta serverInfo (SDK)
NOT READY — 7 breaking issues across 14 checks.
7 of those are protocol plumbing owned by your MCP SDK — upgrading to a
release that targets 2026-07-28 resolves them with no change to your code.
None require a change to your own code.
Finished in 281ms.
The problem
Your SDK version is not your server's behaviour.
A dependency bump compiles. A changelog says the release targets the new revision. Neither tells you what your server puts on the wire — whether a handler you never wrote is still registered, whether a field the specification now requires is actually present in your results.
So this does not read your code. It starts your server, holds a real protocol conversation with it, and reports what came back. The subject is the server you actually run, not the version number you installed.
How it works · five steps, no configuration
A conversation, then a verdict.
The sequence is fixed and the same every run, which is what makes two runs comparable. It never calls one of your tools — tools have side effects, and a conformance check that books a meeting to find out whether booking works is not a check anyone can run against production.
- 01ConnectStart your server over stdio, or point at its Streamable HTTP endpoint.
--stdio "node dist/server.js" - 02ProbeSend a fixed, ordered set of protocol requests. Never one of your tools.
server/discover → tools/list → initialize - 03ObserveRecord every response, header and error code exactly as it came back.
18 exchanges, kept verbatim - 04EvaluateRun each rule against that one shared transcript. No rule re-probes.
21 rules · independent · id order - 05ExplainReport what was found, what the revision requires, and the concrete fix.
found / expected / fix / spec
Who fixes it
Eight findings. Zero of them yours.
You never wrote a ping handler — your SDK registered one. So every rule declares who owns the fix, and the verdict splits on that line. This is the run from the tab above, itemised.
8 findings8 SDK-owned0 application-owned
One dependency bump. That is the whole remediation for this server. Five of the twenty-one rules do land on your code or configuration — MCP013, MCP015, MCP017, MCP019 and MCP020 — and this server tripped none of them. Knowing which column a finding falls in is worth more than the list above it.
21 rules · 15 breaking · 6 advisory
Every finding cites the change it enforces.
No heuristics and no opinions. Each rule maps to a named entry in the changelog, reports the JSON-RPC exchange behind it, and says who has to act.
MCP001server/discover not implementedSDK upgradeMCP004Results missing required resultTypeSDK upgradeMCP011Resource-not-found still returns -32002SDK upgradeMCP013Rejects the _meta protocol envelopeyour codeMCP015Declares deprecated Roots / Sampling / Loggingyour codeMCP017tools/list ordering not deterministicyour codeWhat changed · 6 removed, 6 added
The largest breaking change in the protocol's history.
Revision 2026-07-28 made MCP stateless. Every server has to migrate, on a twelve-month deprecation clock, and the specification shipped no tooling to tell an author where their server stands.
Removed
- initialize handshake
- Mcp-Session-Id and sessions
- ping, logging/setLevel
- resources/subscribe
- Server-initiated requests
- SSE stream resumability
Added
- server/discover (mandatory)
- Per-request _meta envelope
- resultType on every result
- ttlMs / cacheScope
- Multi Round-Trip Requests
- Renumbered error codes
Proven against real servers
Tested on software nobody here wrote.
Fixtures only prove a tool against servers built to trip it. This also runs against the official MCP servers, and against the TypeScript SDK v2 built from source — where it found five defects in itself, every one of which had produced a false result. All fixed, all covered by regression tests.
Measured, not asserted. A weekly job probes a version-pinned cohort of the official servers and commits the verdicts. The first run: four of four reachable, none ready, 33 breaking findings — andevery one of them resolved by an SDK upgrade, none needing a change to the server author's own code. The snapshot stores verdicts and rule ids only, never anyone's wire traffic.
Read the walkthrough — one server, seven findings to READY →Getting started
Nothing to install.
Point it at your server
Over stdio or Streamable HTTP. It never calls a tool — tools have side effects — so it is safe to run against something live.
npx mcp-stateless \
--stdio "node dist/server.js"Read the verdict
Each finding names what was expected, what the server actually answered, and the fix. Add --verbose for the JSON-RPC traffic behind it.
NOT READY — 7 breaking
7 owned by your SDK
0 need your codeKeep it fixed
Wire the action into CI. Upload SARIF and findings appear in the Security tab and inline on pull requests.
- uses: Khanthtutzin/mcp-stateless@v0.3.1
with:
stdio: node dist/server.js
fail-on: errorTwelve-month deprecation clock
Find out in about ten seconds.
Exit 0 ready · 1 findings · 2 usage error, a probe that produced no verdict, or a file it could not write. A server it cannot reach — or one that answers and then stops — produces no findings at all, rather than twenty-one confident guesses.
npx mcp-stateless --http https://api.example.com/mcpAn independent open-source project. Not affiliated with, endorsed by, or an official part of the Model Context Protocol project or Anthropic. “Model Context Protocol” and MCP are used only to describe what this tool checks against. Findings reported about any third-party server describe that server's observable protocol behaviour at a point in time, nothing more — and every one of them is reproducible with a single command, printed alongside the finding.