MCP (Model Context Protocol)

Pattern

A named solution to a recurring problem.

Context

At the agentic level, the Model Context Protocol (MCP) is an open protocol for connecting agents to external tools and data sources. It standardizes how an agent discovers available tools, how it invokes them, and how it receives results, regardless of who built the agent or who built the tool.

MCP sits at the intersection of the harness and the tool layer. Before MCP, each harness had its own mechanism for tool integration, meaning a tool built for one harness couldn’t be used with another. MCP provides a common language, similar to how HTTP standardized web communication or how LSP (Language Server Protocol) standardized code editor features.

In late 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation, with co-founding support from OpenAI, Block, Google, Microsoft, AWS, Cloudflare, and Bloomberg. The protocol is now governed as a vendor-neutral open standard.

Two versions matter as of mid-2026. The shipped, stable specification is 2025-11-25. A locked release candidate dated 2026-07-28 is scheduled to become the next final specification, and it contains breaking changes: it removes protocol-level sessions, reworks the connection lifecycle, and moves several core primitives into an extensions mechanism. This article describes the stable baseline first, then the release-candidate direction, so you can build against what is shipped today without being surprised by what lands next.

Problem

How do you connect an agent to the growing world of external tools, data sources, and services without building custom integrations for each combination of agent and tool?

As agentic coding matures, the number of useful tools grows: code search, documentation lookup, database access, CI/CD control, issue trackers, deployment tools. Without a standard protocol, every tool must be integrated separately with every harness. This creates an O(n*m) problem: n tools times m harnesses, each requiring a custom integration.

Forces

Fragmentation: each harness defining its own tool interface prevents tool reuse.
Tool diversity: the range of useful tools is large and growing, making custom integration impractical.
Discovery: the agent needs to know what tools exist and what they can do, dynamically.
Security: connecting to external services introduces trust, authentication, and prompt injection concerns.
Simplicity: the protocol must be simple enough that tool authors actually adopt it.

Solution

MCP defines a standard interface between an agent (the client) and a tool provider (the server). An MCP server exposes one or more capabilities: tools the agent can call, resources the agent can read, or prompts the agent can use. The agent’s harness connects to MCP servers and presents their capabilities to the model as available tools.

The protocol works through a simple lifecycle:

Discovery. The harness connects to an MCP server and asks what capabilities it provides. The server responds with a list of tools, each with a name, description, and input schema.
Invocation. When the model decides to use a tool, the harness sends the call to the appropriate MCP server with the specified parameters.
Response. The server executes the tool and returns the result to the harness, which includes it in the model’s context.

MCP supports two transport mechanisms. Stdio runs the server as a local subprocess, communicating over standard input and output. This is the simplest option for local tools like file access or database queries. Streamable HTTP treats the server as a standard HTTP endpoint, enabling remote MCP servers hosted anywhere on the network. The shift to Streamable HTTP transformed MCP from a local-tool protocol into a remote-service protocol, and the majority of large SaaS platforms now offer remote MCP servers for their APIs.

The stable 2025-11-25 transport keeps a protocol-level session, established through an initialize/initialized handshake and carried in an Mcp-Session-Id header. That session is exactly what the release candidate removes. Under the RC, a stateless server load-balances like any ordinary HTTP service, list and resource results become cacheable, and the transport can propagate trace context across hops. The forward-looking design is stateless, not sessionful; if you are writing a remote server today, keep the session state shallow enough to drop later.

For remote servers, MCP uses OAuth 2.1 for authentication. The MCP server acts as an OAuth 2.1 resource server, accepting access tokens from clients. This means you can protect MCP endpoints with the same identity infrastructure your organization already uses, rather than inventing a proprietary handshake for each tool.

Alongside the in-session discovery step, a draft proposal (SEP-1649) introduces Server Cards: a static capability descriptor that clients would fetch from a well-known URL (/.well-known/mcp/server-card.json) before opening a session. The card summarizes which tools, resources, transports, and auth methods the server offers. This matters at scale. A harness juggling dozens of servers can scan cards in parallel to pick the right one; registries and crawlers can index capabilities without holding open MCP sessions.

What the release candidate changes

The 2026-07-28 release candidate is the largest revision since Streamable HTTP. Six shifts are worth knowing before you build anything you expect to outlive the current spec.

A stateless protocol core. The initialize/initialized handshake and the Mcp-Session-Id header are gone. Protocol version, client info, and capabilities now travel in a _meta field on every request, so there is no hidden connection state to lose or resume. A new server/discover method fetches capabilities upfront, and Streamable HTTP gains two required headers, Mcp-Method and Mcp-Name, so gateways can route traffic without parsing the request body. When a call needs more input, the server returns an explicit result carrying the request state and the client reissues the call, rather than holding a stream open. The practical win is operational: a stateless server load-balances, caches, and traces like any other HTTP service.

An extensions framework. Capabilities that used to live in the core now negotiate as named extensions, identified by reverse-DNS IDs and versioned on their own schedule. The core stays small; specialized features ship without waiting for a whole-protocol release.

Tasks as an extension. In the stable spec, Tasks is an experimental core primitive for asynchronous work. In the RC it graduates into an extension driven by tasks/get, tasks/update, and tasks/cancel, and a tools/call can return a task handle. Notably, tasks/list is removed: without sessions, there is no safe way to scope which tasks a caller may see.

MCP Apps. A server can now return an interactive HTML interface that the host renders in a sandboxed iframe. The user clicks in the rendered UI, but every action still flows through MCP’s JSON-RPC layer, so the same audit and consent path that governs a plain tool call governs a button press. This turns MCP from a text-and-tool protocol into one that can carry a small application surface.

Deprecations with a real policy. The RC introduces a formal lifecycle (Active, Deprecated, Removed) with at least twelve months between deprecation and the earliest removal. Three primitives are deprecated on that clock, annotation-only for now so existing code keeps working: Roots (replaced by tool parameters, resource URIs, or server config), Sampling (replaced by calling an LLM provider’s API directly), and Logging (replaced by stderr for stdio servers or OpenTelemetry for structured logs).

Full JSON Schema 2020-12 for tools. Tool inputSchema and outputSchema move to the complete JSON Schema 2020-12 dialect, so input schemas can use composition (oneOf, anyOf, allOf), conditionals, and references. The extra expressiveness is useful, but it is also a footgun: an external $ref and an unbounded schema are validation and supply-chain risks, so bound what a tool schema is allowed to pull in.

Warning

Do not treat the release candidate as shipped. It is locked as of May 21, 2026 but does not become the final specification until July 28, 2026, and it carries breaking changes: explicit application handles replace hidden protocol sessions, and authorization tightens to require issuer validation and credential binding. If a server you maintain depends on protocol session state, test it against the RC during the window rather than after the cutover. Build against the stable 2025-11-25 spec for anything you ship today, and track the RC for anything you expect to run past the summer.

Tip

When choosing MCP servers for your workflow, start with a small set of high-quality servers that cover your most common needs (file access, code search, and your project’s primary external services). Adding too many servers at once increases the model’s decision space and can degrade tool selection quality.

How It Plays Out

A developer works with a coding agent that needs to query a PostgreSQL database during development. Rather than giving the agent raw SQL shell access, the team installs an MCP server that exposes read-only database queries with schema introspection. The agent can explore tables, run SELECT queries, and understand the data model, but it can’t modify or delete data. The MCP server enforces the boundary.

An open-source community builds an MCP server for a popular project management tool. Any developer using any MCP-compatible agent can now ask their agent to create issues, check project status, or update task assignments. The project management company didn’t build separate integrations for every coding assistant. One MCP server covers them all.

Example Prompt

“Connect to the PostgreSQL MCP server and explore the schema. Show me the tables related to orders, then write a read-only query that finds all orders placed in the last 24 hours with a total over $100.”

Consequences

MCP turns the tool ecosystem from a fragmented collection of custom integrations into an interoperable network. Tool authors build once and reach every MCP-compatible agent. Agent developers get access to a growing library of tools without building integrations. With over 97 million monthly SDK downloads, thousands of active servers, and first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code, MCP has become the dominant standard for agent-tool communication.

The cost is the indirection of a protocol layer. MCP servers must be installed, configured, and maintained. For remote servers, authentication and authorization add operational complexity. And because MCP servers accept input shaped by model output, they are a primary prompt injection attack surface. Tool-poisoning attacks (where a compromised server injects malicious instructions into tool descriptions) and rug-pull attacks (where a server changes behavior after initial trust is established) are documented threats. OWASP published an MCP Top 10 security guide in early 2026. Treating MCP servers with the same skepticism you’d apply to any external dependency is the right default.

A few pieces of the protocol are still in motion. In the stable spec, the Tasks primitive is experimental: retry semantics on transient failure and expiry policies for completed-task results are active areas of work, not settled rules. The release candidate reshapes Tasks into an extension with a stateless lifecycle, which changes the method surface out from under any code that targeted the experimental version. If you’re building on Tasks today, treat it as a preview and design your code so the contract can shift under you.

Sources

Anthropic introduced MCP in November 2024 as an open protocol for connecting AI agents to external tools and data, modeled on the Language Server Protocol’s success in standardizing editor-to-language-server communication.

The Agentic AI Foundation (AAIF), formed under the Linux Foundation in December 2025, now governs MCP as a vendor-neutral standard, with co-founding members including Anthropic, OpenAI, Block, Google, Microsoft, AWS, Cloudflare, and Bloomberg.

The March 2025 specification update introduced Streamable HTTP as a transport, transforming MCP from a local-tool protocol into one capable of remote server communication. OAuth authorization followed in a separate June 2025 update, adding enterprise-grade authentication for remote endpoints.

The November 2025 specification (2025-11-25) introduced the experimental Tasks primitive for asynchronous tool execution with status tracking and result retrieval, along with enhanced OAuth and an extensions mechanism. This was the first major release under AAIF governance.

The 2026 MCP roadmap, published by lead maintainer David Soria Parra in March 2026, names four priority areas for the year. Transport evolution and scalability focuses on horizontal scaling for Streamable HTTP and standard metadata formats like Server Cards. Agent communication targets the unsettled corners of the Tasks primitive: retry semantics and result-retention policy. Governance maturation streamlines the SEP review process and delegates specialized work to trusted working groups. Enterprise readiness covers audit trails, SSO-integrated auth, and configuration portability so large organizations can adopt the protocol without special casing.

The 2026-07-28 release candidate, announced May 21, 2026 and locked that day, is where the roadmap’s transport and governance work lands. It removes protocol-level sessions, moves lifecycle metadata into per-request _meta, and adds the server/discover method with Mcp-Method and Mcp-Name routing headers. It also introduces the extensions framework, graduates Tasks into an extension, adds MCP Apps, deprecates Roots, Sampling, and Logging on a formal twelve-month clock, and moves tool schemas to full JSON Schema 2020-12. The AAIF’s “MCP is growing up” explainer, published May 27, 2026, walks through why statelessness and the extensions model matter for scale. The final specification is scheduled for July 28, 2026; until then, the candidate is locked but not authoritative.

Keyboard shortcuts