Model Context Protocol (MCP) Guide 2026: Complete Reference

What is the Model Context Protocol (MCP)?

In short

The Model Context Protocol is an open JSON-RPC protocol for connecting LLM applications to tools, resources, and prompts. Anthropic released it on 2024-11-05 and donated it to the Linux Foundation Agentic AI Foundation on 2025-12-09, with co-sponsorship from Block, OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg.

MCP is the answer to a specific problem: before it existed, every agent framework and every LLM vendor invented its own way to describe tools, pass parameters, and surface results. That N-by-M integration matrix was blocking enterprise agent projects because a tool built for one client had to be rewritten for each new model or framework.

The protocol standardises three primitives — tools (side-effect operations, function-call style), resources (GET-style context loaders that return documents or data), and prompts (reusable prompt templates) — and defines the JSON-RPC message shapes for discovering and invoking each.

Anthropic open-sourced the first specification on 2024-11-05 alongside reference SDKs in Python and TypeScript. The 2025-11-25 revision hardened OAuth. The 2025-12-09 governance transfer moved MCP into the Linux Foundation Agentic AI Foundation (AAIF), where a vendor-neutral technical steering committee now owns the roadmap.

By the end of 2025 the ecosystem reported 97M+ monthly SDK downloads and 10,000+ active public servers. Alice Labs has shipped 100+ production AI implementations that use MCP-based tool servers across enterprise clients since 2024, and MCP is now our default integration layer whenever tools must be reused across models or agent frameworks. For a wider view of the frameworks that consume these servers, see our best AI agent frameworks guide for 2026.

MCP spec 2026: what the 2026-07-28 release changed

In short

The 2026-07-28 spec makes MCP stateless: no initialize/initialized handshake, no Mcp-Session-Id, mandatory Mcp-Method on every request, mandatory Mcp-Name on tools/call, resources/read, and prompts/get, plus Multi Round-Trip Requests (MRTR) for mid-call user confirmations.

The release candidate locked on 2026-05-21 and the final specification was published on 2026-07-28. It is the third major revision of MCP and the first governed under the AAIF SEP (Specification Enhancement Proposal) process.

The delta from the 2025-11-25 revision is deliberate and narrow:

• Handshake removed. The initialize / initialized round trip is gone. Protocol version, client info, and capabilities are self-contained in the _meta field of every request.
• Session header removed. Mcp-Session-Id is deprecated. Any request can land on any instance behind a plain load balancer.
• Two new headers. Mcp-Method is required on every request. Mcp-Name is required on tools/call, resources/read, and prompts/get. Gateways can now route and authorize on headers alone without parsing JSON bodies.
• MRTR. Multi Round-Trip Requests introduce resultType: "input_required" so a tool can pause for a user confirmation without holding an SSE stream open for the entire wait.
• Deprecation policy. A formal 12-month minimum deprecation window is now written into the spec, so SDK maintainers can plan upgrades against a calendar rather than a rumour.

Tasks, Roots, Sampling, and Logging moved out of the core into the extensions framework with reverse-DNS identifiers (io.modelcontextprotocol/*). Anything you were relying on there needs to be migrated before the 12-month window closes.

How the stateless MCP protocol layer works

In short

Every 2026-07-28 request self-contains protocol version, client info, and capabilities in _meta. Servers deploy behind round-robin load balancers, Cloud Run, Lambda, and edge runtimes with no sticky session requirement — the single most-requested change from teams running MCP in production.

The 2025 spec required a per-connection session: clients called initialize, the server minted an Mcp-Session-Id, and every subsequent request had to land on the same instance. Operators running MCP on Kubernetes, Cloud Run, or Lambda had to either shard by session ID, maintain a shared session store, or pin traffic with sticky sessions.

The 2026-07-28 spec deletes all of that. A request looks like this on the wire:

POST /mcp HTTP/1.1
Mcp-Method: tools/call
Mcp-Name: search_customers
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "req-1",
  "method": "tools/call",
  "params": {
    "name": "search_customers",
    "arguments": { "region": "SE", "segment": "enterprise" }
  },
  "_meta": {
    "protocolVersion": "2026-07-28",
    "client": { "name": "claude-desktop", "version": "2026.7" },
    "capabilities": { "tools": {}, "resources": {} }
  }
}

Because everything the server needs to reason about the request is in the request itself, deployment topology collapses. Alice Labs migrated four enterprise MCP servers to Cloud Run in the release-candidate window and saw p95 latency drop 30–45% purely from removing session pinning and its associated in-memory state.

The same statelessness makes gateways trivial. A router at the edge can authorize theMcp-Method header, dispatch tools/call to one autoscaling group and resources/read to another, and rate-limit byMcp-Name — all without deserialising the JSON body.

MCP cache scoping: ttlMs and cacheScope explained

In short

SEP-2549 added ttlMs and cacheScope fields to tools/list, prompts/list, resources/list, and resources/read responses. Semantics mirror HTTP Cache-Control — cacheScope determines whether responses are shareable across users or user-specific, and ttlMs gives a hard invalidation clock.

Before SEP-2549, the only reliable way to know that a server's tool list had changed was to keep a long-lived SSE stream open and wait for a tools/list_changed notification. That forced every host to hold a connection per server per user — an expensive default that also broke behind CDN edges.

The 2026-07-28 response shape now includes cache directives:

{
  "jsonrpc": "2.0",
  "id": "req-2",
  "result": {
    "tools": [ ... ],
    "_meta": {
      "ttlMs": 300000,
      "cacheScope": "user"
    }
  }
}

cacheScope: "public" means the response is identical for every user of the server and can be shared across an entire team — perfect for a tool list that only depends on the server's own configuration. cacheScope: "user" pins the cache entry to the authenticated principal, so a per-user resource list never leaks across identities.

The practical result: clients that fan out across dozens of MCP servers on cold start (Claude Code, VS Code, Copilot, the Claude Agent SDK) can pre-warm caches for a known TTL window and skip an entire round trip on subsequent invocations. Alice Labs measured client cold-start reductions of 400–900 ms across a 12-server fleet after enabling a 5-minute public TTL on stable tool lists.

MCP vs function calling: when to use which

In short

Function calling is the model-side mechanism — the LLM emits a structured JSON tool_call. MCP is the protocol layer that standardises how that call is discovered, executed, and returned across processes and vendors. They compose: an MCP server exposes tools; the model invokes them via function calling under the hood.

The confusion is understandable — both concepts revolve around structured tool invocation — but they operate at different layers.

Function calling is a model behaviour. Given a tool schema in the prompt, the model can emit a JSON tool_call instead of natural language. It couples the tool set to a single application loop, running in the same process as the model client.

MCP is a protocol. It defines how a client discovers what tools are available on a remote server, how it authorises the call, how it invokes it, and how it returns the result — across processes, machines, and vendors. The server implements the tools; any compliant client can find and call them.

MCP vs native function calling: decision matrix

The two also compose. Under the hood, when a Claude or GPT client invokes a tool from an MCP server, the model still emits a function call — the MCP client just translates that into a tools/call JSON-RPC request. The Alice Labs rule of thumb: fewer than 10 tools and a single team owns the whole stack, native function calling is fine; anything that needs to be reused across teams, models, or clients belongs behind an MCP server.

Anthropic MCP and the wider ecosystem in 2026

In short

Anthropic originated MCP and ships it in Claude Desktop, Claude.ai, and Claude Code. OpenAI added full MCP client support in ChatGPT in late 2025. Google shipped official MCP support and a managed Gemini remote server mid-2026. Microsoft ships MCP in VS Code, Copilot, and the Microsoft Agent Framework (RC 2026-02-19).

The 2026 ecosystem is genuinely multi-vendor. Every major LLM client now speaks MCP, which is the reason we recommend it as the default integration layer for enterprise tools:

• Anthropic — originator (2024-11-05). MCP is native in Claude Desktop, Claude.ai, and Claude Code. The Claude Agent SDK is the reference client used to validate SDK compliance against the 2026-07-28 spec.
• OpenAI — full MCP client support in ChatGPT since late 2025. Custom connectors and the Responses API both accept MCP servers.
• Google — official MCP support for Google services plus a managed remote server for Gemini shipped mid-2026.
• Microsoft — VS Code, GitHub Copilot, and the Microsoft Agent Framework (release candidate 2026-02-19) all ship MCP support. Microsoft co-sponsors the AAIF.
• AWS — Bedrock AgentCore Gateway supports the 2026-07-28 spec as a managed MCP gateway with unified logging and IAM.

Alice Labs is an Anthropic Partner. Our reference architecture pairs Claude Agent SDK clients with EMA-enabled MCP servers behind an enterprise IdP, but the same servers work unchanged for a customer that later switches to Copilot or Gemini — which is the entire point of standardising on the protocol layer.

MCP servers: registry, discovery, and 2026 counts

In short

The official MCP Registry API held 9,652 latest server records as of 2026-05-24. Independent Nerq census counted 17,468 servers across all registries in Q1 2026, and Glama alone indexes close to 20,000 servers by 2026.

Growth in the server ecosystem is the leading indicator that MCP has crossed the adoption chasm. First-party servers cover Anthropic, Google Drive, Slack, GitHub, Postgres, Filesystem, Puppeteer, and Sentry. Enterprise ISVs have followed: Atlassian, Linear, Snowflake, Salesforce, ServiceNow, Okta, Supabase, Notion, Cloudflare, and Stripe all ship official servers.

MCP server registry counts, 2026

The Alice Labs shortlist we work through with enterprise clients is deliberately small: Atlassian, Linear, Snowflake, Salesforce, ServiceNow, and Okta cover 70% of the day-one integrations. Everything else is a domain-specific server we build against the client's own system of record. Discovery is done via the MCP Registry API's contract, which we mirror inside the corporate boundary as a private registry — see the enterprise patterns section below.

MCP implementation: build your first stateless server in Python

In short

Install the Python SDK with `uv add "mcp[cli]"`, declare tools, resources, and prompts with decorators, and run over Streamable HTTP for remote deployment or stdio for local process integration. The 2026-07-28 spec-compliant SDK is v2.

The Python SDK is the fastest path to a working server. Install it with either uv or pip:

uv add "mcp[cli]"
# or
pip install "mcp[cli]"

A minimal stateless server exposing one tool, one resource, and one prompt looks like this:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP(
    name="customer-lookup",
    version="1.0.0",
    protocol_version="2026-07-28",
)

@mcp.tool()
def search_customers(region: str, segment: str) -> list[dict]:
    """Return customers filtered by region and segment."""
    # Real implementation calls your CRM here
    return crm_client.query(region=region, segment=segment)

@mcp.resource("customer://{customer_id}")
def customer_record(customer_id: str) -> str:
    """Return a single customer record as JSON."""
    return crm_client.get(customer_id).to_json()

@mcp.prompt()
def account_review(customer_id: str) -> str:
    """Prompt template for a quarterly account review."""
    return f"Draft a quarterly review for customer {customer_id} using the customer://{customer_id} resource."

if __name__ == "__main__":
    # Streamable HTTP for remote deployment
    mcp.run(transport="streamable-http", host="0.0.0.0", port=8080)

Three primitives, three decorators. The SDK handles JSON-RPC framing, the mandatory Mcp-Method and Mcp-Name headers, and the _meta envelope. Streamable HTTP is the default transport for remote servers; stdio remains for local process integration (Claude Desktop, VS Code local extensions, CI runners).

The Alice Labs template pins the Python SDK to v2 and runs each server as a stateless FastAPI-style app on Cloud Run with a 60-second cold-start budget and a 1 GiB memory floor. TypeScript, Go, C#, and Rust SDKs shipped 2026-07-28-compliant beta releases in the same window and can be substituted without protocol changes.

MCP authorization 2026: OAuth 2.1, EMA, and enterprise SSO

In short

Any internet-accessible MCP server must implement OAuth 2.1 with PKCE (S256) since the 2025-11-25 revision. The 2026-07-28 spec adds RFC 9207 issuer validation and replaces Dynamic Client Registration with Client ID Metadata Documents (CIMD). Enterprise-Managed Authorization (EMA) uses ID-JAG token exchange for zero per-app OAuth.

Authorization is the layer that decides whether MCP graduates from developer tool to enterprise infrastructure. The 2026 spec is unambiguous about the rules:

• OAuth 2.1 with PKCE (S256) is mandatory for any server reachable over the internet. No API keys, no basic auth.
• Resource-server only. The MCP server validates tokens but does not issue them. The authorization server is external — typically the corporate IdP.
• RFC 9207 issuer validation. Servers must verify the token's issuer matches the expected authorization server URL, closing a class of confused-deputy attacks that surfaced in 2025.
• Client ID Metadata Documents (CIMD). Replaces Dynamic Client Registration. Clients advertise a metadata URL; servers fetch and cache it. This stops the drive-by client-registration abuse pattern that the OAuth working group flagged in early 2026.

Enterprise-Managed Authorization (EMA) is the extension that unlocks large-scale rollout. Instead of every user completing a per-app OAuth flow, the corporate IdP mints an Identity Assertion JWT Authorization Grant (ID-JAG) token that the MCP server exchanges for a server-scoped access token. Users get connected servers on first SSO with no per-app consent screen.

EMA is now stable. Adopters include Anthropic (Claude), VS Code, Okta, Asana, Atlassian, Canva, Figma, Linear, and Supabase. Okta is the first supported IdP; Entra ID and Google Workspace are on the public roadmap.

For enterprise buyers, the practical implication is that MCP is now provisionable the way SaaS apps are: the security team owns the IdP, the AI platform team publishes the server, and users see the server appear inside Claude or Copilot without ever touching an OAuth consent page.

MCP Apps: server-rendered interactive UI as a first-class primitive

In short

MCP Apps was proposed 2025-11-21 as SEP-1865 and shipped as the first official MCP extension on 2026-01-26. Servers ship HTML interfaces that hosts render in sandboxed iframes; UI-initiated actions traverse the same JSON-RPC consent path as direct tool calls.

MCP Apps addresses a real limitation: some workflows are too rich for a chat transcript. A form with conditional fields, a table with inline actions, or a chart the user needs to interact with all require a UI surface — and MCP Apps gives servers one.

Servers declare UI templates ahead of time, which lets hosts prefetch them, cache them, and put them through a security review before they ever render. The host loads each template inside a sandboxed iframe with a restricted CSP. Every user action inside the iframe traverses the same JSON-RPC consent and audit path as a direct tool call — so the security and governance model is unified.

In the 2026-07-28 spec, MCP Apps was folded into the extensions framework alongside Tasks and Roots. Extensions now get reverse-DNS identifiers (com.example.forms/v1), their own repositories, delegated maintainers, and independent versioning. That decoupling means an extension can iterate on a faster cadence than the core spec without destabilising it.

For enterprise use cases, MCP Apps is what makes it realistic to embed approval workflows, purchase-order builders, or ticket-triage forms directly inside a Claude or Copilot conversation while keeping every action auditable through the same protocol surface as programmatic tool calls.

MCP support across agent frameworks: LangGraph, CrewAI, MAF, Claude Agent SDK

In short

CrewAI supports all three transports (stdio, SSE, Streamable HTTP) inline. LangGraph wraps MCP clients in graph nodes and exposes agents via /mcp. The Microsoft Agent Framework RC (2026-02-19) ships bidirectional MCP + A2A. The Claude Agent SDK is the reference client for stateless server testing.

The reason Alice Labs standardises on MCP for the tool layer is that it survives framework migrations. Every major agent framework in 2026 ships a native client:

• CrewAI — inline server declarations, all three transports, automatic connection lifecycle. Fastest path from a new server to an agent that uses it.
• LangGraph — MCP clients wrap inside graph nodes; the LangGraph Agent Server also exposes agents themselves via a /mcp endpoint, turning any graph into an MCP server for other clients. See our LangGraph tutorial for 2026 for the full graph and state model.
• Microsoft Agent Framework — RC on 2026-02-19 shipped native bidirectional MCP support alongside Google's A2A protocol.
• Claude Agent SDK — the reference client for 2026-07-28 spec validation. MCP support ships in the Python and TypeScript packages.

The Alice Labs production stack routes every tool discovery through MCP regardless of which client framework the client team prefers. When a customer swaps from CrewAI to LangGraph or vice versa mid-project — and it happens more often than framework marketing suggests — the tool servers keep working without a change.

For a broader comparison of the frameworks themselves, see our best AI agent frameworks guide for 2026 or the head-to-head LangGraph vs CrewAI vs AutoGen breakdown.

MCP security: tool poisoning, prompt injection, and enterprise controls

In short

2026 disclosures identified up to 200,000 vulnerable MCP instances across IDEs, internal tools, and cloud services. Trend Micro found 492 public servers with zero authentication; Check Point disclosed RCE in Claude Code via poisoned repo config files. OWASP now catalogues MCP Tool Poisoning as a distinct attack class.

Security is where MCP deployments succeed or fail in the enterprise. The threats are well-catalogued and specific to the protocol:

• Tool poisoning. An attacker hides adversarial instructions inside tool metadata (descriptions, parameter docs) that the model reads on tools/list but the user never sees. Persistent across every session. OWASP classified this as a distinct attack class in 2026.
• Unauthenticated servers. Trend Micro's 2026 scan identified 492 public MCP servers with zero authentication in place, exposing internal databases, filesystems, and cloud APIs.
• Config-file RCE. Check Point disclosed a Claude Code remote-code execution chain triggered by a poisoned .mcp.json in a public repo the user cloned. Any tool that reads repo-scoped config is in scope.
• Prompt injection. Data returned from a resource can carry instructions that hijack the agent — a general LLM problem, but MCP amplifies it by making arbitrary external data trivially accessible.

The Alice Labs MCP deployment checklist is short and non-negotiable:

1. Tool allow-listing at the client level. No client automatically installs every tool a server advertises.
2. IdP-bound identity per call via EMA. Every action is attributable to a real user.
3. Signed tool manifests. The server publishes a signed digest of its tool set; the client verifies before invoking.
4. Static metadata scan on every server upgrade. Automated diff of tool descriptions and parameters against the previous version, flagging anything that looks like an instruction.
5. Human-in-the-loop on write operations. Any tool that mutates state requires an explicit user confirmation before execution.

For EU AI Act compliance, MCP's audit trail (every JSON-RPC call is loggable, attributable to an OAuth principal, and time-stamped) satisfies the Article 12 logging obligation. Document your interrupt and allow-list policy in your conformity assessment.

MCP deployment patterns for the enterprise

In short

Three enterprise patterns dominate: domain server per system of record with EMA and scoped OAuth resource indicators, gateway aggregation fronting multiple domain servers, and a private registry inside the corporate boundary using the official Registry API contract.

After 100+ production AI implementations, Alice Labs converges on three deployment patterns for MCP inside the enterprise. Every project uses one, some use two, none of our production deployments deviate from the set.

Alice Labs enterprise MCP patterns

The Alice Labs baseline SLO for every server we ship: p95 tools/list under 200 ms cold; p95 tools/call under 1.2 s excluding downstream API time. Every server ships with an OpenTelemetry exporter and a synthetic tool named build_metadata that returns commit SHA, build timestamp, and dependency digests — the supply-chain audit trail is a JSON-RPC call away.

For teams weighing whether to build this in-house or bring in external delivery, our build vs buy AI guide lays out the decision framework we run through with clients.

Migrating from stateful MCP (2025) to stateless MCP (2026-07-28)

In short

Migration is mechanical: remove initialize/initialized, hoist capability negotiation into per-request _meta, delete Mcp-Session-Id, add Mcp-Method and Mcp-Name, move Tasks/Roots/Sampling/Logging to their extension packages, swap Dynamic Client Registration for Client ID Metadata Documents, and add ttlMs/cacheScope to list endpoints.

The 12-month deprecation window starts on 2026-07-28. Every production server needs to migrate before 2027-07-28. The steps, in the order Alice Labs runs them:

1. Delete the handshake. Remove initialize and initialized handling. Hoist capability negotiation into per-request _meta.
2. Delete session state. Remove any code that reads or writes Mcp-Session-Id. Purge session stores.
3. Enforce new headers. Add Mcp-Method validation on every request and Mcp-Name validation on tools/call, resources/read, and prompts/get.
4. Migrate extensions. Move Tasks, Roots, Sampling, and Logging consumers to their io.modelcontextprotocol/* packages.
5. Swap client registration. Replace Dynamic Client Registration with Client ID Metadata Documents. Publish a metadata URL, update client configs.
6. Add cache directives. Emit ttlMs and cacheScope from every list endpoint. Default to user scope unless you have proven the response is principal-independent.
7. Add issuer validation. Enforce RFC 9207 in the OAuth resource-server layer.
8. Deploy stateless. Redeploy behind a round-robin load balancer. Delete any sticky-session config. Measure p95 before and after.

In the release-candidate window Alice Labs migrated four servers in an average of two engineering days each. The bulk of that time was refactoring the OAuth layer for RFC 9207 and CIMD — the header changes and handshake removal took hours, not days.

MCP roadmap after 2026-07-28: what to build against next

In short

AAIF TSC governs post-2026-07-28 evolution with vendor-neutral SEPs. Priority themes: agent-to-agent (A2A) alignment, permissioned discovery for private registries, richer async Tasks semantics, and a first-class observability schema. Next spec cadence expected quarterly.

With MCP now living inside the AAIF, the evolution model is closer to the way CNCF or the IETF runs specs: a Technical Steering Committee owns the roadmap, and every substantive change is a Specification Enhancement Proposal (SEP) that ships against a named release candidate.

Public priority themes for the next 12 months:

• Agent-to-Agent (A2A) alignment. Bidirectional message shapes so an MCP server can also act as a peer to other agents, closing the gap between MCP and Google's A2A protocol.
• Permissioned discovery. Private registries need a spec-blessed way to authorise discovery per user, replacing the ad-hoc approaches vendors have shipped so far.
• Richer async Tasks semantics. Long-running server-initiated work (imagine a batch report that takes hours) needs first-class progress and cancellation.
• Observability schema. A shared shape for tracing, metrics, and audit logs so gateways and hosts can aggregate across servers without bespoke integration.
• Deprecation. Roots, Sampling, and Logging leave the core on 2027-07-28. Clients using them should migrate now to the extension packages.

The pace to expect is quarterly release-candidate windows with SDK maintainers validating against a stable target. For teams building on MCP today, that cadence is the strongest signal that the protocol has matured from experimental to durable — it is now safe to build a five-year integration strategy around it.