What is MCP? A plain-English definition
MCP stands for Model Context Protocol. It is an open standard — a published specification, not a product — that defines how an AI application talks to the outside world: local files, databases, SaaS tools, internal APIs, and reusable workflows. The official documentation describes it as "an open-source standard for connecting AI applications to external systems" (MCP docs — What is MCP?).
Anthropic introduced and open-sourced MCP on November 25, 2024, shipping the specification, SDKs, local server support in the Claude Desktop apps, and an open-source repository of pre-built servers (Anthropic — Introducing the Model Context Protocol). The analogy Anthropic and the MCP docs use is a "USB-C port for AI applications": just as USB-C gives every device one standard connector instead of a drawer full of proprietary cables, MCP gives every AI app one standard way to plug into tools and data (MCP docs). That framing is theirs, not ours, but it is the right mental model.
Two things MCP is not: it is not a model, and it is not an agent framework. It does not decide what the AI should do or how it reasons — the MCP docs are explicit that it "focuses solely on the protocol for context exchange" and does not dictate how applications use LLMs (MCP docs — Architecture). It is the plumbing between an AI app and the systems it needs to reach.
The problem MCP solves: M × N integrations
Before a standard existed, every AI application that wanted to reach a tool had to write its own integration for it. A chat assistant, an IDE agent, and an internal support bot each needed their own GitHub connector, their own Postgres connector, their own Slack connector — with their own auth handling, schema descriptions, and error semantics. With M AI apps and N tools, that is M × N integrations to build and maintain, none of them reusable across apps.
MCP collapses that to M + N. A tool is wrapped once as an MCP server; an AI app implements an MCP client once. From then on, any client can use any server, because both sides speak the same protocol. The MCP docs frame the payoff by audience: developers get reduced integration time and complexity, tool builders reach every MCP-compatible app with a single server, and end users get assistants that can actually act on their data (MCP docs — Why does MCP matter?).
A natural question is how this differs from just calling a REST API — the short answer is that MCP is a layer on top of your APIs that makes them discoverable and callable by any AI client, and the deep comparison (MCP vs API, MCP vs RAG, when to use which) lives in our MCP vs API guide.
What is an MCP server?
An MCP server is a program that exposes capabilities — tools, resources, and prompts — to AI applications over the Model Context Protocol. It can run locally on your machine as a subprocess, or remotely as a web service. The MCP docs define servers as "programs that expose specific capabilities to AI applications through standardized protocol interfaces" (MCP docs — Understanding MCP servers). So when someone says "MCP server," they mean a wrapper around something useful — a filesystem, a Git repo, a database, a SaaS product — that any MCP client can plug into.
To understand where a server sits, you need the three roles the protocol defines (MCP docs — Participants):
| Role | What it is | What it does |
|---|---|---|
| MCP Host | The AI application the user is actually using — Claude Desktop, Claude Code, an IDE, or your own agent. | Coordinates one or more MCP clients, decides which servers to connect to, and owns the LLM loop. |
| MCP Client | A component inside the host. The host creates one client per server. | Maintains a dedicated connection to a single MCP server and relays requests and responses. |
| MCP Server | A separate program (local or remote) that wraps a tool, data source, or workflow. | Exposes capabilities — tools, resources, prompts — to any client that speaks the protocol. |
An MCP server can expose three kinds of capability. The MCP docs call these the core server features, and each has a different "who triggers it" model: tools are model-controlled (the AI can discover and invoke them, subject to the host's approval controls), resources are application-driven (the host decides how to retrieve and present them as context), and prompts are user-controlled (explicitly invoked, not triggered automatically) (MCP docs — Core server features):
| Primitive | What it is | Example |
|---|---|---|
| Tools | Executable functions the model can call — run a query, create an issue, send a message. | A GitHub server exposes create_issue and search_code. |
| Resources | Read-only data the host can pull into the model's context — files, records, documents. | A filesystem server exposes file contents by URI. |
| Prompts | Reusable prompt templates the server offers, usually surfaced to the user as commands. | A server ships a 'summarize this PR' template. |
A concrete example. The reference Filesystem server in the official servers repository provides "secure file operations with configurable access controls" (modelcontextprotocol/servers — Reference Servers). When Claude Desktop launches it, the server runs as a local subprocess on the same machine; the host creates one MCP client for it, asks the server what tools it offers, and from then on the model can read, search, and write files within the directories you allowed — without Claude Desktop having any filesystem code of its own (MCP docs — Architecture). Swap in a GitHub server and the same client code gives the model issues, pull requests, and code search instead. That interchangeability is the whole point.
Get the weekly AI engineering brief
Agents, MCP, RAG, evals, and the tools worth using — one practical email a week. Plus the free roadmap PDF.
By subscribing you agree to receive emails from AI Engineer Insights. Unsubscribe anytime. See our Privacy Policy.
How MCP works: the architecture
MCP follows a client-server architecture. The host application — Claude Code, Claude Desktop, an IDE, or your own agent — establishes connections to one or more MCP servers by creating one MCP client per server. Each client maintains a dedicated connection to its server. Local servers using stdio typically serve a single client; remote servers using Streamable HTTP typically serve many (MCP docs — Architecture).
The protocol is organized in two layers (MCP docs — Layers):
- • Data layer. A JSON-RPC 2.0 based exchange protocol that defines message structure and semantics: discovery (a client queries a server's supported protocol versions, capabilities, and identity), the server primitives (tools, resources, prompts), client features such as elicitation (a server asking the user for input), and utility features like notifications for real-time updates and progress tracking for long-running operations.
- • Transport layer. How those messages physically move between client and server — connection establishment, message framing, and authorization. The data layer is the inner layer; the transport is the outer one, and the same messages work over any transport.
Messages are JSON-RPC 2.0. The specification states that "the protocol uses JSON-RPC 2.0 messages to establish communication between" hosts, clients, and servers, and that messages must be UTF-8 encoded (MCP Specification — Overview; MCP Specification — Transports). In practice that means a client sends a request like tools/list to discover what a server offers, gets back a JSON description of each tool and its input schema, and later sends tools/call with arguments when the model decides to use one.
Two standard transports. The current specification defines two (MCP Specification — Transports):
- • stdio — newline-delimited JSON-RPC messages over the standard input and output streams of a subprocess the client launches. This is the "local server" case: zero network setup, the server dies when the host does.
- • Streamable HTTP — each message is an HTTP POST to a single MCP endpoint; replies come back as a JSON object or as a request-scoped SSE stream. This is the "remote server" case, used by hosted servers that serve many clients and need authorization.
Clients and servers may also implement custom transports, but those two are what you will meet in the wild. The spec is versioned by date and evolves — always read the latest revision at modelcontextprotocol.io rather than trusting a blog post's snapshot of the details (MCP Specification — latest).
What is MCP in AI? Where it fits in an agent stack
In the context of AI systems, MCP is the standard way an agent or assistant discovers and calls external tools and data at runtime. An AI agent is a loop: the model observes, decides, acts, and observes again. MCP is how the "act" step reaches anything outside the model — the agent connects to servers, asks each what it can do, and calls those capabilities through a common message format instead of through bespoke glue code. The MCP docs' own examples are agents that read your calendar, query a database, or open a pull request (MCP docs — What can MCP enable?).
MCP complements agent frameworks rather than replacing them. A framework like LangGraph, CrewAI, or the OpenAI Agents SDK handles reasoning, orchestration, memory, and control flow; MCP handles how tools are described and reached. Most of the frameworks in our open-source agent frameworks roundup can consume MCP servers as tool sources — OpenAI's Agents SDK, for example, documents MCP support directly (OpenAI Agents SDK — Model context protocol).
It also has a sibling. MCP connects an agent to its tools; the A2A (Agent2Agent) protocol connects agents to other agents. They solve different problems and are routinely used together. And if you are wondering how MCP relates to plain APIs or to RAG, that comparison is covered in depth in our MCP vs API post — this guide stays on "what it is and how it works."
Real MCP servers and the ecosystem
At launch, Anthropic shipped pre-built servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, and named Block and Apollo as early adopters, with Zed, Replit, Codeium, and Sourcegraph working to add MCP to their developer tools (Anthropic — Introducing MCP). Today the official modelcontextprotocol/servers repository holds a smaller set of reference servers meant to demonstrate the protocol and SDKs — Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, and Time — and points to the Official MCP Registry as the place to browse published community and vendor servers (modelcontextprotocol/servers). Official SDKs exist for TypeScript, Python, Java, Kotlin, C#, Go, Rust, Swift, Ruby, and PHP, per the same repository.
On adoption, we only state what the primary sources say. The official MCP documentation describes MCP as "an open protocol supported across a wide range of clients and servers" and lists AI assistants including Claude and ChatGPT, and development tools including Visual Studio Code and Cursor, as supporting it (MCP docs — Broad ecosystem support). OpenAI's platform documentation calls MCP "an open protocol that's becoming the industry standard for extending AI models with additional tools and knowledge" and documents building remote MCP servers for its API (OpenAI — Building MCP servers). So the short version is: MCP began at Anthropic, and it is now used across several major AI vendors and most mainstream coding tools — which is exactly what makes writing one server worth it.
How to try MCP
You do not need to write code to see MCP work. The fastest route is to use an application that already ships an MCP client, add one existing server, and watch the model discover and call its tools. The official quickstart walks through adding the Filesystem server to Claude Desktop with a few lines of JSON config (MCP docs — Connect to local MCP servers).
- • Use an existing client. Claude Desktop, Claude Code, VS Code, and Cursor all include MCP clients — pick the one you already use.
- • Add a server. Start with a reference server such as Filesystem or Git from the official repository, or browse the Official MCP Registry for a server that wraps a tool you rely on.
- • Build one. When you want to expose your own system, write a server with an official SDK. We keep a step-by-step build walkthrough in the "How to build an MCP server" section of the MCP vs API guide, so we will not duplicate it here.
One habit worth forming early: treat MCP servers like any other dependency you grant access to. A server that exposes tools is a server that can act on your behalf, so read what a server does and scope its permissions (which directories, which repos, which credentials) before wiring it into an agent that runs unattended.
Frequently Asked Questions
What is MCP?
MCP (Model Context Protocol) is an open standard for connecting AI applications to external tools, data sources, and workflows. It was introduced and open-sourced by Anthropic in November 2024 and defines a client-server protocol: an AI app (the host) runs MCP clients that connect to MCP servers, and each server exposes capabilities — tools, resources, and prompts — that the AI can discover and use at runtime. The goal is that a tool integrated once as an MCP server works with any MCP-compatible AI application.
What does MCP stand for?
MCP stands for Model Context Protocol. 'Model' refers to the AI model, 'context' is the external information and tools the model needs to do useful work, and 'protocol' means it is a standardized, specified way of exchanging that context — not a product or a library.
What is an MCP server?
An MCP server is a program that exposes capabilities to AI applications over the Model Context Protocol. It can expose three kinds of things: tools (functions the model can call), resources (data the host can read into context), and prompts (reusable prompt templates). A server can run locally on your machine, communicating over stdio, or remotely as a web service using Streamable HTTP. Examples include servers for the filesystem, Git, GitHub, Slack, and databases.
What is MCP in AI?
In AI systems, MCP is the standard way an AI agent or assistant discovers and calls external tools and data at runtime. Instead of hard-coding each integration into the agent, the agent connects to MCP servers, asks each one what it offers, and calls those capabilities through a common message format (JSON-RPC 2.0). It sits alongside agent frameworks, which handle reasoning and orchestration, and agent-to-agent protocols like A2A, which handle communication between agents.
Who created MCP and is it open source?
Anthropic introduced MCP and open-sourced it on November 25, 2024, releasing a specification, SDKs, and a repository of reference servers. It is an open standard with a public, versioned specification maintained at modelcontextprotocol.io, and the SDKs and reference servers are developed in the open on GitHub under the modelcontextprotocol organization.
Is MCP only for Claude?
No. MCP started at Anthropic, but it is an open standard and is not tied to Claude. The official MCP documentation lists AI assistants including Claude and ChatGPT and developer tools such as Visual Studio Code and Cursor as supporting the protocol, and OpenAI documents MCP support in both its Agents SDK and its platform API. Any application that implements an MCP client can use any MCP server.
References
- • Model Context Protocol — What is MCP? (official docs)
- • Model Context Protocol — Architecture overview (participants, layers, data layer, transport layer)
- • Model Context Protocol — Understanding MCP servers (tools, resources, prompts)
- • Model Context Protocol — Understanding MCP clients (elicitation, roots)
- • Model Context Protocol — Specification (latest revision)
- • Model Context Protocol — Specification: Transports (stdio, Streamable HTTP)
- • Model Context Protocol — Connect to local MCP servers (quickstart)
- • Anthropic — Introducing the Model Context Protocol (Nov 25, 2024)
- • GitHub — modelcontextprotocol/servers (reference servers and official SDKs)
- • Official MCP Registry
- • OpenAI Agents SDK — Model context protocol (MCP)
- • OpenAI — Building MCP servers for plugins and API integrations