Should Your MCP Server Hold State, and Where Does It Live If It Does Not?

TL;DR: Prefer a stateless MCP server, and treat state as a placement decision rather than a default. The core interaction works without the server remembering each client between calls, which is what lets servers scale, restart, and fail without taking conversations down with them. Product data lives in your product, where it always lived. Conversation context lives with the client and the model. The small remainder, short lived working state such as an upload in progress, belongs in an explicit store keyed to the calling agent, with an owner, an access rule, and an expiry. State you cannot name an owner and a lifetime for should not be stored at all.

Key Takeaways

• Stateless does not mean nothing is stored anywhere. It means the MCP server does not need private memory of a client to answer the next call correctly.
• There are three kinds of state and they belong in three places: product data in the product database, session context with the client, and working state in a named store with a lifetime.
• Hidden server state is the dangerous kind. If a tool only works because the server remembers an earlier call, scaling, restarts, and second callers all become failure modes.
• Per-agent identity decides who may read working state. October 2026 MCP security coverage read for this post ties state access to per-agent tokens and server side enforcement.

What does stateless actually mean for an MCP server?

It means each call carries what the server needs, and the server answers from the request plus the product data behind it, not from a memory of the conversation. The comparison in what actually changes when an agent calls your product through MCP instead of your API tracks this shift at the protocol level: earlier assumptions about a stateful session gave way to a core that treats calls as independent, which is why hosted servers can sit behind ordinary load balancing and restart without ceremony.

Stateless does not forbid reading and writing data. Writing a record through a tool changes product state, and that is the point of the tool. What it rules out is conversational memory as a load bearing mechanism: the server quietly remembering which record you mentioned three calls ago, with no record of that memory anywhere the operator can inspect. That hidden dependency breaks in predictable places.

Where does each kind of state belong?

Product data belongs in the product. If an agent creates a lead or updates a ticket through your tools, the result should land in the same store your own interface uses, under the same validation and permissions. An MCP server that keeps its own shadow copy creates two sources of truth, and they will disagree in production at the worst moment. As how to build an MCP server for your SaaS argues, the server is a projection of the product, not a second home for its data.

Session and conversation context belongs with the client. The client and the model hold what the user asked, what the agent already tried, and which results it is reasoning over. If that context matters to the next call, the agent can include it in the call. Pushing it into the server strands it where the user and the model cannot see or correct it.

Working state belongs in an explicit store, and it is the only genuinely new category. Some workflows really do span calls: a large import staged in parts, a multi step approval waiting on a human, a long running job whose progress an agent polls. That state should live in a store you name, keyed by a job or session identifier, readable only by the agent identity that created it, and deleted on completion or expiry.

What breaks when a server holds state quietly?

Three failures recur. The first is scaling. A server that remembers sessions in memory cannot be replicated freely, because the next call may land on an instance that never saw the earlier ones. Teams work around this with sticky sessions, which trade a simple architecture for a fragile one and still fail when the sticky instance restarts.

The second failure is collision, the subject of the companion post on what happens when two agents call at the same time. State shared in server memory is shared between every caller who reaches that process. One agent in progress workflow becomes visible, or worse, writable, to another, and the bug only appears under real multi caller use.

The third failure is audit. State held inside a server process rarely appears in the invocation logs that what should an MCP server log argues for, so an operator reconstructing an incident cannot see the remembered context that made the server answer as it did.

How do identity and permissions apply to stored state?

Exactly as they apply to tools, because stored working state is data with readers. The October 2026 MCP security coverage read for this post makes the general argument in its own terms: per-agent tokens, server side enforcement, and least privilege. Translated to state, a job record created under one agent token is not readable under another agent token merely because both can call the same status tool. The server checks the caller identity against the state owner on every read, on the server side.

Least privilege also sets the lifetime: an agent that stages an import needs that state for the length of the import, not for a quarter, so set a short expiry at creation. And as which API endpoints should never become MCP tools argues for endpoints, an admin view of working state is an operator surface, not an agent tool.

How do you decide, for one feature, whether to store state?

Ask four questions in order. First, can the call carry the information instead? If the agent can include the identifier or the prior result in the request, no storage is needed. Second, is this product data in disguise? If a human user would expect to see it in your interface, it belongs in the product store through a normal tool write. Third, if it is genuinely working state, who owns it, which identities may read it, and when does it expire? Write those answers down before building. Fourth, what happens when it disappears mid workflow? The workflow should fail visibly and restart cleanly rather than continue on half remembered assumptions.

FAQ

Is a stateless server always the right choice?

It is the right default, not a law. A tiny local server serving one user on one machine can hold session state with little risk, because the scaling and collision failures never arrive. The moment the server is hosted or shared, the default should win unless you can name a concrete reason it cannot.

Where does conversation memory go if the server does not keep it?

With the client. The agent host holds the conversation, the task context, and the results so far, and passes whatever the next call needs as part of that call.

Bottom Line

Do not ask whether your MCP server may hold state in the abstract. Ask, for each thing it would remember, where that memory belongs, who may read it, and when it dies. Product data in the product, context with the client, working state in a named store under the calling agent identity, and nothing load bearing inside the server process itself. A server built that way can scale, restart, and serve two agents at once without any of those events becoming an incident.