What Is Model Context Protocol (MCP)? The Definitive 2026 Guide

What is Model Context Protocol (MCP)?

The Model Context Protocol is an open standard that lets an AI application connect to external tools and data through one common interface, rather than through a separate custom integration for each system. It defines a shared language, so an AI application can discover what a tool offers, describe it to a model, invoke it, and use the result, all through the same protocol regardless of who built the tool.

The most useful analogy, and the one its creators use, is that MCP is a USB-C port for AI. Before USB-C, every device needed its own cable and connector. Afterward, one standard port connected everything. MCP plays the same role for AI: it is a universal connector between the AI application on one side and the tools, files, and services on the other. An application that speaks MCP can use any tool that speaks a compatible version of MCP, subject to the usual constraints of capabilities, transport, and authorization.

It is important to place MCP correctly in the stack. MCP is not a model, not an agent, and not a model provider's function-calling API. It is an application-level interoperability protocol. A large language model provides the reasoning, the host application decides how tools are presented to that model, function calling is how the model represents a request to invoke one, and MCP standardizes how the application discovers and reaches the external system that actually performs the work.

In short: MCP is the open, universal standard that connects AI applications to external tools and data, the plug that lets a tool built once be reused across many AI clients.

What problem does MCP solve?

MCP solves the integration explosion that appears whenever many AI applications need to connect to many tools. This is known as the M times N problem, and it is the reason a standard became necessary.

Consider the situation before MCP. If you have M AI applications and N tools, and every application needs its own custom connector to every tool, you end up building M multiplied by N integrations. With twenty agent frameworks and fifty tool providers, that is a thousand separate connectors, each written, tested, and maintained by hand. Worse, every new tool has to be rebuilt for every application, and every new application has to be rebuilt for every tool. The cost grows as a product, not a sum.

MCP changes the shape of the problem. When every application and every tool speaks one shared protocol, each side only implements that protocol once. The twenty applications implement MCP once each, the fifty tools implement it once each, and they interoperate. The integration burden drops from M times N to M plus N, from a thousand connectors to seventy. This is the same move that standards like USB, HTTP, and the shipping container made in their own domains. MCP does not eliminate integration work, an MCP server still has to be built for a given tool, but that work is done once and reused rather than repeated for every client.

How does MCP work?

MCP works through a client-server architecture with three participants: a host, one or more clients, and one or more servers, communicating over JSON-RPC. Understanding how these fit together, and where the model sits relative to them, explains the whole protocol.

The important conceptual point is that a model does not connect directly to a tool. The chain runs from the model, through the host application, to an MCP client inside that host, across the protocol to an MCP server, and finally to the underlying system. The host and its client sit in the middle precisely because MCP is an application interoperability protocol, not a wire between a model provider and an external service.

All communication between clients and servers uses JSON-RPC 2.0, a lightweight, well-established messaging format. The protocol is organized into two layers. The data layer defines the messages themselves, how a client and server negotiate capabilities and how tools, resources, and prompts are described and invoked. The transport layer defines the channel those messages travel over. Keeping these separate is deliberate, because a server author writes the capabilities once and can expose them over whichever transport suits the deployment without changing any tool logic.

In short: an MCP host runs one client per server, the model reaches tools only through that host and client, and clients and servers exchange JSON-RPC messages across a transport.

What are MCP hosts, clients, and servers?

MCP defines three roles, and the fastest way to understand the protocol is to define each one precisely and see how they relate.

An MCP host is the AI application the person actually uses, such as Claude Desktop, an AI code editor like Cursor, or a custom agent platform. The host is the coordinator: it runs or connects to the model, enforces user permissions and consent, and decides which servers to connect to.

An MCP client is a connector component that lives inside the host. The host creates one client for each server it wants to talk to, and each client maintains a single dedicated connection and manages the JSON-RPC exchange on that link. If a host connects to three servers, it runs three clients.

An MCP server is an external program that exposes capabilities in the standard MCP format. A server implements or brokers what it exposes: it may perform an operation itself, or it may translate the MCP request into calls to an underlying API, database, filesystem, or business system. Servers can run locally on the same machine as the host or remotely across a network.

In short: the host is the AI application, the client is the per-connection component inside it, and the server exposes the tools and data, with the host running one client for each server.

What are MCP tools, resources, and prompts?

MCP is built from a small set of building blocks called primitives, and the core server primitives are tools, resources, and prompts. These are the vocabulary of what a server can offer.

• Tools are executable actions the model can invoke, and they may have side effects, such as sending an email, creating a record, or running a query. Tools are model-controlled: the AI decides when to call them. This is the primitive most people mean when they talk about MCP.
• Resources are read-only data that provide context to the model, such as a file, a document, or a database row. Resources are application-controlled and carry no side effects, they simply supply information.
• Prompts are reusable, templated instructions a server offers to guide how its capabilities are used. Prompts are user-controlled, often surfaced as ready-made commands a person can pick.

A tool is described with a schema so a model knows how to call it. As of the 2026-07-28 specification, those schemas use full JSON Schema 2020-12. A minimal tool definition looks like this:

{
  "name": "search_orders",
  "description": "Search a customer's orders by ID",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string" }
    },
    "required": ["customer_id"]
  }
}

MCP standardizes how that capability is described, discovered, and invoked. The underlying server determines what actually happens when it is called. Beyond the server primitives, MCP includes elicitation, an interaction capability that lets a server request additional input from the user during an operation, such as a confirmation or a missing detail. In the 2026 specification, this kind of server-initiated request is carried through the Multi Round-Trip mechanism rather than a persistent bidirectional stream.

In short: an MCP server exposes tools, resources, and prompts, with elicitation for requesting user input, while the older Roots, Sampling, and Logging capabilities are now deprecated in favor of newer patterns.

How does MCP communicate?

MCP communicates over one of two transports, and as of the 2026 specification the protocol core is stateless. The transport is the channel the JSON-RPC messages travel over, and the choice depends on where the server runs.

Standard input and output (stdio) is used when the server runs locally on the same machine as the host. The host launches the server as a subprocess and exchanges messages through its input and output streams. There is no network involved, which makes stdio fast and simple, and it is how a desktop application runs a local server such as one that reads your files.

Streamable HTTP is used for remote servers reached over a network. The client sends messages by HTTP POST, and the server can stream responses back. As of the 2026-07-28 specification, Streamable HTTP uses the stateless protocol core and no longer relies on the previous session-based handshake, and the older HTTP with server-sent events transport is deprecated.

Two 2026 changes are worth calling out because they replace mechanisms that older MCP explainers still describe. First, the initialize and initialized handshake that used to open every connection is gone. Clients now attach the protocol version to each request and use a new server/discover call to learn a server's supported versions and capabilities before interacting with it. Second, when a server needs more input mid-operation, it uses Multi Round-Trip Requests instead of a persistent open stream: the server returns a result marked "input required" along with an opaque request-state token, the client gathers the requested information, and the client calls the same tool again with the responses attached.

A subtle but important point: statelessness applies to the protocol, not to the application. Removing sessions does not mean an MCP application cannot maintain state. An application can still preserve workflow state explicitly, for example by returning a task_id or basket_id that the client passes back on the next call. What the 2026 specification removed is state maintained by the MCP protocol itself, which is why a stateless server can now sit behind ordinary load balancers without shared session storage.

In short: MCP uses stdio locally and stateless Streamable HTTP remotely, replaces the old handshake with server/discover, and carries mid-operation input requests through Multi Round-Trip Requests.

What changed in MCP in 2026?

The 2026-07-28 specification is the largest revision in MCP's history, and its central change is the removal of the stateful session model in favor of a stateless core. As of August 2026, the current MCP specification is 2026-07-28, published by the Agentic AI Foundation. This release is what turned MCP from a protocol that worked beautifully on a developer's laptop into one enterprises can run behind their existing infrastructure.

Under the earlier design, every connection opened with an initialize handshake that established a stateful session. That statefulness was the quiet blocker to serious deployment, because it forced every load balancer, gateway, and retry to pin a client to one specific server instance. The stateless core removes that constraint, so requests no longer depend on protocol-level session affinity or shared session storage and a server can scale horizontally like any other stateless web service.

A few of these deserve a note. Full JSON Schema 2020-12 lets tool input and output schemas use rich validation and composition such as oneOf, anyOf, allOf, conditionals, and references, and structured output is no longer limited to a plain object. The extensions framework lets capabilities evolve independently of the protocol core, and its first two official extensions are MCP Apps and Tasks. Authorization was hardened across several proposals, bringing MCP into closer alignment with mainstream OAuth 2.1 and OpenID Connect deployments, including issuer validation, with an enterprise-managed authorization extension for stronger identity assurance. Finally, a formal feature lifecycle now classifies every feature as Active, Deprecated, or Removed, and requires a deprecated feature to remain available for at least twelve months.

One clarification prevents a common confusion: the specification and the SDKs evolve at different speeds. The specification defines the protocol, while the SDKs implement it for specific languages. The July release updated the Tier 1 SDKs, so an SDK version can introduce implementation-specific APIs and migration steps even when the underlying protocol concept is unchanged.

What are MCP Apps and Tasks?

MCP Apps and Tasks are the first two official extensions in the 2026 framework, and together they push MCP beyond background tool calls. Their arrival marks a shift: where MCP once meant tools and data, it increasingly means tools, data, and interactive experiences.

MCP Apps let a server provide an interactive user interface that the host renders in a sandboxed environment, built on HTML and communicating through the same JSON-RPC foundation as the rest of the protocol. Instead of returning only a value or performing only an action, an MCP-connected capability can return an interactive experience around that capability, such as a form, a viewer, or a small application surface. OpenAI's Apps SDK, which lets developers build apps that run inside ChatGPT, is built on MCP and is an early large-scale example of this direction.

Tasks give clients and servers a standard way to represent long-running work. Rather than forcing a tool call to finish immediately, a server can return a task handle that the client can later inspect, update, or cancel, which suits operations that take minutes or hours rather than seconds.

In short: MCP Apps let servers offer interactive interfaces, and Tasks let them model long-running work, extending MCP from a connector for tools and data into a foundation for richer AI experiences.

What does MCP standardize, and what does it not?

MCP standardizes the connective layer between AI applications and external capabilities, and it deliberately leaves the model, the reasoning, and the business logic alone. Being explicit about the boundary is the clearest way to understand the protocol's scope.

MCP standardizes capability discovery, the interfaces for tools, resources, and prompts, the structure of messages, client-server communication, transport behavior, authorization mechanisms, extensions, and the lifecycle conventions for how features are added and retired.

MCP does not standardize the underlying AI model, the agent's reasoning or autonomy, model training, the business logic behind a tool, the underlying API or database a server wraps, or how an organization decides which tools an agent is allowed to use. Those remain the responsibility of the model provider, the application, and the deploying organization.

In short: MCP standardizes how AI applications discover and talk to capabilities, not the model, the reasoning, or the systems underneath the capabilities.

What is the difference between MCP and function calling?

MCP and function calling operate at different layers and work together, which is the single most common point of confusion. Function calling is a model or API mechanism for representing a request to invoke a tool. MCP is a protocol for how an AI application discovers, describes, connects to, and invokes external capabilities. They are complementary, and an MCP-enabled application typically translates MCP tools into whatever native tool-calling format its model uses.

To see the difference, follow a single request. The model, using function calling, decides it needs a tool and emits a structured request with a tool name and arguments. That happens inside the model's own API. MCP governs everything around that moment on the application side: how the tool was discovered, described in a standard schema, connected to, and invoked, so the same tool works the same way whether the model behind it is from Anthropic, OpenAI, or Google.

For a fuller treatment of the model-side mechanism, see our guide to tool use and function calling.

In short: function calling is how a model represents a tool request, and MCP is the application-level protocol for discovering and reaching the capability, so they operate at different layers and work together.

MCP vs APIs: what is the difference?

APIs and MCP solve related but different problems, and MCP usually wraps an API rather than replacing it. An API defines how software exposes and consumes capabilities, and it assumes a developer read the documentation and wired the endpoints in advance. MCP defines a standardized way for an AI application to discover and interact with tools, resources, and prompts at runtime, without a developer having pre-wired each one.

The practical relationship is that an MCP server often acts as an adapter around an existing API, translating it into the standard protocol so any MCP-compatible application can use it. The API still does the underlying work. Whether to expose a capability through MCP or a direct integration depends on the deployment: direct integrations can give tighter, application-specific control over authentication and the exact code that touches sensitive data, while MCP is valuable when interoperability, reuse across many AI clients, or access to the growing MCP ecosystem matters.

In short: an API is how software exposes capabilities to developers, while MCP is how AI applications discover and use those capabilities at runtime, and an MCP server usually adapts an existing API rather than replacing it.

How does MCP compare to A2A and other agent protocols?

MCP and A2A address different layers of the agentic stack and can be used together. The clearest way to understand the difference is by direction. MCP connects an agent downward to tools and data. A2A, the Agent2Agent protocol, connects an agent sideways to other agents.

MCP is vertical integration: it answers how a single agent reaches the tools, files, and services it needs. A2A is horizontal integration: it answers how one agent discovers, delegates to, and coordinates with another, which is the foundation of multi-agent systems. A complex workflow can use both at once, with several agents coordinating over A2A while each agent reaches its own tools over MCP.

In short: MCP connects an agent to its tools, A2A connects agents to each other, and a full agentic system often uses both, so they are complementary layers of the same stack.

Is MCP secure?

MCP requires deliberate security controls, because connecting a model to real tools expands the attack surface. The risk is not limited to the protocol implementation itself. MCP gives AI applications structured access to external tools, data, and actions, and that access is what has to be governed.

Several named attack classes have been documented as the ecosystem has grown. Tool poisoning hides malicious instructions in a tool's description so a model is lured into unsafe actions simply by having the tool available. A rug pull is when a server silently redefines a tool after a user approved it. Prompt injection in an MCP context often arrives through the tool result itself, where data returned from a server carries instructions that hijack the model. The confused deputy problem occurs when a server with legitimate elevated privileges is tricked into using them on an attacker's behalf. Researchers summarize the worst case as the lethal trifecta: an agent with access to private data, exposure to untrusted content, and a way to send data out is one poisoned tool away from a breach. Real vulnerabilities have followed, including CVE-2025-6514, a critical remote code execution flaw in the widely used mcp-remote connector disclosed by JFrog in July 2025.

There is also a supply-chain dimension. Installing an MCP server can effectively give an AI application privileged access to sensitive systems, which makes the server a software dependency. Organizations should evaluate a server's provenance, dependencies, permissions, update history, and maintainer trust, not just the tools it advertises, because a compromised, typosquatted, or silently updated server can turn access into exposure.

It also helps to separate two ideas that are easy to blur. Authentication asks who you are, and authorization asks what you are allowed to do. The 2026 specification strengthened MCP's authorization model, bringing it into closer alignment with mainstream OAuth deployments, but OAuth is one layer rather than the whole security answer. Deployments still need application-level permission controls, and the recommended practices are consistent across security guidance: treat every tool description and result as untrusted input, inspect a server's full schema before approving it, put the tool list through human approval rather than trusting a friendly summary, show the full tool call before it runs, keep sensitive servers isolated from general-purpose ones, and validate any state passed between multi-round requests. These controls can materially reduce MCP-related risk, but production deployments still require conventional application-security practices, least-privilege access, monitoring, and human oversight appropriate to the actions being exposed.

What can you build with MCP, and where is it used?

MCP is used anywhere an AI application needs to reach beyond its own text, and by 2026 that covers most serious AI products. The ecosystem splits into two halves that meet in the middle: the hosts people use and the servers that expose capabilities.

On the host side, MCP is built into AI assistants like Claude Desktop, AI code editors such as Cursor, and enterprise platforms including Microsoft Copilot Studio. On the server side, thousands of tools now ship official or community MCP servers: version control through a GitHub server, databases through Postgres and other data servers, messaging through a Slack server, payments through a hosted server from a provider like Stripe, and file access through local servers. Because the protocol is shared, connecting a new tool to an assistant is often a matter of pointing the host at a server rather than writing integration code. Yes, MCP can connect to databases, and it can both retrieve data through resources and take actions through tools, not only read.

The protocol is also moving beyond background tool calls into interactive experiences. OpenAI's Apps SDK, for example, is built on MCP and lets developers create apps with both logic and interfaces that run inside ChatGPT. What you can build ranges from a simple assistant given read access to a codebase and a database, to a support agent that looks up orders and files tickets across several servers, to an autonomous agent coordinated by an orchestration layer that chains many MCP tools across many systems.

Building an MCP server follows a consistent shape rather than a fixed recipe: choose the capability or data source to expose, pick an MCP SDK, define the tools, resources, or prompts and their schemas, decide between stdio and Streamable HTTP, add authentication and authorization, test against a host, apply the security controls above, and deploy. A full, step-by-step build belongs in a tutorial rather than this concept guide.

In short: MCP is used by AI assistants, code editors, and enterprise platforms on one side and thousands of tool servers on the other, and it now supports interactive apps as well as background tool calls.

Why does MCP matter for AI agents?

MCP matters because it is emerging as a major interoperability layer for agentic AI, particularly for connecting AI applications with external tools and data. The history of computing shows that platforms take off when a connective standard removes the friction of integration. The web needed HTTP, devices needed USB, and commerce needed the shipping container. Agentic AI needed a way for AI applications to use tools without rebuilding every connection, and MCP has become one of the leading answers.

Its strategic importance is why competitors cooperated on it. Models are where AI companies compete, but tools are where AI becomes useful, and no single company could connect every tool to every model alone. By agreeing on MCP and handing it to a neutral foundation, the industry chose a common substrate for action, much as it earlier converged on transformers as a common substrate for the models themselves. That decision compounds through network effects: every new MCP server makes every MCP host more capable, and every new host makes every server more valuable.

The scale of that adoption is striking. In roughly two years MCP went from an Anthropic release to an industry standard, a trajectory the Agentic AI Foundation, which now stewards the protocol, traces in this short overview.

For anyone tracking where AI is going, MCP is a layer to watch, because it is where the abstract promise of autonomous agents meets the concrete systems they must act on. Function calling gave models a way to represent an action, agents gave them autonomy, and MCP is emerging as the standardized way that autonomy reaches the real world, now including the physical machines addressed by the Model Hardware Standard.

A brief timeline of MCP

Frequently asked questions

Sources and further reading

1. Model Context Protocol. Specification, 2026-07-28 revision (architecture, primitives, transports, extensions). modelcontextprotocol.io
2. Model Context Protocol Blog. The 2026-07-28 Specification. blog.modelcontextprotocol.io
3. Anthropic. Introducing the Model Context Protocol. November 2024. anthropic.com
4. Anthropic. Donating the Model Context Protocol and Establishing the Agentic AI Foundation. December 2025.
5. Linux Foundation. Agentic AI Foundation. 2025.
6. OpenAI. Apps SDK and MCP Support. 2026.
7. Microsoft Security. The State of MCP Security in 2026. 2026.
8. JFrog Security Research. CVE-2025-6514: Remote Code Execution in mcp-remote. July 2025.
9. Anthropic. Code Execution with MCP: Building More Efficient AI Agents. Anthropic Engineering, 2026.
10. IBM. What is Model Context Protocol (MCP)? IBM Think, 2026.