What is the difference between MCP session state and request-scoped metadata?

Session state was implicit context carried for the life of a connection, while request-scoped metadata is sent on each call and can be processed independently. In the 2026-07-28 spec, protocol version, client capabilities, and identity move into _meta or headers on every request. That shift supports ordinary HTTP routing, but it also pushes state handling into the application and authorization layer.

How MCP session state and request-scoped metadata differ

MCP session state is connection-bound context that can persist across a live channel, so one request may depend on what was established earlier. Request-scoped metadata is carried on each call, which makes the call more self-contained and easier to route, inspect, and authorize independently. That design shift reduces hidden coupling, but it also means more logic must be explicit at the request boundary.

The practical difference is that session state behaves like remembered conversation context, while request-scoped metadata behaves like an ordinary HTTP envelope. In the newer model, information such as protocol version, client capabilities, and identity is no longer assumed to be remembered from the session alone. It is sent in-band on each request or in headers, which makes intermediaries and policy layers more relevant to enforcement.

For implementers, this changes where trust is placed. With session state, the server can infer some facts from a prior handshake, but that creates hidden dependencies on connection continuity and server-side state. With request-scoped metadata, each call must carry enough context for the server to decide what to do, which is usually better for distributed systems, load balancing, and stateless processing. The trade-off is that authorization and context validation become more visible, and also more demanding, at the application boundary. See the MCP authorization specification for how MCP servers treat HTTP transports and audience-bound tokens.

Why the protocol shifted toward per-request metadata

Per-request metadata fits the way HTTP infrastructure actually behaves. Routing, retries, proxies, and observability tools all work more cleanly when the request describes itself, rather than relying on connection memory. That is one reason modern protocol design tends to prefer explicit request context over implicit session assumptions.

This shift also changes how clients and servers evolve. If capabilities or identity are attached to the session only, then changes mid-connection can become ambiguous. If they are attached to each request, the application can evaluate them repeatedly and reject stale or malformed context without guessing what a previous exchange implied. That is especially useful when the protocol needs to interoperate with gateways, policy engines, and distributed backends.

The difference is not just cosmetic. The MCP Security Guide explains why transport-bound assumptions and token handling need to be designed explicitly, and why token passthrough, gateway behaviour, and client metadata all affect the security model. For the broader agentic context, the OWASP Agentic Applications Top 10 highlights identity and privilege abuse as a recurring failure mode when tool-using systems rely on weak context boundaries.

What this changes for authorization and state handling

Once identity moves into request-scoped metadata, the server can no longer treat earlier connection setup as sufficient proof for later actions. Each request must be checked against the current authority, target resource, and allowed operation. That makes the authorization layer more central, because the application now has to decide whether the metadata is enough to trust the call.

It also changes failure modes. A stale session may still look alive, but its request metadata may no longer match the policy that should govern the action. Conversely, if metadata is missing or inconsistent, the server has to fail closed rather than trying to reconstruct context from memory. In practice, that means teams should design for explicit validation of protocol version, client capability, and identity at the request boundary, not just at connection establishment.

Where agentic or machine-driven clients are involved, this is closely related to least privilege and short-lived authority. The AI Agent Identity Security: The 2026 Deployment Guide and AI Agent Authorisation Guide both reinforce the same operational principle: the caller should present enough context for each action to be judged on its own merits, not merely inherit trust from an earlier step.

Risk and Threat Considerations

Request-scoped metadata improves clarity, but it can also expose weaknesses if teams assume the application will “remember” what the transport no longer guarantees. If identity, capability, or version data is omitted, stale, or spoofed, the server may make the wrong authorization decision or route a request incorrectly. The security burden shifts from connection persistence to per-call correctness.

Failure mechanism: An attacker or faulty client can exploit inconsistent request metadata, replay outdated context, or take advantage of servers that over-trust prior session state instead of validating each call independently.

Impact: The result can be broken authorization, confused-deputy behaviour, privilege misuse, or routing to an unintended capability set, especially in systems where tools or downstream services rely on the metadata for policy decisions.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Request-scoped identity and capability handling affects agent privilege decisions.
Recommendation — Enforce per-request authorization so agents cannot inherit stale privileges.
OWASP API Security Top 10	API2 — Broken Authentication	Per-call identity context must be validated to avoid weak request authentication.
Recommendation — Validate each request's authentication data before processing the call.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Per-request identity handling requires reliable authentication at the boundary.
	AC-3 — Access Enforcement	Request metadata feeds authorization decisions that must be enforced on every call.
Recommendation — Authenticate the caller at each decision point, not only at session start. Enforce access decisions using the current request context and policy.
NIST CSF 2.0	PR.AA-05 — Managed Credentials and Authentication	The shift from session state to request metadata changes how credentials are presented and checked.
Recommendation — Bind credentials and authentication checks to each request flow.

Practitioner Guidance

What to verify: Treat protocol version, client capability, and caller identity as inputs that must be validated on every request, not inferred from connection history. If a downstream service depends on any of those fields, confirm that it fails closed when they are missing or inconsistent.

Common mistake: Do not let the session layer become a shadow authorization system. If the application or gateway cannot make a decision from the current request alone, you have preserved hidden state that will be hard to secure and harder to debug.

Practitioner takeaway: The safer design is the one where each request carries enough context to be judged independently, while any remaining session state is treated as convenience, not authority.