DEV Community

Zira
Zira

Posted on

MCP's 2026 Update Makes Remote Servers Easier to Scale

#mcp #agents #ai #programming

If you run remote MCP servers for coding agents, the boring part of the stack just got a real upgrade.

The Model Context Protocol project published a release candidate for the 2026-07-28 specification — the biggest revision since launch. Final ships July 28, 2026. Alongside it: a stable Enterprise-Managed Authorization extension and beta SDKs in Python, TypeScript, Go, and C#.

This is not a model-launch week post. It's infrastructure. And infrastructure is what decides whether agent demos survive contact with production.

If you've been watching the shift from chatbots to coding agents, this is the plumbing layer catching up.

Why this matters more than another "agent" launch

MCP is how hosts like Claude, Claude Code, Codex-style tools, Cursor-class IDEs, and custom harnesses talk to tools and data. When that protocol is stateful and awkward to scale, every remote tool server becomes a special snowflake:

  • sticky sessions at the load balancer
  • shared session stores
  • gateway rules that parse JSON bodies just to route
  • per-user OAuth consent for every server in the org

That is fine for a laptop demo. It is painful when you have fleets of agents calling fleets of tools. The RC is aimed at that pain.

The big change: protocol-level sessions are gone

Before (2025-11-25 style)

You initialize once, get an Mcp-Session-Id, and every later call has to hit the instance that owns that session. Horizontal scale means sticky routing or a shared session store.

After (2026-07-28 RC)

The initialize handshake and protocol session are removed. Each request is self-describing. Client info, protocol version, and capabilities travel in _meta. Any instance can answer any request.

The official RC post shows the shape of a tool call:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}
Enter fullscreen mode Exit fullscreen mode

Practical effect: round-robin load balancers become normal again. That is the sentence ops teams have been waiting for.

Stateless protocol does not mean stateless apps

MCP is explicit about this. If your tool needs multi-step state, mint a handle (basket_id, browser_id, workspace_id) and have the model pass it back as a normal argument. The state becomes visible to the agent instead of hidden in transport metadata — which is usually better for debugging and for multi-agent handoffs.

Same idea as the safety mindset in agent systems: make authority and state explicit, not ambient. That pairs with the production instincts in coding agents tripping EDR alarms — different layer, same rule: don't rely on hidden session magic.

Multi Round-Trip Requests: prompts without sticky SSE

Servers still need to ask the user something mid-tool-call (confirm delete, pick a branch, approve a spend). Holding an SSE stream open and pinning a session was the old answer.

The RC replaces that with Multi Round-Trip Requests:

  1. Server returns InputRequiredResult + opaque requestState
  2. Client collects answers
  3. Client re-issues the tool call with inputResponses + the same requestState
  4. Any instance can continue the work

No long-lived connection required for "are you sure?" That is a huge deal for serverless and multi-AZ fleets.

Headers that gateways can actually use

Streamable HTTP now expects routing-friendly headers:

  • Mcp-Method
  • Mcp-Name (when a tool/resource/prompt is named)

Gateways and rate limiters can route without body inspection. Servers reject header/body mismatches.

Also useful in production:

  • ttlMs / cacheScope on list/read results so clients can cache tools/list
  • W3C Trace Context names locked so OpenTelemetry traces can span host → client SDK → MCP server → downstream

If you care about reliability of agent systems (not just model quality), this is where real levers live. Tool discovery thrash and blind routing show up as ops pain as much as bad prompts do.

Enterprise auth finally matches how companies work

Per-user OAuth for every MCP server does not scale in a company:

  • onboarding becomes a consent gauntlet
  • security cannot enforce one policy
  • personal vs corporate accounts blur

The Enterprise-Managed Authorization (EMA) extension is now stable. The org IdP becomes the decision plane. Users SSO once; admins grant server access by group/role; clients exchange an Identity Assertion JWT Authorization Grant (ID-JAG) for audience-restricted access tokens without per-server consent screens.

Early ecosystem signals from the official post:

  • IdP: Okta first (Cross App Access / XAA)
  • Clients: Anthropic's shared MCP layer (Claude, Claude Code, Cowork), VS Code preview support
  • Servers: Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase (with more in flight)

This is the enterprise companion to model/agent productization stories like ChatGPT Work: agents only become default work software when identity, audit, and policy are not duct-taped on later.

What is deprecated (and what is not on fire)

Under the new lifecycle policy, Roots, Sampling, and Logging are deprecated with replacements:

Deprecated Prefer
Roots tool params, resource URIs, server config
Sampling direct provider APIs
Logging stderr (stdio) / OpenTelemetry

These are annotation-style deprecations with at least 12 months before possible removal. Do not panic-delete code tonight. Do put them on a migration list.

Also note: missing resources now use standard JSON-RPC -32602 instead of MCP-custom -32002. If you match the literal error code, update clients.

SDK betas: what to install if you want to test

From the SDK beta announcement:

# Python (opt-in pre-release)
pip install "mcp[cli]==2.0.0b1"
# or: uv add "mcp[cli]==2.0.0b1"

# TypeScript v2 (new package names)
npm install @modelcontextprotocol/server@beta
npm install @modelcontextprotocol/client@beta

# Go
go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1

# C#
dotnet add package ModelContextProtocol --prerelease
Enter fullscreen mode Exit fullscreen mode

Important compatibility notes from MCP:

  • Stable SDK lines keep working; July 28 is a spec publish date, not a hard kill switch for old traffic
  • v2 Python/TS are major versions you adopt on your schedule
  • Many stacks keep accepting legacy 2025-11-25 handshakes while serving the new revision
  • Pin exact beta versions; public APIs can still move before stable

If you maintain a library that depends on Python mcp, MCP suggests adding an upper bound now (example pattern: mcp>=1.27,<2) so a stable v2 drop does not surprise your users.

A practical 2-week plan for teams

If you already run remote MCP for agents, do this before July 28:

  1. Inventory session assumptions. Sticky sessions? Redis session tables? Long-lived SSE required for confirmations? Those are the migration hotspots.
  2. Stand up a beta branch. Hit real tools, not only hello-world. Especially multi-step tools that elicit user input.
  3. Test behind your real gateway. Confirm round-robin works and that Mcp-Method / Mcp-Name are preserved end-to-end.
  4. Map auth. Consumer OAuth stays default. If you are enterprise, evaluate EMA with your IdP and host (Claude / VS Code / custom).
  5. Scan clients for -32002. Fix error matching early.
  6. Schedule Roots/Sampling/Logging migration inside the 12-month window. No heroics required this sprint.
  7. Keep local fallbacks honest. Local stdio servers and local models still matter for offline and sensitive workflows — the same reason OpenClaw + Ollama setups stay useful even as remote MCP matures.

What this is not

  • Not a free upgrade to better model quality. Models still fail. Agents still need review.
  • Not permission to skip sandboxing and least privilege. Stateless transport does not equal safe tool design.
  • Not a reason to rewrite every server on day one. Dual-stack and deprecation windows exist for a reason.

It is a signal that MCP is being treated as infrastructure: deprecation policy, conformance suite gates, extension track, AAIF/Linux Foundation stewardship, and production transport design.

Bottom line

Agent demos sell the dream. Production needs boring HTTP properties: any-instance routing, cacheable discovery, auditable auth, and traceable calls.

The 2026-07-28 RC is MCP choosing boring on purpose. That is the right move.

If you build coding-agent workflows on Claude-class or multi-model stacks (Sonnet 5 era agents, OpenAI-side tool use, local OpenClaw setups), put this on your infra backlog now — while betas still accept feedback.

Sources

Discussion: Are you running remote MCP today with sticky sessions / shared session stores — or still mostly stdio on the developer laptop? What breaks first when you try the stateless path?

Top comments (0)