How to Deploy an MCP Server in 2026

If you deployed an MCP server before mid-2026, the deployment fundamentals (HTTPS, process management, rate limiting) haven't changed. What has changed is the protocol underneath, and it makes some parts of deployment meaningfully simpler. This post covers what's actually different in 2026, on top of our general production deployment guide.

The Big Change: No More Session Affinity

Every MCP deployment before the 2026-07-28 specification had to deal with session state. A client would initialize, get back a session tracked by an Mcp-Session-Id header, and every subsequent request in that session needed to reach the same server instance, or you needed shared session storage across instances. This is exactly the kind of infrastructure complexity that turns "deploy a Node process" into "deploy a Node process plus Redis plus sticky routing rules."

The 2026-07-28 spec removes this. MCP is now stateless: every request carries its own protocol version, client identity, and capabilities, so any request can land on any server instance behind a plain round-robin load balancer. If you're deploying an MCP server today on a spec-current SDK, you no longer need sticky sessions or shared session storage at all.

What this means for your deployment:

• A plain round-robin load balancer works. You don't need session affinity rules.
• Horizontal scaling is simpler: add another instance behind the load balancer, and any request can hit it.
• You don't need a shared session store (Redis or similar) purely for MCP session tracking, though you may still want one for rate limiting counters or caching.

The Tradeoff: You Handle State Explicitly Now

Removing implicit session state doesn't mean your tools can't have state, it means state has to be modeled explicitly instead of relying on the transport layer to hold it for you. The recommended pattern from the spec authors: mint an explicit handle from a tool call, and have the client pass that handle back as an argument on the next call.

// A tool that starts a multi-step process returns a handle
return {
  content: [{type: "text", text: "Import started."}],
  structuredContent: {importHandle: "imp_8f2a91"},
};

// A later tool call receives the handle as an explicit argument
server.registerTool("check_import_status", {
  inputSchema: z.object({importHandle: z.string()}),
}, async ({importHandle}) => {
  // Look up state by the handle, not by an implicit session
});

This is slightly more code than relying on hidden session state, but it's also easier to observe and debug, since the state your tool depends on is visible in the request itself rather than tucked away in a server instance's memory.

Multi Round-Trip Requests Replace Held-Open Connections

Before this revision, a server that needed more input mid-call (confirming an action, or asking for a missing parameter) had to hold a connection open and push a server-initiated request over it. That pattern doesn't work with stateless, load-balanced HTTP.

Multi Round-Trip Requests (MRTR) replace it: a server returns resultType: "input_required" describing what it still needs, the client collects the answer, and retries the call with inputResponses included. If your deployment previously relied on long-held connections for this kind of interaction, plan to update the tool logic, not just the infrastructure, when you move to a spec-current SDK.

Deployment Checklist for 2026

The core checklist from our production deployment guide still applies. What's new or changed:

• Confirm your SDK version implements the stateless 2026-07-28 transport (see our SDK v2 migration guide if you're on the TypeScript SDK)
• Remove sticky session routing rules if your load balancer had them configured for MCP traffic
• Audit any tool that relied on implicit session state and convert it to an explicit handle pattern
• If you use OAuth, confirm your authorization server returns the iss parameter per the tightened authorization spec
• Legacy HTTP+SSE transport is deprecated with a one-year offramp. Not urgent, but plan the move to Streamable HTTP if you haven't already

Skipping the Infrastructure Work Entirely

Every point above is infrastructure and protocol-version work that a hosted platform absorbs on your behalf. MCPCore runs on the current spec, so a revision like 2026-07-28 is something the platform handles rather than something you have to re-architect around. See MCP server deployment for what that looks like in practice.

---

This post covers deployment-relevant changes in the 2026-07-28 specification. See MCP 2026-07-28: What Changed for the full protocol-level summary, and modelcontextprotocol.io for the authoritative spec.