Writing

MCP session handles are capability tokens, not pointers

MCP's shift to model-held session handles removes server affinity and lets the protocol scale horizontally. Instead of pinning a conversation to one server, the model carries the handle and passes it along as it moves between tools and models. That means no sticky sessions, no shared session store, and no server-side state to blow up. For agentic workloads where conversations hop between tools and models, that is a real win.

But the same shift quietly moves correlation, authorization, expiry, and retry semantics into the application layer. The server no longer owns the lifecycle of a session, so the application has to decide when a handle expires, how to correlate it across steps, and whether a retry is safe. In distributed systems, session state without a durable owner breeds orphaned handles, inconsistent auth checks, and audit gaps. If the model misplaces a handle, who is responsible? You are.

That question is not rhetorical. A model can drop a handle between steps, reuse one across workflows, or pass it to a tool that should not have received it. When the server no longer owns sessions, the application and the people operating it own the consequences. That is a meaningful change from the old model, where the session object at least had a clear home on the server.

So the tension is straightforward. You get horizontal scalability, but you give up a single, durable place where session state can be controlled. That control used to live in one place; now it is distributed across every application that speaks MCP. I do not think the change is bad. It just means the tradeoff needs to be acknowledged and handled deliberately rather than treated as a pure removal of sessions.

My take is to treat MCP session handles as opaque capability tokens, not pointers. A pointer implies something you can follow to a known object; a capability token implies something you can use for a limited purpose and a limited time. Bind them to a short TTL, rotate them per workflow, log a correlation ID at every hop, and enforce authorization at a gateway or sidecar rather than in the model. The model should not be the security boundary.

That approach keeps the scaling benefit of model-held handles without surrendering auditability or security. The handles become short-lived, observable, and replaceable as work moves forward. The server stays stateless, the application keeps a clear record of what happened, and authorization stays where it can be enforced consistently. That feels like the right balance for a protocol change that is otherwise easy to misread as simply removing sessions.

Originally covered at infoworld.com ↗