Why the 2026 Stateless MCP Core Makes Proxying Practical

What Changed For Proxies

The operational shift is that an MCP request can now stand on its own. In earlier HTTP-era deployments, a proxy often had to respect a connection-level session and the old initialization shape before it knew enough about the client and server to route safely. The 2026 release removed the protocol-level handshake and session identifier from the core path, so a request can carry the protocol version, client information and client capabilities in _meta. That makes the proxy boundary much closer to ordinary HTTP infrastructure: any compatible backend instance can receive the next request if it has the same workspace, credential and source configuration.

That does not mean the application has no state. OAuth tokens, source connections, cached tool catalogs, audit records and explicit handles returned by tools still exist. The difference is where that state lives. It is no longer smuggled through a transport session that a load balancer must keep sticky. If a tool needs a continuation handle, it should return one as data and require the model to pass it into the next call. That is a better shape for a proxy because policy can inspect the handle-bearing call just like any other tools/call.

The Request Is Routable

For Streamable HTTP, each JSON-RPC request is sent as its own HTTP POST to a single MCP endpoint. The 2026 transport rules require request metadata headers such as MCP-Protocol-Version and Mcp-Method, and require Mcp-Name for calls that name a tool, prompt or resource. A proxy can read those headers before parsing the JSON body, which is exactly the sort of thing load balancers, WAFs, rate limiters and observability middleware are good at.

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: github.search_issues
Authorization: Bearer ${WORKSPACE_MCP_KEY}

{
  "jsonrpc": "2.0",
  "id": 17,
  "method": "tools/call",
  "params": {
    "name": "github.search_issues",
    "arguments": {
      "query": "repo:acme/api is:open label:incident"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "acme-agent",
        "version": "1.4.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The key safety rule is that headers are an envelope, not a second source of truth. The transport spec says the body remains authoritative and servers that process the body must reject mismatches between mirrored headers and body fields. That matters in a proxy chain: the edge might route on Mcp-Name, while the MCP server executes the JSON-RPC body. If those disagree and nobody checks, an attacker can aim one component at one tool and another component at a different tool.

Tool Discovery Becomes Cacheable

Proxying is much easier when discovery is deterministic. Tool-capable servers answer tools/list with the tools available to the requesting client, and the tools spec now allows pagination plus cache hints such as ttlMs and cacheScope. It also says servers should return tools in a deterministic order when the underlying set has not changed. For a gateway, that turns discovery into a cacheable policy product rather than a fresh upstream crawl on every agent startup.

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "linear.list_issues",
        "description": "List Linear issues visible to this workspace key.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "teamKey": { "type": "string" },
            "state": { "type": "string" }
          }
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "private"
  }
}

The cache key still has to include authorization. The tools spec allows the returned set to vary by the credentials on the request, because credentials are per-request input rather than connection state. A useful proxy cache key is therefore closer to workspace + caller key + granted scopes + enabled source + protocol version than just upstream URL. That is the bridge to the sibling article on lazy tool loading: a gateway can cache a small, caller-specific list first, then reveal another source when the task needs it.

Authorization Moves To The Edge

The authorization model also fits a proxy boundary. HTTP MCP servers act as protected resources, clients use bearer tokens, and authorization is included on every HTTP request. That lets a gateway make a decision before an upstream tool sees the request: is this token valid, is it intended for this MCP resource, does it have the scope needed for this source, and is the requested tool allowed for the caller?

For write-capable tools, the proxy should not rely on the model to choose safely. It should treat the requested method, the named tool and the granted permission as separate inputs. If the token is missing or invalid, the answer is a 401-style authorization failure. If the token is valid but lacks the requested scope, the answer is a 403-style insufficient-permission failure. If the tool exists upstream but is not visible to this caller, the proxy should return a clear denial rather than forwarding and hoping the upstream server catches it.

This is where proxying differs from publishing a registry entry. A registry can tell a developer that a server exists. A runtime gateway can stop tools/call before it leaves the workspace. The related guide on scoped API keys for AI agents goes deeper on least privilege; the stateless core simply makes that policy cheaper to enforce per request.

What The Proxy Still Must Own

The stateless core removes a class of transport stickiness, but it does not turn an MCP gateway into a blind reverse proxy. It still has to understand tool names, source ownership and response semantics. If two upstream servers both expose search, the tools spec says names are unique only within one server, so an aggregate proxy needs a disambiguation rule. Prefixing or otherwise namespacing the tool before it reaches the model is simpler than trying to infer the intended upstream after the call arrives.

Multi-round interactions are another place to be precise. Streamable HTTP can return request-scoped SSE for progress and final responses, and the newer shape embeds server-to-client needs as input-required results rather than independent server-initiated JSON-RPC requests. A proxy should preserve that structure instead of inventing its own long-lived side channel. The practical benefit is that approval, elicitation and retry flows stay attached to the original request.

How SPYN3 handles this

SPYN3 holds the upstream side of the session so the agent doesn't have to. When an upstream MCP server issues an Mcp-Session-Id, SPYN3 keeps it and sends it on later calls to that server. The agent never sees or manages it. Each upstream call is bounded: listing tools times out after 15 seconds and a tool call after 60. A server that stays down trips a circuit breaker for that source instead of slowing every request.

Rollout Checks

The first rollout check is protocol-era detection. If an upstream server still depends on the older HTTP+SSE shape, session identifiers or server-initiated requests, put an adapter at the proxy edge and make the compatibility behavior explicit. Do not let the agent see a modern stateless endpoint while the middle tier silently depends on sticky routing behind the scenes. That creates the exact operational coupling the new core is meant to remove.

1. Confirm every modern HTTP request includes MCP-Protocol-Version, Mcp-Method and, for named calls, Mcp-Name.
2. Reject requests where mirrored headers and JSON-RPC body fields disagree.
3. Cache tools/list only with a key that includes caller authorization and enabled source state.
4. Namespace aggregated tools before exposing them to the model.
5. Record whether an error came from proxy authorization, upstream reachability, upstream authorization or tool execution.

That last point is where the architecture becomes useful in daily operations. The companion article on proxied tool-call latency and cost covers measurement. For this topic, the important outcome is simpler: the proxy can be horizontally scaled, inspected and governed with normal HTTP controls while still speaking MCP correctly to the client.