Adopt MCP specification 2026-07-28

[ypldan]

QuickApps version

latest

What is the problem this feature will solve?

MCP spec 2026-07-28 is a major, partly breaking release (RC published; final on 2026-07-28 — see the release-candidate announcement and the changelog). QuickApps' MCP client implements the session-based protocol the new revision removes: the initialize/initialized handshake and Mcp-Session-Id are gone — protocol version, client info, and capabilities travel via _meta on every request; a mandatory server/discover RPC advertises server identity, capabilities, and instructions; server-initiated requests (sampling/elicitation/roots) become Multi Round-Trip Requests; subscriptions/listen replaces the GET/SSE stream; tool schemas move to full JSON Schema 2020-12; error codes are renumbered; and roots/sampling/logging are deprecated. Servers on older revisions stay valid on those revisions, so QuickApps must interoperate with both generations for the long transition.

What is the feature you are proposing to solve the problem?

Assess and adopt the new spec in the MCP client:

• Support new-spec servers: stateless request cycle, _meta-carried client info/capabilities, server/discover, multi-round-trip InputRequiredResult handling, updated error codes and JSON Schema 2020-12 tool schemas.
• Detect the server's spec generation (server/discover as the probe) and keep old-spec servers working — they will remain the majority for a long time, so the session-based path is not legacy code but the primary path for now.
• Re-baseline in-flight MCP work against the new spec — see Additional information.
• Evaluate the operability additions (ttlMs/cacheScope caching hints, Mcp-Method/Mcp-Name routing headers, trace-context propagation) as follow-ups.

What alternatives have you considered?

Stay on the 2025 spec until forced — rejected: new servers will target the stateless protocol, and the deprecation clock on the old one is already running.

Additional information

Impact on existing backlog items (to reconcile in this issue's design pass):

• Preserve MCP session across tool calls #389 (preserve MCP session): built around Mcp-Session-Id persistence, which the new revision removes in favor of server-minted handles passed as ordinary tool arguments. Preserve MCP session across tool calls #389 keeps its near-term priority unchanged — today's server ecosystem is session-based and will stay predominantly so for years (the HTTP+SSE transport deprecated in 2025-03-26 is still common today); it just becomes spec-version-aware. New-spec servers need no client-side session preservation: handles flow through tool args naturally.
• Utilize MCP instructions #282 (MCP instructions): instructions survive the redesign — they move from the removed initialize handshake to DiscoverResult.instructions, cacheable via ttlMs. If anything, adoption gets easier: discoverable on demand, no handshake required.
• MCP capabilities extension: resources as context sources #425 / PR chore/mcp_capabilities_extension #384 (capabilities extension): capability negotiation moves to per-request capability maps — the design doc's negotiation section needs an update.
• Code interpreter MCP service #422 (code-interpreter MCP facade): should target the new spec from day one; the Tasks extension (tasks/get/update/cancel) fits long-running code execution, and statelessness may soften Consume code interpreter via MCP and retire the internal py_interpreter toolset #423's dependency on Preserve MCP session across tool calls #389.