Epic: adopt MCP specification 2026-07-28

[TGoodhew]

Tracking issue for the MCP 2026-07-28 specification revision — the largest break since the protocol launched.

We currently implement 2025-06-18 (McpDispatcher.ProtocolVersion, src/GpibMcp.Core/Mcp/McpDispatcher.cs:22), two revisions behind.

What changed at the top level

• Sessions are gone. No Mcp-Session-Id, no per-connection list results (SEP-2567).
• The handshake is gone. No initialize / notifications/initialized. Every request carries its protocol version, client capabilities and identity in _meta (SEP-2575).
• server/discover is a MUST — the new way a client learns what we support.
• Every result needs resultType — "complete" or "input_required" (SEP-2322).
• ping, logging/setLevel, notifications/roots/list_changed removed.
• Server-initiated requests are replaced by MRTR — instead of the server calling sampling/createMessage or elicitation/create, it returns an InputRequiredResult and the client retries with inputResponses (SEP-2322).
• Roots, Sampling and Logging are deprecated — twelve-month minimum window (SEP-2577).
• Tasks moved to an official extension, io.modelcontextprotocol/tasks, with polling instead of blocking (SEP-2663).

Where we already line up

Worth noting before the list of work, because it's more than expected:

• The HTTP transport is already sessionless and offers no GET/SSE stream — SEP-2567 and SEP-2575 both move toward exactly that, so there's nothing to unwind
• No SSE resumability to remove
• We use none of the deprecated features — no Roots, no Sampling, no Logging; diagnostics already go to stderr, which is the recommended migration
• tools/list is already deterministically ordered
• All our error codes sit in the standard JSON-RPC range, so nothing collides with the newly reserved block

Work

• MCP: validate the client's protocolVersion instead of echoing it back #104 — validate the client's protocolVersion instead of echoing it back (bug, do first, independent of the rest)
• MCP 2026-07-28: implement the required server/discover RPC #105 — implement server/discover
• MCP 2026-07-28: stateless dispatch - per-request _meta context and serverInfo in results #106 — stateless dispatch: per-request _meta context, serverInfo in results
• MCP 2026-07-28: add the required resultType field to every result #107 — required resultType on every result
• MCP 2026-07-28: tools/list must return ttlMs/cacheScope and a deterministic order #108 — tools/list: ttlMs / cacheScope + pinned ordering
• MCP 2026-07-28: adopt the JSON-RPC error-code allocation policy #109 — JSON-RPC error-code allocation policy
• MCP 2026-07-28: Streamable HTTP - Mcp-Method/Mcp-Name headers and stale session remnants #110 — Streamable HTTP: Mcp-Method / Mcp-Name headers, stale session remnants
• MCP 2026-07-28: answer subscriptions/listen (replaces the HTTP GET stream) #111 — answer subscriptions/listen
• Adopt the io.modelcontextprotocol/tasks extension for long-running captures and batch sweeps #112 — io.modelcontextprotocol/tasks for long-running captures and sweeps
• Add outputSchema + structuredContent so measurements stop coming back as prose #113 — outputSchema + structuredContent for measurement results
• HTTP transport authorization: static bearer token vs the MCP authorization spec #114 — HTTP authorization: static bearer vs the MCP authorization spec
• README + packaging/ docs updated once the wire format changes (the README's initialize examples at lines 211/226/767 hard-code 2025-06-18)

Suggested sequencing

1. MCP: validate the client's protocolVersion instead of echoing it back #104 first — it's a real bug today, standalone, and small.
2. Adopt the io.modelcontextprotocol/tasks extension for long-running captures and batch sweeps #112 and Add outputSchema + structuredContent so measurements stop coming back as prose #113 next. These are the only two items on the list with a user-visible payoff: task handles + progress for the 7–24 s captures, and structured measurement results instead of prose the model re-parses. Neither is blocked on the conformance work.
3. Then the conformance block (MCP 2026-07-28: stateless dispatch - per-request _meta context and serverInfo in results #106 → MCP 2026-07-28: add the required resultType field to every result #107 → MCP 2026-07-28: implement the required server/discover RPC #105 → MCP 2026-07-28: tools/list must return ttlMs/cacheScope and a deterministic order #108 → MCP 2026-07-28: adopt the JSON-RPC error-code allocation policy #109 → MCP 2026-07-28: Streamable HTTP - Mcp-Method/Mcp-Name headers and stale session remnants #110 → MCP 2026-07-28: answer subscriptions/listen (replaces the HTTP GET stream) #111), with MCP 2026-07-28: stateless dispatch - per-request _meta context and serverInfo in results #106 first since the per-request context is what the others hang off.

Compatibility constraint

Every client we ship for today — Claude Desktop, the .mcpb bundle, the Copilot/ChatGPT HTTP connectors — speaks 2025-06-18. This has to be additive: keep initialize, notifications/initialized and ping working as legacy paths and switch behaviour on the revision the request actually declares. No client is asking for 2026-07-28 yet, so there's no rush — but #104 means we currently claim to support it when asked, which is the part that should be fixed now.

[TGoodhew]

Conformance block complete — everything but #114 is done and merged.

Issue	PR	What landed
#104	#116	SupportedProtocolVersions + honest negotiation
#112	#117	tasks extension + notifications/progress
#113	#118	outputSchema / structuredContent on four tools
#106	#121	RequestContext, per-request _meta, serverInfo on every result
#107	#122	resultType
#105	#123	server/discover
#108	#124	cacheable, order-pinned tools/list
#109	#125	error-code allocation policy
#110	#126	Streamable HTTP request-metadata headers, 405 on GET/DELETE
#111	#127	subscriptions/listen

Tests went 305 → 402 (plus 113 in Hpgl.Rendering).

The compatibility constraint held throughout. Everything new is gated on the revision a request declares, so a 2025-06-18 client — Claude Desktop, the .mcpb bundle, the Copilot and ChatGPT connectors — sees exactly what it saw before. initialize, notifications/initialized and ping are all still served.

We still do not claim 2026-07-28. SupportedProtocolVersions lists only what is fully implemented, and server/discover reports that list. Two things stand between here and adding it:

1. HTTP transport authorization: static bearer token vs the MCP authorization spec #114, the last open item.
2. MRTR (SEP-2322) — InputRequiredResult / inputResponses. Not on this epic's list because we initiate no sampling, elicitation or roots requests, so there is nothing to convert. Worth confirming that reading before claiming the revision, since resultType: "input_required" is the half of MCP 2026-07-28: add the required resultType field to every result #107 we do not implement.

A dated revision we do not fully implement is currently served best-effort with a warning rather than refused (see #109 for why: refusing would put the 2026-07-28 features out of reach of the only clients that want them). That best-effort branch turning into a refusal — or into 2026-07-28 joining the supported list — is the closing move of this epic, and McpDispatcher.CheckDeclaredProtocol is where it happens.

[TGoodhew]

All child issues are now closed. #114 landed as PR #129: the decision is static bearer, deliberately — recorded in the issue, the README and packaging/chatgpt, with the three standalone fixes (refuse to start on a network bind with no token, constant-time comparison, the Origin/tunnel behaviour documented).

Tests: 305 → 414 GpibMcp, plus 113 in Hpgl.Rendering.

What is left before this epic can close is the one thing it cannot decide for itself: whether 2026-07-28 joins SupportedProtocolVersions.

Everything the revision asks of a server is implemented — stateless dispatch, server/discover, resultType, cacheable tools/list, the error-code policy, the transport headers and status codes, subscriptions/listen, tasks. Two things stand in the way of claiming it:

1. MRTR (SEP-2322) is unimplemented and believed inapplicable. We return no InputRequiredResult because we initiate no sampling, elicitation or roots requests — there is nothing to convert. That reading should be confirmed rather than assumed, because it is the half of MCP 2026-07-28: add the required resultType field to every result #107 we do not implement.
2. The authorization SHOULD. HTTP transport authorization: static bearer token vs the MCP authorization spec #114 chose the static bearer over the spec's OAuth model. That is a deliberate, documented departure from a SHOULD, not a MUST — so it does not block the claim, but it should be a conscious part of making it.

If both hold, the change is small and lives in one place: add the revision to SupportedProtocolVersions and turn the best-effort branch in McpDispatcher.CheckDeclaredProtocol into a refusal for anything genuinely unsupported. Until then the server keeps doing what it does now — serving a 2026-07-28 request best-effort, and telling the truth about what it implements when asked.