The one-sentence version: an API is a contract written for a programmer; MCP is a contract written for a model. MCP does not replace APIs — it is a standard wrapper that sits on top of them, and underneath almost every MCP server is a plain REST call.
The analogy
A REST API is a wall socket: fixed shape, fixed voltage, documented in a manual somewhere. It works perfectly — provided you already know which plug you need and you built the plug yourself. The socket assumes a human read the spec in advance. MCP is a socket that announces itself: walk up and it tells you, in a language you can act on, what it offers right now and what it needs from you to proceed. No manual, because it describes itself at the moment of use.
The official framing is “USB-C for AI” — one connector, not a cable per device. Useful, but it undersells the point: USB-C standardizes the shape; MCP standardizes the self-description. That's the part a model actually needs, because it can't go read your docs before it acts.
The job-to-be-done split
| REST / GraphQL API | MCP | |
|---|---|---|
| Whose job | Let a developer's code call my service | Let a model find and use my service with no developer in the loop |
| Who reads the docs | A human, in advance, once | The agent, at runtime, every session |
| Consumer | Code you wrote deliberately | A model deciding on the fly |
| Failure mode | Breaking change ships, your code 500s | Tool description is vague, model picks wrong |
| Born | REST 2000, GraphQL 2015 | Nov 25, 2024 (Anthropic) |
What's genuinely the same
- Both are contracts over a network boundary — request in, structured response out. Neither is new physics.
- Both ride HTTP. MCP speaks JSON-RPC 2.0 rather than HTTP verbs, but it's the same wires.
- Both need auth, rate limits, versioning and error handling — MCP has re-learned each, mostly the hard way.
- Both are usually the same service. An MCP server is very often a thin layer over a REST API that already existed.
What's genuinely different — three things, not ten
- 1. Runtime discovery. The agent asks
tools/listand gets a machine-readable catalogue of what exists now. Add a capability server-side and every client can use it with no code change. REST has no equivalent — OpenAPI describes an API to a human or a codegen step, not to a running model mid-decision. This is the actual difference; the rest is detail. - 2. The N×M collapse. M agents × N services = M×N bespoke adapters. One standard makes it M+N — the argument that justified USB, ODBC and LSP, and it has worked every previous time.
- 3. Descriptions are the interface. In REST the endpoint name is a label; in MCP the tool description is what the model reasons over. Prose quality becomes an engineering property. Writing the description IS the design work.
⚠ What changed in July 2026 — most comparisons you'll read are now wrong
“MCP is stateful, REST is stateless” was the standard talking point. As of the 2026-07-28 spec it is false. That release turned the protocol core into stateless request/response: the
initialize/initialized handshake and the Mcp-Session-Id header were removed; each request now carries its own version, identity and capabilities. Held-open server-initiated streams were replaced by Multi Round-Trip Requests — the server returns input_required and the client retries with answers. Legacy HTTP+SSE is deprecated; Roots, Sampling and Logging are deprecated on a 12-month clock.Why it matters: the change exists so MCP servers can sit behind ordinary load balancers, routing and authorizing on HTTP headers (Mcp-Method, Mcp-Name). MCP moved toward the operational model of a REST API, not away from it. Any article comparing the two on statefulness describes a protocol that no longer exists — check the date on anything you read.
Who owns it now
Not Anthropic. In December 2025 MCP was donated to the Agentic AI Foundation, a Linux Foundation directed fund co-founded by Anthropic, Block and OpenAI. Adoption ran ahead of the handover: OpenAI March 2025, Google DeepMind April 2025, ChatGPT apps September 2025. A protocol your competitor donates and you adopt has stopped being a strategy and become plumbing — usually the moment a standard is safe to build on.
The decision table — your JTBD
| If the job is… | Reach for | Because |
|---|---|---|
| A web or mobile app you're building | REST | You know the calls at build time. Discovery buys nothing. |
| High-volume data reads | REST | HTTP caching and CDNs. MCP adds a hop and a token cost. |
| Letting Claude/Cowork touch your system | MCP | The whole point. Discovery, one auth story, no glue code. |
| Third parties integrating with you | REST first, MCP alongside | Their developers still want an SDK. Ship both; they aren't rivals. |
| An internal tool only you and agents use | MCP | Skip the SDK, skip the docs site. The description is the docs. |
| Something with real blast radius (money, deletion, sending) | REST behind a human | See security, below. Don't hand a model an irreversible verb. |
The anti-pattern, stated plainly: auto-converting every REST endpoint into an MCP tool. Good REST design means hundreds of small composable endpoints — correct for a developer, ruinous for a model, because every tool description is spent context and a hundred near-identical options is a choice the model will get wrong. MCP tools should be fewer and larger than your endpoints — shaped around jobs, not around resources. Principle §2, applied to a protocol.
Security — the part that is genuinely worse
MCP inherits every API risk and adds one with no REST analogue: the consumer can be talked into things. A REST endpoint does what your code told it to; an agent does what it was persuaded to — and the persuasion arrives inside the data it reads.
- Prompt injection — hostile instructions embedded in content the agent retrieves.
- Poisoned tools — a malicious server whose descriptions steer the model, including into exfiltrating data through other connected tools. Documented since April 2025.
- Cross-tool blast radius — risk isn't per-server; it's the product of everything connected at once. Two safe tools can compose into an unsafe one.
The NSA published MCP security design guidance in June 2026 — a fair marker of how seriously this is taken. Practical rule for the harness: least privilege per server; never connect a read-anything tool to a send-anything tool in the same session. The cos- security pulse in one line.
Adoption — with the caveats attached
| Figure | Source & date | Read it as |
|---|---|---|
| 10,000+ public servers | Anthropic, Dec 2025 | Vendor count, generous definition |
| 9,652 registry records | Registry API snapshot, May 2026 | The auditable number |
| 97M+ monthly SDK downloads | Anthropic, Dec 2025 | Includes CI and bots |
| 41% at some production level | Stacklok survey, 2026 | 12% broad production. The honest one. |
Epistemics note (§11): a widely-repeated “78% enterprise adoption” figure was unsourced and has since been removed from the tracker that carried it. The real picture is 12% in broad production — a protocol that has clearly won the argument and is still early in the deployment. Both halves of that sentence are true; most coverage picks one.
The three sentences to keep
- MCP is not an API replacement. It's a self-describing wrapper so a model can use an API without a programmer pre-wiring the call.
- Runtime discovery is the only difference that matters. Statefulness was never the real distinction, and as of July 2026 it isn't a distinction at all.
- The tool description is the product. Design it the way you'd design an interface, because for the model, it is the interface.
Page 2 — Terms sheet
| Term | What it actually means |
|---|---|
| API | Application Programming Interface — any documented way one piece of software calls another. The umbrella term; REST and MCP are both under it |
| REST | The dominant web-API style since ~2000. Resources at URLs, HTTP verbs (GET/POST/PUT/DELETE), stateless requests |
| GraphQL | Alternative to REST — client asks for exactly the fields it wants in one query. Fixes over-fetching; costs caching |
| Endpoint | One callable address on an API — /users/42. A REST API is a set of endpoints |
| JSON-RPC 2.0 | A minimal “call this method with these arguments” convention over JSON. MCP's message format — simpler and older than REST-style design |
| MCP | Model Context Protocol. Open standard, Anthropic, Nov 2024; donated to the Linux Foundation's Agentic AI Foundation Dec 2025 |
| MCP server | The thing exposing capabilities — your Gmail connector, your file bridge. Usually a thin layer over an existing API |
| MCP client / host | The thing consuming them — Claude, Cowork, an IDE. One client, many servers |
| Tool | An action the model can take (send, create, query). The primitive that does something |
| Resource | Content the model can read (a file, a record). Data, not action |
| Prompt | A reusable templated instruction a server offers. The least-used of the three primitives |
tools/list | The discovery call. The agent asks what's available; this is the mechanism the whole value proposition rests on |
| Tool description | The prose telling the model what a tool does and when to use it. In MCP this is not documentation — it's the interface |
| MRTR | Multi Round-Trip Requests — 2026 replacement for held-open streams. Server says input_required, client retries with answers |
| Stateless (2026-07-28) | Each request self-contained; no session handshake, no session ID. Lets MCP servers sit behind ordinary load balancers |
| SSE | Server-Sent Events — one-way server→client stream. MCP's legacy transport, now deprecated |
| N×M problem | M clients × N services = M×N custom adapters. A shared protocol makes it M+N. The core economic argument for any standard |
| OpenAPI / Swagger | Machine-readable REST description. Closest REST relative to discovery — but read at build time by tooling, not at runtime by a model |
| OAuth 2.1 / PKCE | The modern delegated-auth flow. MCP is opinionated about it where REST allows anything; scoped tokens say exactly what an agent may do |
| Prompt injection | Hostile instructions hidden in content the agent reads, hijacking its behaviour. The risk class with no REST equivalent |
| Poisoned tool | A malicious server whose descriptions manipulate the model — including into leaking data through other connected tools |
| Least privilege | Connect the narrowest capability that does the job. The only reliable defence when the consumer can be persuaded |
| Agentic AI Foundation | Linux Foundation directed fund, Dec 2025 — Anthropic, Block, OpenAI. MCP's current home; why it's plumbing, not strategy |
| Connector | Product word for “an MCP server someone else already built and hosts” |
APIs & MCP Primer · @ Singularity 🧠/Technologies · v2 compact · Sep 5, 2026 · spec details from the 2026-07-28 MCP specification; adoption figures dated and attributed in-table — the vendor counts and the survey disagree, and both are shown. Sources: modelcontextprotocol.io, Wikipedia, WorkOS, digitalapplied MCP tracker, NSA MCP security guidance (Jun 2026).