Stateless and every revision: can mcpx do both?

created:      2026-09-30T08:00:00-05:00
last-updated: 2026-09-30T08:00:00-05:00
increment:    1
status:       standard
tags:         area:compare, area:protocol
description:  whether one mcpx can serve and consume the stateless
              2026-07-28 protocol and every legacy revision at once, what
              "stateless" actually requires, where mcpx keeps state, and
              what stands in the way at 05c78b2.

The question: can mcpx speak the most modern, fully stateless protocol (2026-07-28) and also every older revision, in both directions?

The answer

The specification says yes, and says how. mcpx at 05c78b2 does not yet.

The specification allows exactly this. A dual-era server “MAY serve both eras concurrently on the same endpoint or process” (2026-07-28/basic/versioning.mdx:182), and it chooses per request: “A request carrying modern per-request _meta is served statelessly according to this revision. An initialize request selects legacy semantics, scoped to the stdio process (stdio) or the session (HTTP)” (2026-07-28/basic/versioning.mdx:176-180). A legacy session is therefore compatible with statelessness. What breaks statelessness is requiring state from a modern request, not having state somewhere.

“Stateless” is a property of the protocol surface, not of the process. A 2026-07-28 server may keep caches, durable tasks, open subscription streams and application handles. What it may not do is infer anything from the connection. It must not rely on earlier requests for version, capabilities or identity (2026-07-28/basic/index.mdx:191-193), should not require related operations to use the same connection (:196-197), must reference cross-request state “by an explicit identifier the client passes on each request” (:200-202), and “must not treat connection or process identity as a proxy for conversation or session continuity” (:204-208).

mcpx at 05c78b2 meets the dual-era shape. It serves initialize and per-request _meta on one endpoint, and it reads _meta before the connection’s handshake (internal/mcpserver/conn.go:133-146). It fails on details that decide interoperability:

1. It cannot talk to a conformant 2026 peer in either direction. server/discover answers protocolVersions and the client reads protocolVersions; the schema field is supportedVersions (internal/mcpserver/server.go:534, internal/mcpclient/client.go:284, schema/2026-07-28/schema.ts:683). mcpx talks to itself because both halves are wrong the same way.
2. Its modern input_required path needs the session 2026 removed. A requestState is bound to Mcp-Session-Id (internal/mcpserver/state.go:47-51, internal/mcpserver/server.go:1208-1230). A conformant sessionless 2026 client that declares elicitation gets -32603 "tools/call was still asking for input after 8 rounds" within milliseconds, and the upstream call is abandoned (internal/mcpserver/ask.go:195-209; reproduced on the wire, see the M1 transcript).
3. It mints Mcp-Session-Id for modern clients on server/discover (internal/mcpserver/server.go:1214-1229). 2026-07-28 does not define the header, and tells a server that supports only that revision to “ignore it, and do not mint or echo session IDs” (2026-07-28/basic/transports/streamable-http.mdx:680-686). A dual-era server is not literally bound by that sentence. But a modern request is to be “served statelessly according to this revision”, and the harm is not the header, which a conformant client ignores. The harm is that mcpx then depends on the client echoing it (item 2).
4. Its pool treats process identity as session continuity. A host that reaches mcpx over MCP is keyed as mcp-<pid> of the serving process (internal/cli/serve.go:292-297). Over the daemon’s /mcp that pid is the daemon’s, so every HTTP host shares one key. The comment says the host has “no way to tell us” (internal/cli/serve.go:289-290). opencode v2 does tell us: it sends _meta["ai.opencode/sessionID"] on every tools/call (v2:packages/core/src/mcp/client.ts:278), and mcpx discards it.

None of these is structural. Each has a known fix, and none needs mcpx to drop legacy support. §5 is the list.

1. What “stateless” requires of a 2026-07-28 server

The checklist, with mcpx’s status at 05c78b2. A server is stateless in the 2026-07-28 sense if all of these hold. “Dual-era” in the status column means the item applies to modern requests only, and mcpx handles legacy ones as the revision they negotiated.

What remains legitimately stateful in a conformant 2026 server: open listen streams, durable tasks (extension), client-held requestState, application handles, per-request auth context, process caches that no connection can observe, and legacy sessions for clients that opened with initialize.

2. Where mcpx keeps state

Every place mcpx remembers something across requests, verified at 05c78b2 (paths relative to pkgs/mcpx). The last two columns answer the question for 2026-07-28.

Two observations the table makes:

• Almost all of mcpx’s state is on the upstream side of the proxy. Pools, schema caches, upstream sessions and the broker are invisible to a host. 2026 says nothing about them and does not need to. A proxy that keeps a browser warm between calls keeps state, and statelessness never forbade that.
• The state that faces the host is small and fixable. It is the HTTP session (legacy-only by right), the requestState binding, the MCP session key, and two task stores. Each has a request-scoped replacement that the specification already names.

The one thing that cannot become request-scoped is row 10, the live upstream call behind an input_required. Nor should it. mcpx is a single local process, not a fleet behind a load balancer, and the pattern’s motivation (“without requiring a shared storage layer across server instances”, 2026-07-28/basic/patterns/mrtr.mdx:30-31) does not apply to it. The requirement that does apply is that the handle is explicit, bound and expiring, and mcpx’s requestState already is.

3. Every revision, both directions

What happens today when each era meets mcpx. Server columns: a host of that revision connecting to mcpx. Client columns: mcpx connecting to an upstream server of that revision. The per-feature detail is in matrix-mcpx.md.

“Every older one” also needs a floor. The oldest published revision is 2024-11-05, and mcpx’s is 2025-03-26 (internal/mcpserver/revisions.go:14). Serving 2024-11-05 is cheap to add, and it is the only revision mcpx refuses outright. It means a counter-offer in negotiate, plus one floors row for each thing 2025-03-26 added (audio, tool annotations, the completions capability: 2025-03-26/changelog.mdx:18, :25-27). With those rows the downgrade() audio branch, dead today, starts to matter.

4. The conflict at the centre

Statelessness and “accept liberally” pull in opposite directions in one place: a request that carries neither _meta nor a session. 2026-07-28 says such a request is malformed (2026-07-28/basic/index.mdx:380-381). The legacy HTTP rules say a server that receives no MCP-Protocol-Version “SHOULD assume protocol version 2025-03-26” (2025-06-18/basic/transports.mdx:250-254), and a legacy client may legitimately never send a session header when the server issued none. mcpx takes the legacy reading and serves the request as 2025-03-26 (internal/mcpserver/conn.go:137-146).

For a dual-era server that is the right call. Rejecting it would break every legacy client that ignores sessions, and nothing in 2026-07-28 tells a dual-era server to prefer the modern reading. The specification never states it, and this page records it so nobody “fixes” it into a regression. See conflicts.md.

5. What it would take

Ordered by how much interoperability each item buys. The register row for each is in the linked area file. The PROTOCOL work in progress at the time of writing (a modern-first probe and conformance fixes) is expected to close some of these; the status column in each register file is where that shows.

Nothing on this list conflicts with keeping every legacy revision. Items 1–8 touch only the modern path or add checks the legacy path already skips.

Evidence

The wire observations (W*, M*, S*) come from a session recorded against a binary built from 05c78b2 with an isolated configuration, state and socket, driving the repository’s own test servers (internal/testsupport/fakemcp, internal/testsupport/askmcp). W1, W5, W12, W15, W16, W17, W18, W20, W21, M1 and M2 were reproduced independently for this page. The requests, verbatim:

• W5 server/discover with 2026 _meta → HTTP 200, a Mcp-Session-Id header, and {"capabilities":{…,"extensions":{"io.modelcontextprotocol/tasks":{}},…,"tasks":{…}},"instructions":…,"protocolVersions":[…],"serverInfo":{…}}.
• M1 tools/call mcpx_call → ask.need_repo with 2026 _meta declaring elicitation, no session → {"error":{"code":-32603,"message":"tools/call was still asking for input after 8 rounds"}} in about 40 ms.
• M2 the same after taking Mcp-Session-Id from server/discover → {"resultType":"input_required","inputRequests":{"elc-…":{"method":"elicitation/create",…}},"requestState":"<base64>.<hmac>"}. The base64 part decodes to {"c":"tsk-…","b":"sess-…","e":<unix expiry>}.
• M4 the M3 retry without the session header → {"error":{"code":-32602,"message":"this requestState belongs to another session"}}.
• W17 subscriptions/listen over HTTP → 202 Accepted, Content-Length: 0.
• W13 a request whose _meta version is 9999-01-01 → HTTP 200, -32022, "requested":"".