Model Context Protocol (MCP)

What is the Model Context Protocol?

The Model Context Protocol (MCP) is an open standard that defines how AI applications connect to external tools, data sources, and reusable prompts through a single, uniform interface. Anthropic announced and open-sourced MCP on November 25, 2024; it was created by engineers David Soria Parra and Justin Spahr-Summers. The protocol borrows its message-flow design from the Language Server Protocol (LSP) and runs over JSON-RPC 2.0.

Conceptually, MCP is to AI integrations what a universal port standard is to peripherals: instead of building a custom connector for every pairing of model and system, a developer implements the protocol once and gains interoperability across any compliant client or server. MCP focuses solely on the protocol for context exchange. It does not dictate how an application uses its language model or manages the context it receives.

As of 2026, the most recent stable specification revision is dated 2025-11-25, succeeding the earlier 2025-06-18 revision. Specification revisions are versioned by date, and clients and servers negotiate a mutually supported protocol version during connection setup.

• Open standard introduced by Anthropic in November 2024 (November 25, 2024).
• Runs over JSON-RPC 2.0; design modeled on the Language Server Protocol.
• Latest stable spec revision as of 2026: 2025-11-25 (prior: 2025-06-18).

The M×N integration problem MCP solves

Before a shared protocol existed, connecting M AI applications to N external systems required building and maintaining roughly M×N bespoke integrations. Anthropic described this as an N×M data integration challenge: each application needed a custom connector for each tool or data source, and every new model or system multiplied the work.

MCP collapses this into an M+N problem. Each AI application implements the client side of the protocol once, and each tool or data source implements the server side once. Any compliant client can then talk to any compliant server. This is the same structural win that the Language Server Protocol delivered for code editors and programming languages, which is why MCP is frequently described as the LSP equivalent for AI tooling.

• Without a standard: M clients × N tools means M×N custom connectors to build and maintain.
• With MCP: M clients + N servers, each implementing one shared protocol.
• Servers are reusable across every client; clients gain access to every server.
• Reduces duplicated integration code, version drift, and per-vendor lock-in.

Architecture: hosts, clients, and servers

MCP follows a client-server architecture organized around three roles. The MCP host is the AI application itself, such as Claude Desktop, an IDE extension, or an agent runtime. The host coordinates one or more MCP clients, manages the model's context window, and decides when to invoke external capabilities.

An MCP client is a component inside the host that maintains a dedicated, stateful connection to exactly one MCP server. When a host connects to several servers, it instantiates one client per server. An MCP server is a program that exposes tools, resources, and prompts to clients. Servers can run locally on the same machine as the host or remotely on a network endpoint.

This one-client-per-server design keeps connections isolated, makes capability negotiation explicit, and lets a host compose many independent servers (a filesystem server, a database server, a remote SaaS server) into a single unified set of capabilities for the model.

• Host: the AI application that manages the model and orchestrates clients.
• Client: a connector inside the host, one per server, holding a dedicated connection.
• Server: a program exposing capabilities; runs locally (stdio) or remotely (HTTP).

Core primitives: tools, resources, and prompts

MCP defines three core primitives that servers expose. Tools are executable functions the model can invoke to perform actions, such as querying a database, calling an API, or writing a file. Resources are data sources that supply contextual information, such as file contents, records, or API responses, and are typically read rather than executed. Prompts are reusable templates, including system prompts and few-shot examples, that structure interactions with the model.

Each primitive type has associated JSON-RPC methods for discovery and use: clients call methods like tools/list, resources/list, and prompts/list to discover what a server offers, then invoke them with calls such as tools/call. Because discovery happens at runtime, a server's available capabilities can change dynamically, and servers can emit notifications (for example notifications/tools/list_changed) to tell clients to refresh.

MCP also defines client-side primitives that servers can call on. Sampling lets a server request a model completion from the host so the server stays model-independent. Elicitation lets a server ask the user for additional input or confirmation. Logging lets a server send diagnostic messages to the client. A Tasks primitive for durable, deferred execution is also defined as experimental in recent revisions.

• Tools: model-invocable functions that perform actions (server primitive).
• Resources: readable context data exposed to the application (server primitive).
• Prompts: reusable interaction templates (server primitive).
• Sampling, elicitation, and logging: capabilities servers can request from clients.

Transports and the protocol lifecycle

MCP separates a data layer from a transport layer. The data layer is the JSON-RPC 2.0 message protocol covering lifecycle, primitives, and notifications. The transport layer carries those messages and handles connection setup, framing, and authentication. The same JSON-RPC message format is used regardless of transport.

Two transports are defined. The stdio transport uses standard input and output streams for direct process communication on the same machine, with no network overhead, and is typical for local servers. The Streamable HTTP transport uses HTTP POST for client-to-server messages with optional Server-Sent Events for streaming, supports remote servers, and recommends OAuth for obtaining authentication tokens.

MCP is a stateful protocol with explicit lifecycle management. A connection begins with an initialize request in which the client and server negotiate a protocol version and declare their capabilities, such as which primitives and notifications each supports. The client then sends a notifications/initialized message, after which normal request and response exchange proceeds. If no compatible protocol version is agreed, the connection is terminated.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_documents",
    "arguments": {
      "query": "renewal terms",
      "limit": 5
    }
  }
}

• Stdio transport: standard input/output for local, same-machine servers.
• Streamable HTTP transport: HTTP POST with optional Server-Sent Events for remote servers.
• Lifecycle: initialize request, version and capability negotiation, then notifications/initialized.

MCP versus plain function calling: where each fits

Function calling (or tool calling) is a model capability: an LLM emits a structured request to invoke a developer-defined function, and the application executes it. MCP operates one layer up. It standardizes how the tools, data, and prompts themselves are discovered, described, and connected, independent of any single model or SDK.

The two are complementary rather than competing. A function-calling loop still drives whether and when the model acts; MCP defines the interoperable packaging so the same server works across many hosts without rewriting integration glue. For a single, tightly coupled tool inside one application, direct function calling is often simpler. For tools meant to be reused across multiple AI applications, or for connecting to third-party systems maintained by others, MCP avoids re-implementing the same connector for every host.

• Function calling: a model-level mechanism for invoking a specific function in one app.
• MCP: a transport-agnostic standard for discovering and connecting reusable capabilities.
• Use direct function calling for bespoke, single-app tools.
• Use MCP when servers should be reusable across many clients or shared across vendors.

Adoption and governance (as of 2026)

MCP saw unusually fast uptake after its November 2024 release. OpenAI announced support in March 2025, including integration with the ChatGPT desktop app, and Google DeepMind indicated adoption in April 2025. Microsoft integrated MCP across tooling such as its SDKs and Azure-hosted services. As of 2026, MCP is supported across products including Claude, ChatGPT, Cursor, and Gemini.

On December 9, 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The AAIF was co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg, and its founding projects include MCP alongside Block's goose and OpenAI's AGENTS.md. Under this structure, the foundation governs strategic and budget matters while individual projects such as MCP retain full autonomy over technical direction.

Foundation stewardship was widely read as removing single-vendor risk and placing MCP on a neutral, multi-stakeholder footing comparable to other Linux Foundation projects. As of the December 2025 announcement, MCP reported over 97 million monthly SDK downloads across Python and TypeScript and more than 10,000 active public servers. These adoption figures and the governance arrangements are evolving and should be reverified against current sources.

• Origin: created and open-sourced by Anthropic, November 2024.
• Cross-vendor support: OpenAI (March 2025), Google DeepMind (April 2025), Microsoft, and others.
• Governance: donated to the Linux Foundation's Agentic AI Foundation on December 9, 2025.
• Scale (as of late 2025): over 97M monthly SDK downloads and more than 10,000 active public servers.

Security and trust considerations

Connecting models to live tools and data widens the attack surface, and the MCP ecosystem has developed a recognized threat taxonomy. Prompt injection occurs when hidden instructions embedded in data, tool outputs, or web content hijack the agent. Tool poisoning plants malicious instructions inside tool descriptions or metadata that the model reads but the user may not see. Confused-deputy problems arise when a server acts on a user's behalf with broader privileges than the user holds, a risk amplified by OAuth misconfiguration.

Concrete incidents have reinforced these concerns. In 2025, JFrog disclosed CVE-2025-6514, a critical OS command-injection vulnerability in mcp-remote, a popular OAuth proxy, where a malicious server could trigger remote code execution on the client. The OWASP MCP Top 10 and an OWASP MCP Security Cheat Sheet, both published in 2025, provide structured guidance.

Recommended controls include treating every server and its metadata as untrusted input, pinning and reviewing server versions, scoping OAuth tokens narrowly, requiring user confirmation for sensitive actions (which the elicitation primitive supports), and isolating servers from one another. The 2025-06-18 revision and later updates strengthened authorization, including OAuth-based flows and discovery.

• Prompt injection: hidden instructions in data or tool output hijack the agent.
• Tool poisoning: malicious instructions embedded in tool descriptions or metadata.
• Confused deputy: a server acts with broader privileges than the user, often via OAuth misconfiguration.
• Mitigations: untrusted-input handling, narrow token scopes, user confirmation, and server isolation.

MCP and persistent AI memory

MCP is a natural connection layer for long-term memory: a memory store can be exposed as an MCP server whose resources surface stored context and whose tools handle saving and semantic retrieval, so any compliant client can query it. AI memory and second-brain applications such as MemX, which store documents, photos, and voice notes and retrieve them by plain-English questions using OCR and semantic search, fit this pattern as retrievable context behind a standard interface.

More broadly, MCP standardizes the boundary between a model's transient context window and durable external state, which is precisely the boundary that persistent memory systems must manage.

• A memory store can be exposed as an MCP server: resources surface context, tools handle save and retrieval.
• Any MCP-compliant client can then query the same memory through a standard interface.
• MCP formalizes the boundary between a transient context window and durable external state.