What is MCP (Model Context Protocol)?
MCP is an open protocol for connecting AI applications to external tools and data sources. It was introduced and open-sourced by Anthropic in late 2024 and adopted across the industry through 2025. The problem it solves is boring but expensive: before MCP, every AI app needed custom integration code for every tool it wanted to use. Ten apps and ten tools meant a hundred bespoke integrations.
MCP fixes that the way USB-C fixed chargers, or the way the Language Server Protocol fixed editor tooling: a single standard connector. You expose a capability once as an MCP server, and any MCP host — Claude, ChatGPT, an IDE like Cursor, or your own AI agent — can discover and use it without custom glue. Anthropic's own phrase for it is a "USB-C port for AI applications."
MCP vs API: the real difference
The question "MCP vs API" is slightly the wrong frame, because MCP is built on top of APIs — an MCP server almost always calls a REST or database API underneath. The useful contrast is what each is for: an API is a general interface a developer codes against; MCP is a model-facing protocol that makes those interfaces discoverable and reusable by any AI app.
| Aspect | Traditional API | MCP |
|---|---|---|
| What it is | A general interface between two pieces of software | A specific open protocol for connecting LLM apps to tools and data |
| Who it's for | Developers, who write integration code | The model / agent, which calls tools at runtime |
| Discovery | Read the docs, hard-code each endpoint | Self-describing — the host lists available tools automatically |
| What it exposes | Endpoints (REST, GraphQL, RPC…) | Standard Tools, Resources, and Prompts |
| Integration cost | M×N — every app wired to every tool | M+N — write one server, any host uses it |
| Transport | Usually HTTP | JSON-RPC 2.0 over stdio or streamable HTTP |
| Relationship | The thing being called | Usually wraps an API so a model can use it |
The single biggest win is the last-but-one row. Custom integrations scale as M×N — every AI app times every tool. MCP collapses that to M+N: write a server once, and every host that speaks MCP gets it for free.
How MCP works: architecture
MCP is a client-server protocol built on JSON-RPC 2.0. Three roles (shown in the diagram above):
- • Host. The AI application the user interacts with — Claude Desktop, an IDE, an agent runtime.
- • Client. Lives inside the host and holds one connection to each server.
- • Server. Exposes capabilities over MCP, usually wrapping an API, database, or filesystem.
Each server offers three standard primitives: Tools (actions the model can call, like "create a GitHub issue"), Resources (data/context the app can read, like a file or record), and Prompts (reusable templates a user can invoke). Servers run over stdio for local processes or streamable HTTP for remote ones. Because the primitives are standard and self-describing, the host can list a server's tools at runtime — no hard-coding.
How MCP evolved — and what was hard at first
MCP shipped fast and changed fast, so the version you read about in an early post is not quite the one you build on today. The first release (November 2024) supported two transports — stdio for local servers and an HTTP+SSE transport for remote ones — with a deliberately minimal spec. That minimalism is what got it adopted, but it also left real gaps the next revisions had to close.
The early pain points:
- • The HTTP+SSE transport was awkward. It needed a long-lived server-sent-events stream plus a separate POST endpoint — stateful, hard to run on serverless, and with no way to resume a dropped connection.
- • Auth was underspecified. Early remote servers had no standard way to authenticate, so everyone rolled their own.
- • Security gaps. Because tool descriptions are fed to the model, a malicious server can smuggle instructions ("tool poisoning" / prompt injection), and over-permissioned servers or token pass-through opened confused-deputy and token-theft risks.
- • Breaking changes. The spec moved so quickly that early adopters had to chase transport and SDK churn.
The revisions that fixed most of it:
- • 2025-03-26. The clunky HTTP+SSE transport was replaced by Streamable HTTP — a single endpoint that works statelessly (serverless-friendly) and supports resumable streams — and a formal OAuth 2.1 authorization framework was added.
- • 2025-06-18. MCP servers were defined as OAuth Resource Servers with Resource Indicators (RFC 8707) so tokens can't be reused where they shouldn't be, plus structured tool output, an elicitation flow for servers to ask the user for input, removal of JSON-RPC batching, and a dedicated security best-practices document.
Governance opened up too, moving toward a public specification process rather than a single-vendor project. Net effect: the "USB-C for AI" idea survived, but the wiring behind it got a lot more production-ready.
Get the weekly AI engineering brief
MCP, agents, RAG, 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.
RAG vs MCP: not the same thing
These get compared a lot, but they solve different problems at different layers. RAG (retrieval-augmented generation) is a technique for pulling relevant knowledge into a model's context before it answers. MCP is a protocol for connecting tools and data sources to AI apps. They're complementary, not competing.
In fact, the cleanest way to ship RAG to an agent is through MCP: wrap your retrieval pipeline (embeddings, vector search, reranking) in an MCP server that exposes a search_knowledge_base tool. Now any MCP host can do retrieval against your data with zero custom integration. RAG is the what; MCP is one clean how to deliver it.
When to use MCP vs a plain API
- • Reach for MCP when an LLM or agent needs to discover and call tools, especially if you want the same tool to work across multiple AI hosts, or you're building agents that plug into many capabilities.
- • Reach for a plain API when it's deterministic app-to-app integration with no model in the loop, when you need maximum control or performance, or when only one consumer will ever call it.
- • Usually you use both: the MCP server is a thin, model-friendly wrapper around your existing API, adding discovery, standard primitives, and reuse.
What developers actually say about MCP
MCP's reception has been loud on both sides — worth knowing before you build on it. The praise: it solved a real, expensive problem (the M×N integration mess), and adoption was extraordinary — thousands of community servers within months, plus cross-vendor support from OpenAI, Google, and Microsoft, made it a de facto standard faster than almost any recent protocol.
The criticism clusters in three places:
- • Security is the loudest. Researchers repeatedly warned that MCP makes it easy to wire an agent into what Simon Willison calls the "lethal trifecta" — access to private data, exposure to untrusted content, and a way to exfiltrate — so a poisoned tool description or malicious server can hijack an agent. The 2025 auth and security revisions were a direct response.
- • Context and token burn. Every connected server injects its tool definitions — names, descriptions, and schemas — into the model's context on every call. Wire up a dozen servers and you can spend thousands of tokens before the user asks anything, driving up cost and latency; worse, too many tools measurably degrades the model's tool selection. The practical fix is to load only the servers a task needs (and lean on dynamic/lazy tool loading as hosts add it).
- • Transport churn. Replacing HTTP+SSE so soon frustrated early adopters who'd already built on it.
- • "Do we even need it?" Some argued function calling plus OpenAPI already covered most cases and that MCP re-invents the wheel; the counter is that runtime discovery, standard primitives, and cross-host reuse are exactly what ad-hoc function calling lacks.
The honest read in 2026: MCP won the standardization battle, and the sharp early edges (transport, auth, security) are mostly sanded down — but you still own the security of what you connect. Treat every third-party server as untrusted, scope permissions tightly, and keep a human in the loop for risky actions.
MCP examples and ecosystem
There's a large and growing library of ready-made MCP servers — filesystem, GitHub, Google Drive, Slack, Postgres, Puppeteer/browser, and web search among them — plus SDKs to build your own in TypeScript, Python, and other languages. On the host side, Claude Desktop, popular IDEs and coding agents (see our ranked AI coding agents), and custom agent frameworks all speak MCP. That two-sided adoption is exactly why writing one server is worth it: it lights up everywhere at once.
MCP vs A2A, ADK, and other agent protocols
MCP isn't the only standard in this space, and the others mostly complement it rather than compete. The trick is to notice which connection each one is about:
- • MCP — agent ↔ tools and data. What this article is about.
- • A2A (Agent2Agent) — agent ↔ agent. Google's protocol for letting independent agents discover and delegate to each other, later donated to the Linux Foundation. MCP gives an agent its tools; A2A lets agents talk to one another. See our deep dive on A2A.
- • ADK (Agent Development Kit) — not a protocol but Google's open-source framework for building agents; it speaks both MCP (for tools) and A2A (for agent-to-agent), which is a clean picture of how the layers stack.
- • ACP and others — additional agent-communication efforts exist (e.g. IBM/BeeAI's ACP), but momentum in 2026 has consolidated around MCP for tools and A2A for agent-to-agent.
How to build an MCP server
The minimum path:
- Pick an SDK — the official TypeScript or Python SDK is the usual starting point.
- Define your primitives. List the Tools, Resources, and Prompts you want to expose, with clear names and descriptions (the model reads these).
- Wrap the backend. Each tool calls your existing API, database, or filesystem.
- Choose a transport. stdio for local, streamable HTTP for remote.
- Connect a host — point Claude Desktop, your IDE, or your agent at the server, and the tools appear automatically.
Building tool-using agents is core AI-engineering work in 2026. If you're leveling up toward it, our AI engineering roadmap and skills checklist cover the fundamentals underneath MCP and agents.
Frequently Asked Questions
What is MCP in simple terms?
MCP (Model Context Protocol) is an open standard for connecting AI apps to external tools and data. Instead of writing custom glue code for every tool in every AI app, you expose a tool once as an MCP server, and any MCP-compatible host — Claude, ChatGPT, an IDE, your own agent — can use it. Anthropic describes it as a 'USB-C port for AI applications.'
What is the difference between MCP and an API?
An API is a general interface you write code against, one integration at a time. MCP is one standardized, model-facing protocol that makes tools self-describing and reusable across every AI app. They aren't competitors: an MCP server usually calls an API under the hood — MCP is the layer that lets an LLM discover and use that API in a uniform way.
Is MCP better than a REST API?
It's not better or worse — it operates at a different layer. Use a plain API for deterministic app-to-app integration with no model in the loop. Use MCP when you want an LLM or agent to discover and call tools, especially across multiple AI hosts. In practice MCP servers wrap REST APIs, so you often use both together.
What is the difference between RAG and MCP?
RAG (retrieval-augmented generation) is a technique for pulling relevant knowledge into a model's context. MCP is a protocol for connecting tools and data sources. They're at different layers and are often combined — you can expose a retrieval/RAG capability as an MCP server so any agent can search your knowledge base as a standard tool.
Who created MCP and is it open?
MCP was introduced and open-sourced by Anthropic in late 2024. The specification is public, with SDKs in several languages, and it saw broad adoption across the industry through 2025 — including support from other model providers and many IDEs and agent frameworks.
Is MCP secure?
MCP is as secure as how you deploy it. Early versions had gaps — underspecified auth and prompt-injection / 'tool poisoning' risks — which the 2025 revisions addressed with an OAuth 2.1 framework, resource-server semantics, and a security best-practices spec. But you still own the risk of what you connect: treat third-party servers as untrusted, scope permissions tightly, and keep a human in the loop for sensitive actions.
What is the difference between MCP and A2A?
They cover different connections. MCP connects an agent to tools and data. A2A (Agent2Agent, from Google) connects agents to each other so they can discover and delegate work. They're complementary — an agent might use MCP for its tools and A2A to hand off to another agent. Google's ADK framework speaks both.
How do I build an MCP server?
Pick an official MCP SDK (TypeScript or Python are common), define the Tools, Resources, and Prompts you want to expose, wrap whatever API or data source they call, and run the server over stdio (for local) or HTTP (for remote). Point an MCP host — Claude Desktop, an IDE, or your agent — at it, and the tools become available automatically.
References
- • Anthropic — Introducing the Model Context Protocol
- • Model Context Protocol — official documentation and specification
- • MCP specification — versioning and revision history (2025-03-26, 2025-06-18)
- • MCP reference servers (GitHub)
- • A2A (Agent2Agent) protocol
- • Google Agent Development Kit (ADK) documentation
- • Simon Willison — the "lethal trifecta" (agent security)
- • JSON-RPC 2.0 specification