What is MCP (Model Context Protocol)? A plain-English explainer of the Anthropic-led standard

The short answer

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems. The official documentation describes it as “an open-source standard for connecting AI applications to external systems” and frames the analogy plainly: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.” ¹

MCP was introduced by Anthropic in November 2024. ⁴ A year and a half later, the protocol is supported by Claude, ChatGPT, Visual Studio Code, Cursor, and a long tail of clients and servers, which is what an “open protocol” eventually looks like when adoption sticks. ¹

The protocol has a small surface. There are three participants: a host (the AI application), clients (the host’s connection objects), and servers (the programs that expose tools and data). Servers expose three primitives: tools (callable functions), resources (data sources), and prompts (reusable templates). The whole exchange runs over JSON-RPC 2.0, either through stdio for local servers or streamable HTTP for remote ones. ²

The problem MCP is trying to solve

Before MCP, every AI application defined its own way of exposing external capabilities to a language model. Claude Desktop had its own way of declaring tools. The OpenAI Assistants API had a different way. Every agent framework — LangChain, LlamaIndex, AutoGen, CrewAI — had its own. A vendor writing a tool that an AI should be able to call (say, a Sentry integration that lets the model fetch error reports) had to write a different integration for each application.

MCP’s value proposition is to collapse those many integrations into one. A vendor writes a single MCP server. Any application that speaks MCP can use it. The official introduction summarises the motivation in three audiences: developers see reduced integration complexity, AI applications get access to a wider ecosystem of tools and data, and end users get more capable assistants that can act on their behalf. ¹

The framing as a “USB-C port for AI applications” is the official analogy, and the underlying logic is the same: a standard plug is most useful when both sides of the connection adopt it. ¹

Hosts, clients, servers

MCP follows a client-server architecture, with one wrinkle. The architecture documentation names the three participants explicitly: ²

• MCP Host: “The AI application that coordinates and manages one or multiple MCP clients.” This is Claude Desktop, Cursor, VS Code, ChatGPT, or whatever AI application the user is interacting with.
• MCP Client: “A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use.” Each connection gets its own client object; a host with three connected servers has three clients.
• MCP Server: “A program that provides context to MCP clients.” A server might run locally as a process the host launches (using the stdio transport) or remotely as an HTTP service (using the streamable HTTP transport).

The unusual word is “host.” In most client-server terminology, the host is the machine; in MCP, the host is the application. A single AI application can be a host to many servers at once, with one dedicated client per server connection. ²

The three primitives

The protocol’s working surface is three things a server can expose to a client: ²

Tools are “executable functions that AI applications can invoke to perform actions (e.g., file operations, API calls, database queries).” Tools are how the model does something through MCP. A filesystem server exposes tools for reading and writing files. A database server exposes tools for running queries. A GitHub server exposes tools for opening pull requests.

Resources are “data sources that provide contextual information to AI applications (e.g., file contents, database records, API responses).” Resources are how the model reads something through MCP. The distinction from tools is subtle but real: a resource is a thing with a URI that can be enumerated and fetched; a tool is a function that does work. A database server might expose its schema as a resource and its query interface as a tool.

Prompts are “reusable templates that help structure interactions with language models (e.g., system prompts, few-shot examples).” A prompt is a parametric chunk of text that the host can fetch from the server and inject into a model conversation. Prompts let a server bundle “the right way to invoke this server” alongside the server itself.

Each primitive has discovery methods (tools/list, resources/list, prompts/list), retrieval methods (resources/get, prompts/get), and where it makes sense an execution method (tools/call). ²

How the data flows

A typical MCP session has four phases. ²

Initialisation. The client opens a connection and sends an initialize request with its supported features. The server replies with its own capabilities. Both sides exchange protocol version and identity information.

Discovery. The client calls the */list methods to find out what tools, resources, and prompts the server exposes. The host registers these with the language model so the model knows what is available.

Use. When the model decides to call a tool, the client sends a tools/call request with the tool name and arguments. The server runs the tool and returns the result as a structured content array. The host inserts the result into the model’s conversation and continues the loop.

Notifications. Servers can push updates to clients without a request — for example, when the list of available tools changes — using JSON-RPC notifications (one-way messages with no id and no expected reply).

Everything is JSON-RPC 2.0 under the hood. The same message format is used regardless of whether the transport is stdio or HTTP. ²

Transports: local stdio, remote streamable HTTP

MCP defines two transports. ²

Stdio transport uses standard input and standard output for direct process communication between a host and a locally-running server. The host launches the server as a subprocess; messages flow over the subprocess’s stdin and stdout pipes. This is the default for “local” MCP servers, including the official reference filesystem server. ⁵ No network overhead, no authentication question — the server inherits its permissions from the launching process.

Streamable HTTP transport uses HTTP POST for client-to-server messages with optional Server-Sent Events for streaming responses. This is the default for “remote” MCP servers, which the host connects to over the network. The transport supports standard HTTP authentication mechanisms (bearer tokens, API keys, custom headers), and the specification recommends OAuth for obtaining authentication tokens. ²

The transport layer is the outer wrapping; the data layer (JSON-RPC messages, primitives, lifecycle) is unchanged across the two. A server can in principle support both, though most servers in the reference repository default to stdio for the local-developer-machine case and HTTP for the deployed-service case. ⁵

Client-side primitives, briefly

The flow is not strictly one-way. MCP also defines a few client primitives — capabilities a host can expose back to the server. ²

• Sampling lets a server request a language-model completion from the host’s LLM. This is useful when the server author wants access to a language model without embedding one. The server calls sampling/createMessage; the host’s LLM responds.
• Elicitation lets a server ask the user for additional information through the host. The server calls elicitation/create; the host presents the request to the user and returns the answer.
• Logging lets a server send log messages to the client for debugging and monitoring.

These are less commonly used than the server primitives but they are part of the standard surface.

Why this matters in practice

Adoption is what makes a standard a standard. The MCP documentation lists Claude, ChatGPT, Visual Studio Code, Cursor, and a long tail of additional clients as supporting the protocol; the GitHub organisation modelcontextprotocol/servers collects reference and community-contributed server implementations covering filesystems, databases, GitHub, Slack, Google Drive, Sentry, and many others. ^{1 5}

For a developer building an AI application, MCP changes a 1-to-N integration problem into a 1-to-1 one: write the MCP host once, plug in any compliant server. For a developer building a tool, MCP changes an N-to-1 problem into a 1-to-1 one: write the MCP server once, expose it to any compliant application. The “USB-C” framing in the official introduction is, in the cases where adoption sticks, what eventually plays out. ¹

Common misconceptions

Three things are worth correcting because they appear in posts on the topic.

First, MCP is not an Anthropic-only protocol. Anthropic introduced the standard and continues to lead its development, but the specification is open and the GitHub organisation accepts contributions from outside Anthropic. ChatGPT supports MCP. VS Code supports MCP. The protocol works the same whether the model behind the host is Claude, GPT-5.5, Gemini, or an open-weight model. ¹

Second, MCP is not a replacement for an agent framework. MCP standardises how tools and data sources are declared and called; it does not say anything about how the host decides which tool to call, how it manages memory, or how it loops. Those are concerns of the agent framework that sits inside the host. LangChain, OpenAI’s Agents SDK, and Anthropic’s own agent recipes all live above MCP, not next to it.

Third, MCP is not a remote-code-execution surface in the security sense — but it is a permission-granting surface that needs care. An MCP server can do anything the process it runs as can do. Connecting a filesystem server with full read-write access to the home directory is connecting the model to the home directory. The protocol does not, by itself, sandbox tool execution; sandboxing is the host’s responsibility, and a host’s tool-approval UX matters more under MCP than it did before.

Honest caveats

The protocol is still evolving. The specification version visible in the architecture documentation at the time of writing is 2025-06-18, and the documentation flags several primitives (notably Tasks, for durable execution wrappers) as experimental. ^{2 3} Anyone implementing against MCP should pin to a specific specification version and watch the changelog.

Concrete adoption beyond the major clients (Claude, ChatGPT, Cursor, VS Code) is still uneven. Many enterprise SaaS vendors had not shipped first-party MCP servers as of mid-2026, which means production integrations often rely on community-maintained MCP servers whose quality varies. The GitHub server registry is the right starting point for evaluating which servers exist. ⁵

This explainer covers what MCP is and the shape of the protocol. The companion tutorial walks through building a first server end-to-end.