We ran our own MCP fleet through our watch — and found we speak a Legacy protocol

On 2026-08-22 we pointed mcp-watch — the monitoring product we build — at our own production estate: four MCP servers and three web surfaces under jithox.com. On availability, the round came back clean: all seven targets LIVE, zero drift findings. It also came back with a verdict we now have to own in public: every one of our four MCP servers speaks protocol version 2025-11-25, which the current MCP specification classifies as a previous generation. Our own watch labels our own fleet Legacy (dogfood round run-b-mcp-factory-watch-1787414185.poging1.json, record JX_V45_WATCH_DOGFOOD, 2026-08-22T15:56:25Z).

What the stateless spec changes

The MCP specification revision of 2026-07-28 is the current one, and our research watch calls it the biggest protocol break since MCP exists (release/v46/research-watch.md, item UR-13, citing modelcontextprotocol.io's versioning page and the 2026-07-28 changelog). The highlights, all per UR-13:

• —MCP is now stateless. The initialize / notifications/initialized handshake is removed. Protocol version and client capabilities travel with every request in _meta; Mcp-Session-Id and protocol-level sessions are gone.
• —server/discover is mandatory — versions, capabilities and identity in one RPC.
• —Server-initiated requests are replaced by the MRTR pattern: instead of sampling, elicitation or roots calls from the server, a result carries resultType: "input_required" and the client retries.
• —subscriptions/listen replaces the GET endpoint and resources/subscribe; SSE resumability via Last-Event-ID is removed.
• —Deprecations: Roots, Sampling and Logging; the HTTP+SSE transport; and OAuth Dynamic Client Registration, superseded by Client ID Metadata Documents.
• —POST requests must carry Mcp-Method and Mcp-Name headers, list results get ttlMs/cacheScope, and a deterministic tool ordering is recommended for prompt caching.

How the watch turns that into a per-server verdict

mcp-watch appends every probe result to a hash-linked receipt chain (receipts.jsonl plus an anchor file); each target in a round gets its own chain-entry hash. Since product revision impr-001-r2, the protocol-generation verdict is written as its own record in that same tamper-evident chain — per server, with its own entry hash (dogfood artifact, eerlijkeGrens field).

A deliberate design choice sits underneath: a target's severity only measures drift between rounds and does not fold the generation verdict in. Generation is a separate axis with a separate chain record (WARNING when Legacy). That is why the same round can truthfully say "LIVE, zero drift" and "Legacy generation" about the same server — the two claims are independent and independently checkable. Each verdict records the observed protocolVersion, the norm source (the 2026-07-28 spec plus the dated research-watch analysis) and a written reason (dogfood artifact, protocolGeneratie per target).

The honest finding: we are the Legacy fleet

All four servers — mcp-einvoice, mcp-import, mcp-energy and mcp-sanctions, each exposing 5 tools — report protocolVersion: 2025-11-25 (dogfood artifact, doelen). Under the 2026-07-28 revision that is a previous-generation dialect and a break risk for modern stateless clients (UR-13; the verdicts' reden fields).

What we are doing about it follows the research watch's own recommendation (UR-13): a two-generation strategy. First, our fleet's authentication contract is anchored on the initialize handshake ("initialize open, tools/call OAuth-only", contract PLA-001) — under a stateless spec that anchor disappears, so the auth design must be reworked before migration, not during it. Second, mcp-watch itself will validate both generations, 2025-11-25-conformant and 2026-07-28-conformant, because everyone running MCP servers faces the same migration we do.

What this round does — and does not — prove

The round's artifact carries its own caveats, and they belong in this article:

• —The chain is hash-verified but unsigned. There is no Ed25519 signature yet; without a signer, the chain is not audit evidence (signatureStatus). We repeat that caveat wherever we cite the round, including here.
• —The negative controls are simulated. The four failure-mode checks — a removed tool must yield BREAKING, an empty catalog DEGRADED, an unreachable server UNVERIFIED/UNKNOWN, changed body content a WARNING — all passed, but they ran as simulated probes in a quarantine tenant, not as real production failures (negatieveControles).
• —Failure never turns green. UNKNOWN stays UNKNOWN until a successful re-measurement (eerlijkeGrens).
• —The chain has a known scale limit: above roughly 2,000 entries, rotation is required before production cadence (eerlijkeGrens, citing the v44 dogfood receipt).

The probes against the seven live targets themselves were real: executed by the watch itself on 2026-08-22, with nothing carried over from earlier rounds (echteProbes, uitvoering).

Try it on your own fleet

If you run MCP servers, the 2026-07-28 revision asks you the same question it asked us — and the honest answer may also be "Legacy." Point a watch at your own endpoints before your clients' upgrades do it for you: start at https://jithox.com/docs/quickstart.

Sources

• —/home/jithox/.hermes-v45/bot/bus/artifacts/run-b-mcp-factory-watch-1787414185.poging1.json — accepted dogfood round with per-server generation verdicts (2026-08-22T15:56:25Z)
• —/home/jithox/worktrees/v44-factory/release/v46/research-watch.md — UR-13, analysis of MCP spec revision 2026-07-28
• —https://modelcontextprotocol.io/specification/2026-07-28 — norm source referenced in the verdicts