Explain what a stateful MCP session enables that a stateless per-call model cannot. Describe at least one concrete multi-step scenario and the scaling tradeoff this model introduces.
Free · 2 AI evals / day
A **stateful MCP session** means the server remembers things between calls inside one connection. The client negotiates capabilities once during the handshake, gets a session id, and reuses it for every later request.
That memory unlocks multi-step work. A database server can open a transaction in one call, run queries in the next few, then commit or roll back at the end. The transaction handle lives in the server's memory the whole time. A stateless model where every call starts fresh cannot do this safely, because each call would forget the open transaction.
State also lets the server push to the client. It can send notifications when a resource changes, support subscriptions, and even ask the model to sample a completion through the client.
The cost shows up in production. Because the state sits in one server instance's memory, follow-up requests must hit that same instance. That is called sticky routing, and it makes spreading load across many replicas harder. The server also has to clean up sessions when clients vanish, or memory leaks.
A stateful MCP session lets the server hold context across multiple calls in one connection. Capabilities are negotiated once at `initialize`, then a session id ties every later request to server-side memory.
The headline benefit is multi-step operations. A database server can open a transaction, run several queries, then commit or roll back. The transaction handle persists in memory across calls. A stateless per-call model cannot guarantee those calls share one transaction. State also enables server-initiated traffic: change notifications, resource subscriptions, and sampling callbacks where the server asks the host to run a model completion.
The production cost is horizontal scaling. Session state lives in one instance's memory, so follow-up requests must route back to that instance. This is sticky routing, also called session affinity. It blocks the stateless round-robin balancing that makes replicas trivially interchangeable. Teams must add affinity at the load balancer or externalize state to a shared store. Servers also need session cleanup, since clients that disconnect ungracefully would otherwise leak memory.
Streamable HTTP softens this. It allows a stateless mode where each request is self-contained, so simple servers can scale flat and skip affinity entirely.
Quick reference
TL;DR
A stateful MCP session remembers context across calls (enabling transactions and server-pushed notifications) but the cost is sticky routing that breaks easy horizontal scaling.
Think of a stateless call like a fast-food counter where a new cashier serves you each time. You must repeat your whole order every visit, and nobody can start cooking now to finish later. A stateful MCP session is a sit-down restaurant with one waiter who remembers your table all night. They open a tab, take several courses, and close it at the end. That memory is powerful: the waiter can also walk over and tell you news without being asked. The catch is you are tied to that one waiter. If they go on break, nobody else knows your tab. The restaurant cannot just throw any free waiter at your table the way the fast-food counter could.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Read-only tool servers like a search or lookup wrapper with no cross-call memory There is no state to preserve, so a stateful session only adds affinity and cleanup burden for no benefit.
High-fan-out remote deployments that must scale flat behind a simple balancer Sticky routing fights flat horizontal scaling; a stateless Streamable HTTP mode keeps replicas interchangeable.
Workflows that must survive replica restarts without losing progress In-memory session state vanishes when the instance dies, so durable steps belong in an external store, not a session.
Single-shot calls where each request is fully self-contained Negotiating and pinning a session id adds latency and memory cost with nothing to remember between calls.
Quick scan · 2–4 min
Everything important, quickly.
5 min: define session state, give a transaction example, list server-initiated features, explain sticky routing and cleanup, then close on when Streamable HTTP stateless mode is the right call.
Code example
typescript
// Stateful session: the server holds a DB transaction across calls.
const sessions = new Map<string, { tx: Transaction; lastSeen: number }>();
server.setRequestHandler("tools/call", async (req, sessionId) => {
const { name, arguments: args } = req.params;
if (name === "begin_transaction") {
const tx = await db.beginTransaction();
sessions.set(sessionId, { tx, lastSeen: Date.now() });
return ok("transaction opened");
}
const session = sessions.get(sessionId);
if (!session) throw new Error("no active session"); // sticky routing failed
session.lastSeen = Date.now();
if (name === "execute_query") return ok(await session.tx.query(args.sql));
if (name === "commit") {
await session.tx.commit();
sessions.delete(sessionId); // cleanup on graceful close
return ok("committed");
}
});
// Idle sweeper prevents leaks from ungraceful disconnects.
setInterval(() => {
const cutoff = Date.now() - 30 * 60 * 1000;
for (const [id, s] of sessions) {
if (s.lastSeen < cutoff) { s.tx.rollback(); sessions.delete(id); }
}
}, 60 * 1000);
Side-by-side
Concern
Stateful session
Stateless per-call
Multi-step transactions
Yes, handle persists across calls
No, each call is isolated
Server-initiated push
Notifications, subscriptions, sampling
Not supported
Capability negotiation
Once at initialize
Per request, if at all
Load balancing
Needs sticky routing
Plain round-robin works
Replica failure
Live sessions lost
Any replica can serve
Real-world examples
Real products, models, and research that use this idea.
1A Postgres MCP server opens a transaction, runs queries across several tool calls, then commits; the handle lives in session memory the whole time.
2Claude Code and Cursor keep long-lived stdio sessions to local servers, negotiating capabilities once at startup rather than per request.
3Remote MCP deployments behind AWS ALB or NGINX enable session affinity cookies to keep a client pinned to the replica holding its state.
4A read-only search MCP server runs in Streamable HTTP stateless mode, scaling flat behind a round-robin balancer with no affinity.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you externalize MCP session state so any replica can serve a follow-up request?
Sign in or go Pro to see the approach for this follow-up.
QHow does Streamable HTTP let a server choose between stateful and stateless operation?
Sign in or go Pro to see the approach for this follow-up.
QWhat happens to in-flight stateful sessions during a rolling deploy, and how do you mitigate it?
Sign in or go Pro to see the approach for this follow-up.
QWhy can a sampling callback only exist in a stateful, bidirectional session?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Naming only the benefit and forgetting the cost. Senior answers must connect in-memory session state to sticky routing and the loss of stateless load balancing.