{"slug": "show-hn-only-1-of-4356-reachable-mcp-servers-is-ready-for-the-2026-07-28-spec", "title": "Show HN: Only 1 of 4,356 reachable MCP servers is ready for the 2026-07-28 spec", "summary": "A developer's scan of 4,356 reachable MCP servers found only one compliant with the 2026-07-28 spec, which introduces a stateless core and removes the initialize handshake. The tool mcp-spec-check probes live endpoints for readiness, revealing 90.8% of servers are not yet migrated.", "body_md": "Is your remote MCP server ready for the\n\n2026-07-28 MCP spec release? Find out in 30 seconds.\n\n```\nnpx mcp-spec-check https://your-server.com/mcp\n```\n\nNothing breaks on July 28.That date is when the spec text publishes, not a switch that flips. Version negotiation keeps working and deprecated features live for at least 12 months. This tool measuresadoptionof the new stateless core, not a countdown to an outage.\n\nThe [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) is the largest revision of the protocol since launch. The `initialize`\n\nhandshake and `Mcp-Session-Id`\n\nare removed in favor of a stateless core, `Mcp-Method`\n\n/ `Mcp-Name`\n\nrouting headers become required, SSE elicitation is replaced by Multi Round-Trip Requests, and several error codes change. SDKs and clients are already moving to the stateless core, so servers that never migrate get left behind as support windows expire. `mcp-spec-check`\n\nblack-box-probes your live endpoint (no code access needed) and tells you where you stand, with links to the migration docs.\n\nI probed every remote server in the official MCP registry, all 7,850 of them, on 2026-07-12. Of the 4,356 I could reach openly, exactly 1 passes all three required checks and 90.8% are not ready yet. The migration to the stateless core has barely begun, which is what you would expect before the spec is even GA. Full writeup, with every percentage next to its denominator and a host-collapsed sensitivity view: ** docs/scan-2026-07.md** (committed aggregate:\n\n[scan-2026-07.aggregates.json](/Roee-Tsur/mcp-spec-check/blob/main/docs/scan-2026-07.aggregates.json)).\n\nThe report leads with a one-line verdict, ** ready for 2026-07-28: YES / NO / UNKNOWN**, decided\n\n*only*by the three required checks below (\n\n`discover`\n\n, `routing-headers`\n\n, `session-independence`\n\n): all three pass gives `YES`\n\n, any fail gives `NO`\n\n, otherwise `UNKNOWN`\n\n. A letter grade over every check follows as a secondary signal.Only those first three can fail a server. The rest are `warn`\n\n: optional or forward-looking, never counted as \"not ready\" on their own.\n\nA check the server answers too ambiguously to judge is marked `inconclusive`\n\nand, like a skipped check, does not count toward the grade. If too many land there, the tool reports grade `?`\n\n(\"couldn't assess\", exit 2) rather than guess.\n\n| Check | What it means |\n|---|---|\n`discover` |\n`server/discover` replaces the initialize handshake; servers must implement it |\n`routing-headers` |\n`Mcp-Method` / `Mcp-Name` are required on every request so gateways can route |\n`session-independence` |\nProtocol-level sessions are removed; session-pinned servers cannot serve the stateless core behind load balancers |\n`error-codes` |\n(warn) resource-not-found renumbers from `-32002` to `-32602` |\n`cache-metadata` |\n(warn) new `ttlMs` / `cacheScope` caching metadata on list/read results |\n`mrtr` |\n(warn) results carry a `resultType` field (Multi Round-Trip Requests replace SSE elicitation) |\n`deprecated-features` |\n(warn) reliance on deprecated Logging or removed `resources/subscribe` capabilities |\n`auth-metadata` |\n(warn) OAuth protected-resource metadata (RFC 9728) discoverable at `/.well-known/oauth-protected-resource` |\n\nProbe correctness is the whole game, so every check is pinned against known-truth servers rather than just asserted:\n\n**Two reference servers run in CI.** A real old-spec server (official SDK v1) and an RC server (the 2026-07-28 SDK beta) are spawned on every build, and`mcp-spec-check`\n\nmust produce the exact expected verdict for all eight checks against both (`npm run verify:refs`\n\n). A regression in either direction fails the build.**A known-truth panel** cross-checks live public servers whose behavior is established, including GitHub's MCP server (auth-walled, RFC 9728 passes) and servers that should read as not-ready or inconclusive.**The official** runs against the RC reference server as an independent co-oracle.[conformance suite](https://github.com/modelcontextprotocol/conformance)\n\nIf the tool ever gives your server a wrong verdict, that is the top-priority bug. Open an issue with the `--json`\n\noutput.\n\n```\nnpx mcp-spec-check <url>                 # human-readable report + letter grade\nnpx mcp-spec-check <url> --json          # machine-readable, for scripting\nnpx mcp-spec-check <url> --verbose       # include the \"why\" for each check\nnpx mcp-spec-check <url> --timeout 30000 # per-probe timeout in ms (default 15000)\nnpx mcp-spec-check <url> --bearer <token>          # sends Authorization: Bearer <token>\nnpx mcp-spec-check <url> --header \"X-Api-Key: k\"   # any header; repeatable\n```\n\nWithout credentials, `mcp-spec-check`\n\ncan classify an auth-walled server but cannot\ngrade it: checks report `skipped`\n\nand the exit code is 2 (couldn't test). The\n`auth-metadata`\n\ncheck still runs, because its RFC 9728 probe of\n`/.well-known/oauth-protected-resource`\n\nis origin-level and needs no token, so\nyou get a readiness signal even behind the wall.\n\nExit codes are CI-friendly: `0`\n\nready, `1`\n\nat least one failing check, `2`\n\ncouldn't test (probe error; endpoint auth-walled / unreachable / not MCP; or the server answered our probes too ambiguously to grade).\n\n```\n- run: npx mcp-spec-check ${{ env.MCP_SERVER_URL }}\n```\n\nPure black-box HTTP probes against your live endpoint. No code access, nothing installed, nothing stored. Zero runtime dependencies.\n\n**Probing ethics.** The registry scan only touches endpoints voluntarily published in the official public MCP registry as connect URLs. Probes are host-serial (one request at a time per host, so no server ever sees parallel load), read-only protocol calls with no side effects, sent with a named `mcp-spec-check-scan`\n\nUser-Agent that links back to this repo. Per-server results stay on the machine that ran the scan; only aggregate counts and percentages are published.\n\nThe official [conformance suite](https://github.com/modelcontextprotocol/conformance) is a spec test framework for implementers, including draft-spec scenarios, that you wire up against your own code. [YawLabs/mcp-compliance](https://github.com/YawLabs/mcp-compliance) grades A to F compliance against the *current* 2025-11-25 spec. The official Inspector is for interactive debugging. `mcp-spec-check`\n\nis none of those: it is a 30-second black-box verdict on a hosted URL, aimed specifically at the *next* release (2026-07-28).\n\nIssues and PRs welcome, see [CONTRIBUTING.md](/Roee-Tsur/mcp-spec-check/blob/main/CONTRIBUTING.md). Probe correctness is the top priority: if a verdict looks wrong, please include the `--json`\n\noutput.\n\nMIT", "url": "https://wpnews.pro/news/show-hn-only-1-of-4356-reachable-mcp-servers-is-ready-for-the-2026-07-28-spec", "canonical_source": "https://github.com/Roee-Tsur/mcp-spec-check", "published_at": "2026-07-12 13:21:01+00:00", "updated_at": "2026-07-12 13:35:03.361680+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-infrastructure"], "entities": ["MCP", "mcp-spec-check", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/show-hn-only-1-of-4356-reachable-mcp-servers-is-ready-for-the-2026-07-28-spec", "markdown": "https://wpnews.pro/news/show-hn-only-1-of-4356-reachable-mcp-servers-is-ready-for-the-2026-07-28-spec.md", "text": "https://wpnews.pro/news/show-hn-only-1-of-4356-reachable-mcp-servers-is-ready-for-the-2026-07-28-spec.txt", "jsonld": "https://wpnews.pro/news/show-hn-only-1-of-4356-reachable-mcp-servers-is-ready-for-the-2026-07-28-spec.jsonld"}}