MCP's 2026 Roadmap: Server Cards, SSO Auth, Real Scale

What you need to know

The Model Context Protocol's 2026 roadmap, published on 5 March 2026 and reinforced by a fresh blog post this month, reads less like a feature wish-list and more like a confession. The maintainers are openly cataloguing the gaps that have stopped MCP being deployed inside regulated enterprises: stateful sessions that fight load balancers, no machine-readable way for registries to discover what a server actually does, static client secrets in place of proper SSO, and no end-to-end audit trail. The good news is that all four of those gaps now have named Working Groups attached.

• MCP Server Cards — a .well-known metadata document so crawlers, IDEs and registries can learn a server's capabilities without opening a live connection. The single most under-discussed item on the roadmap, and arguably the biggest unlock.
• Scalable session handling — sessions that survive server restarts, scale-out events and load-balancer churn. Today builders fake this with sticky sessions; the roadmap wants it baked into the wire format.
• Enterprise-managed auth — paved paths from static secrets to SSO-integrated flows (Cross-App Access is cited as a direction), with proper gateway and proxy semantics defined.
• Audit trails and observability — end-to-end visibility into what a client requested and what a server did, in a form that feeds existing logging and compliance pipelines.
• No fixed dates — the roadmap is explicit that Working Groups own their own timelines. Treat the four priority areas as commitments to direction, not delivery schedules.

Why this roadmap reads as a maturity signal

MCP went from an Anthropic-launched November 2024 spec to a Linux Foundation project with adoption from OpenAI, Microsoft, Google and Amazon in roughly twelve months. By early 2026, registries told the size of the ecosystem in three different ways: mcp.so lists over 19,700 servers, Smithery curates over 7,000, and PulseMCP maintains a smaller hand-vetted set; the official documentation refers to 500+ public servers. Salesforce, ServiceNow and Workday all adopted MCP across 2025. That is fast.

Fast also means messy. The 2026 roadmap is the first time the maintainers have publicly grouped the production pain into four buckets and assigned each to a Working Group. There is something refreshing about a protocol team writing, in essence, "Streamable HTTP works in development and breaks in production once you put it behind a load balancer." That is the actual quote, almost word for word, from the priority-areas section.

For Indian and UK builders running MCP servers in production today, the roadmap is more useful as a planning document than as a release schedule. It tells you which sharp edges the protocol will smooth, so you can decide which sharp edges to keep working around yourself and which to expect a clean fix for. It also tells you which problems are not on the list — chiefly, the maintainers are not planning to add new official transports this cycle, which has implications for anyone hoping for native gRPC or WebTransport support.

Server Cards: the quiet headline

The headline item in the Transport Evolution priority area is something the roadmap calls MCP Server Cards: a standard for exposing structured server metadata via a .well-known URL, so browsers, crawlers and registries can discover a server's capabilities without connecting to it.

Today, every registry — mcp.so, Smithery, PulseMCP — has to crawl-and-connect to learn what a server does. They spin up a session, enumerate tools and resources, capture descriptions, and tear the session down. That is expensive, slow and lossy: you only see what the server happened to expose to an anonymous client at that moment. A locked-down enterprise server tells the crawler nothing useful, so it never gets indexed; a chatty open server gives away more than the maintainer intended.

Server Cards reframe this as a static-fetch problem. A registry pulls a single JSON document from a well-known URL, learns the server's name, tools, resources, policy hints, contact, version, and supported auth flows, and indexes accordingly. The mental model is robots.txt for AI tooling. An illustrative document might look like this (the spec is still in flight, so treat as illustration, not contract):

GET https://mcp.example.co.uk/.well-known/mcp.json

{
  "schema_version": "2026-draft",
  "name": "Acme Fraud Rules MCP",
  "description": "Read-only access to Acme fraud-rule library and rule-evaluation history.",
  "publisher": { "name": "Acme Bank", "url": "https://acme.co.uk" },
  "contact": "mcp-owners@acme.co.uk",
  "auth": {
    "supported": ["oidc", "client_credentials"],
    "issuer": "https://login.acme.co.uk",
    "scopes": ["fraud:read", "fraud:simulate"]
  },
  "capabilities": {
    "tools": [
      { "name": "evaluate_rule", "description": "Evaluate a rule against a payload." },
      { "name": "list_rules",    "description": "List all active fraud rules." }
    ],
    "resources": [
      { "uri": "fraud://rules/", "description": "Active rule library." }
    ]
  },
  "compliance": {
    "data_residency": "uk-south",
    "audit_endpoint": "https://mcp.example.co.uk/audit"
  }
}

That single document does for MCP servers what package.json did for npm and what the OpenAPI spec did for REST: it turns discovery into a cheap, cacheable, machine-readable operation. Registries become commoditised; the differentiator moves to ranking, curation and trust signals.

Scalability: stateful sessions versus load balancers

The next pillar is more boring and more important. MCP's Streamable HTTP transport, while a leap forward, keeps state on a specific server instance. That state — long-lived sampling streams, in-flight tool calls, queued notifications — has to live somewhere, and where it lives is the instance the client first hit. Put a load balancer in front of three replicas and the next request from that client might land on the wrong instance, with no shared state to fall back on.

The workarounds builders use today are familiar:

• Sticky sessions at the load balancer (cookie-based or IP-hash), pinning a client to one replica. Cheap to configure, painful when that replica restarts.
• Server affinity at the gateway layer, often using a session header. Works for HTTP but breaks elegant retries.
• External session stores (Redis, Postgres) for session state. Adds latency to every request and a new dependency to operate.
• Single-replica deployments behind a wait-queue. The honest answer for many teams, and the one that puts a ceiling on traffic.

The roadmap commits to a protocol-level fix: a next-generation transport that runs statelessly across instances, with a defined session-creation, resumption and migration model. Server restarts and scale-out events should become transparent to connected clients. That is a meaningful unlock for anyone running an MCP server behind an Indian fintech's API gateway or a UK NHS trust's proxy — the kinds of environments where horizontal scale is non-negotiable and sticky sessions are a security review red flag.

Enterprise auth: the unblock for regulated industries

This is the section that matters most for builders in BFSI, healthtech and government. The roadmap names the gap precisely: enterprises want paved paths away from static client secrets and toward SSO-integrated flows, so IT teams can manage MCP access the same way they manage everything else.

Today the auth story is functional but spartan. Most public MCP servers expect either anonymous local connections (Claude Desktop-style) or a static bearer token in a header. That works for a solo developer plumbing tools into Claude or Cursor; it does not work for a Mumbai fintech that needs to expose a fraud-rules MCP server to a fleet of internal Claude agents, each acting on behalf of a different human analyst whose entitlements are managed in Okta. It does not work for a London hospital research team that needs every MCP call to a patient-data tool to carry a verifiable user identity, so the audit log can answer the question "who asked the model to look at this patient on Tuesday?"

The roadmap explicitly cites Cross-App Access as a direction of travel. Pair that with the audit-trails-and-observability priority — end-to-end visibility, in a form that feeds existing logging pipelines — and you can see the shape of the enterprise story coming together. The Enterprise WG that the roadmap expects to form will own much of this, and the maintainers signal that the output will likely land as extensions rather than core spec changes. That is the right call: it keeps the core protocol small and lets regulated buyers consume the bits they need without forcing the whole ecosystem to swallow them.

MCP today vs MCP after the roadmap

Here is how the picture changes across the five dimensions that block enterprise adoption today.

Capability	MCP today (May 2026)	MCP after the roadmap
Server discovery	Registries crawl-and-connect; metadata is whatever an anonymous session reveals	Server Cards via /.well-known/mcp.json; static, cacheable, declarative
Authentication	Static client secrets or anonymous local; OAuth bolted on per server	SSO-integrated flows (Cross-App Access direction), paved paths for IT-managed access
Horizontal scale	Sticky sessions, server affinity, external session stores, single-replica fallbacks	Stateless transport across instances; sessions survive scale-out and restarts
Audit and observability	DIY logging at the server level; no standard end-to-end trace format	End-to-end audit-trail format that feeds existing logging and compliance pipelines
Gateway and proxy	Undefined behaviour for intermediaries; authorization propagation is bespoke	Defined gateway semantics: authorization propagation, session handling, visibility rules
Configuration portability	Configure per client (Claude Desktop, Cursor, Continue, custom) — same server, four files	Configure once, run across clients (extension-shaped, not core)

Concrete dual-market scenarios

Mumbai fintech: a fraud-rules MCP server for internal Claude agents

Picture a payments company in BKC that runs an internal fraud-rules service. Risk analysts already query it through a web UI; the product team wants to expose the same rules to a Claude-based agent that triages alerts. The natural fit is an MCP server in front of the rules service.

Today the blocker is not the protocol — building the server is a weekend job. The blocker is the security review. Risk and InfoSec want every call to carry a verified analyst identity (Okta-managed), they want a tamper-evident audit log for the RBI compliance pipeline, and they want the server to scale horizontally so a Monday-morning fraud surge does not queue behind a single replica. Today the team writes three pieces of custom plumbing: an OIDC proxy, a Kafka audit feed, and a Redis-backed session store. After the roadmap lands, those three become protocol features and the security review collapses from weeks to days.

London NHS research team: patient-data MCP behind a strict audit boundary

A research group at a London teaching hospital wants to give clinical researchers a Claude-powered agent that can pull anonymised cohort data from a patient-data MCP server. The Information Governance committee has two non-negotiables: every call must carry a verifiable researcher identity tied to the trust's SSO, and every call must land in the trust's existing audit log within five minutes.

Today, both are achievable but expensive: an in-house team writes the OIDC bridge, builds an audit shim, and runs it as a separate service in front of the MCP server. Once the Enterprise WG's extensions land, the same controls become standard and portable — meaning a second NHS trust can adopt the same architecture by configuration, not by rebuilding the bridge. That is the kind of compounding that turns MCP from a clever protocol into infrastructure.

How MCP relates to the wider standards landscape

MCP is one of three protocol layers that 2026 will be remembered for. The companion piece on AGNTCY, the open agent-interoperability standard, covers the agent-to-agent layer that sits above MCP. The agent-to-tool layer that MCP itself standardises is increasingly intertwined with structured-output discipline — see our piece on tool-call schema reliability for agents for the schema-design side of the same coin.

For enterprise readers, the governance picture is the third leg. Microsoft's announcement of Agent 365 as the enterprise governance layer for AI teams rhymes with the audit-trails and enterprise-managed-auth pillars on the MCP roadmap: both are admitting that "the protocol works, now make it run inside an enterprise." Anthropic's own Claude Managed Agents public beta is the model-side complement, providing the long-running agent runtime that calls MCP servers. And if you are already orchestrating multiple agents that themselves wrap MCP, multi-agent memory and orchestration with LangGraph covers the layer above that.

The short version: MCP standardises how one agent talks to its tools, AGNTCY standardises how agents talk to other agents, and enterprise governance layers like Agent 365 sit across both. The 2026 MCP roadmap is the first of those three to publicly acknowledge that "what works for a hobbyist in Cursor does not yet work for a UK building society."

What builders should do this quarter

Pragmatic actions for the May-to-August 2026 window:

1. Author a Server Card now, even though the spec is still draft. Treat it as a structured README. When the standard locks, you re-name fields and move on.
2. Move off static bearer tokens. If your server is exposed beyond a single Claude Desktop user, put OIDC in front of it. It is not glamorous; it is the gate to every enterprise pilot.
3. Stand up a real audit pipeline. Even a one-process Kafka producer that logs every tool call with caller, target, args, latency and outcome is enough to pass most first-round security reviews.
4. Plan for stateless servers. If your server holds session state in memory today, factor it into a small adapter layer so you can swap to a shared store when the protocol asks you to.
5. Join the relevant Working Group if your team has bandwidth — Transports, Server Card, Enterprise. The maintainers have said SEPs with Working Group backing move fastest.

The bottom line

The 2026 roadmap is not a feature drop. It is a public acknowledgment, from the maintainers of one of the most adopted AI standards in the world, that the protocol's next year is about plumbing rather than primitives. Server Cards make discovery cheap and rich; SSO-integrated auth and audit trails unblock regulated industries; stateless transport unblocks horizontal scale. None of it is exciting in the way a new model release is exciting. All of it is what turns a clever protocol into infrastructure.

For builders in India and the UK, that is the more interesting kind of news. The official 2026 roadmap blog is at blog.modelcontextprotocol.io, the live priorities document at modelcontextprotocol.io/development/roadmap, and independent coverage at The New Stack.