A tool request now carries its own routing record
The 2026-07-28 MCP standard puts routing fields and client context on each request. Gateways can record the route without decoding the body.
A tool request should arrive with enough context for a gateway to record its route. The 2026-07-28 Model Context Protocol standard makes that practical.
Model Context Protocol, or MCP, is a standard that connects models to tools and data. Its maintainers published the 2026-07-28 version with a stateless protocol core. Stateless means the server keeps no protocol session shared across requests.
Routing moves into headers
Streamable HTTP requests must include Mcp-Method and Mcp-Name. Those headers expose the method and tool name to a gateway. It can route, authorize, and meter a request without parsing its JSON body.
The request also states its version through MCP-Protocol-Version. Its schema requires the matching io.modelcontextprotocol/protocolVersion value in _meta.
That makes the routing decision easier to record. A gateway can retain the protocol version, method, tool name, decision, and result as one request record.
Client context travels with the request
The schema requires io.modelcontextprotocol/clientCapabilities on each request. An empty object says that the client supports no optional capabilities. A server must not infer capabilities from an earlier request.
Client software can also send io.modelcontextprotocol/clientInfo. That field holds the client name and version. The schema defines this identity as self-reported and unsuitable for security decisions.
This limit matters. A request can state useful context without proving the client’s authority. The record should keep the claimed identity separate from verified authorization facts.
Session state no longer fills the gaps
The release removes the initialize handshake and the Mcp-Session-Id header. Any request can reach any server instance without shared protocol storage.
Application state can still exist. The maintainers say a tool can issue an explicit handle for a later request. That handle becomes visible request data instead of hidden transport state.
Authorization changes follow the same boundary. The release requires RFC 9207 issuer validation before a client redeems a code. It also binds client credentials to their issuing authorization server.
Dynamic Client Registration remains for compatibility. This standard deprecates it in favor of Client ID Metadata Documents. The release also formalizes an extension framework.
Muniment’s position is that routing and authorization facts belong on the request record. Our connections bind by name to approved MCP registry or local-stdio allowlist entries.
This standard defines fields and behavior. It does not measure production outcomes. The MCP maintainers are neither Muniment customers nor endorsers.