Stateless MCP server architecture definition
A stateless MCP server is a Model Context Protocol server that handles each request independently, with every request carrying its own protocol version, client information, and credentials, so no session is held in server memory between calls and any instance can serve any request.
To deliver CMS content as agent-ready tools, build a stateless MCP server. Expose one HTTP POST endpoint, authenticate every request from its bearer token, and read content from the backend on each call, with no session held between calls. Anything a session used to hold moves to the backend. In Sanity, content lives in the Content Lake, the drafts-or-published view lives in the endpoint's perspective setting, and read scope lives in its groqFilter. A Context MCP request needs only its bearer token to be answered.
A stateless MCP server architecture runs a Model Context Protocol server so it holds no session in memory between calls. The Model Context Protocol (MCP) is an open standard that lets AI agents discover and call tools, read resources, and use prompts that a server exposes. In a stateless design, each request carries its own protocol version, client identity, capabilities, and credentials, so any server instance can answer any request.
Stateless is the protocol default, not a deployment choice. The MCP 2026-07-28 release post says MCP is "transforming from a bidirectional stateful protocol into a request/response stateless protocol." That revision came out on July 28, 2026. It removed the initialize/initialized handshake (SEP-2575) and the Mcp-Session-Id header (SEP-2567). Each request "now travels on its own," with its metadata in a _meta field, and "any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage." A client can use an optional server/discover call to learn a server's capabilities up front.
You can implement a stateless MCP server for CMS content in five steps. First, expose one HTTP POST endpoint. Under the Streamable HTTP transport spec, every JSON-RPC message goes in its own POST, and protocol-level sessions and the GET stream endpoint are gone. Second, build or reuse a server instance per request, with no session map. Third, authenticate every request from its bearer token. Fourth, read content from the CMS backend on every call so the tool result reflects the current document. Fifth, return JSON or a server-sent events (SSE) stream scoped to that one request.
A practical tool set for CMS content covers three jobs: describing the content schema, running a query, and reading a specific document or field. Clients also send Mcp-Method and Mcp-Name headers (SEP-2243). List results can carry ttlMs and cacheScope hints (SEP-2549) so clients can cache tool lists.
The major SDKs support this pattern. In the TypeScript SDK, the v1 stateless pattern of setting sessionIdGenerator to undefined, with a fresh transport per request, "maps directly onto the new default." The C# SDK defaults to stateless mode and recommends that "most servers disable sessions entirely." Cloudflare's createMcpHandler "builds a fresh server for every request."
A stateful MCP server keeps a session for each client in memory, while a stateless MCP server keeps nothing between calls. Under spec revisions 2025-03-26 through 2025-11-25, a server could assign an Mcp-Session-Id and track that session. Later requests then had to reach the same instance through sticky routing or a shared session store. The C# SDK documentation lists the costs as "complexity, memory overhead, and deployment constraints."
Sessions were also an unreliable place to keep state. SEP-2567 notes that "ChatGPT creates a fresh session for every individual tool call." Desktop and IDE clients keep one session per app launch, web clients keep one per page load, and "almost no clients resume a prior session."
Stateless servers scale horizontally because instances share nothing. That fits serverless and edge runtimes, where an instance may exist for a single request. Cloudflare, for example, now marks its Durable Object backed McpAgent as deprecated in favor of the stateless createMcpHandler. The difference matters for remote servers over Streamable HTTP. A local stdio server is one process serving one client, so the session question rarely comes up.
A stateless MCP server still handles authentication, user input, long-running work, and data that spans calls. That state lives in tokens, in the request cycle, or in external stores, not in server memory. As the 2026-07-28 release post puts it, "Dropping the protocol-level session doesn't force your application to be stateless."
Authentication travels as a bearer or OAuth token on every request. The 2026-07-28 revision also tightened authorization, adding RFC 9207 issuer validation. Elicitation and sampling are cases where the server needs an answer from the user or from the client's model. They use Multi Round-Trip Requests (SEP-2322): the server returns resultType "input_required" along with its questions, and the client retries the original call with the answers in inputResponses. State that spans several calls uses explicit handles. In SEP-2567, a create_basket tool returns a basket_id, and the model passes it back to add_item. Long-running work and durable data go to an external store, such as a database, a key-value store, or the content backend itself.
Some features still call for a stateful server. The C# SDK says to choose stateful mode if you need unsolicited notifications, resource subscriptions, per-client isolation, or server-to-client requests to clients that do not support Multi Round-Trip Requests. Long-lived notifications arrive on a subscriptions/listen response stream.
In Sanity, an MCP endpoint over content can stay stateless because the content, the view, and the read scope all live in the backend, not in the server. Sanity Context is a hosted, read-only MCP server that gives agents structured access to content. In GROQ mode it serves a live dataset from the Content Lake. In Knowledge Base mode, which is in Beta, it serves material you indexed ahead of time. GROQ mode includes the tools initial_context, schema_explorer, groq_query, and array_field_reader.
The documented call is one self-contained POST to the endpoint URL. It has an Authorization: Bearer header carrying an organization token and a JSON-RPC body such as a tools/list request. No initialize step or session header is shown. The endpoint's perspective setting decides whether agents read published content (the default), drafts, or raw documents. Its groqFilter is applied server-side as a hard boundary, so nothing in the conversation can widen what the agent reads. Configuration lives in the Context app, not in agent code, so you can change what an endpoint serves without redeploying the agent.
Writes go through a separate Sanity MCP server at mcp.sanity.io, which supports OAuth and token-based authentication. Sanity is the AI Content Operating System, so agents query the same content backend that editors work in.
Explore Sanity Today
Understanding Stateless MCP server architecture is just the beginning. Take the next step and discover how Sanity can enhance your content management and delivery.
Last updated: