MCP vs API: why a new protocol?
MCP and HTTP APIs both expose tools to software, but they target different consumers. APIs describe endpoints for general HTTP clients. MCP describes the same kind of capabilities for LLM agents: discoverable at runtime, with descriptions tuned for natural-language argument synthesis, over a stateful JSON-RPC session.
MCP and HTTP APIs both let agents call external tools, but they target different consumers. An HTTP API (REST, GraphQL, gRPC) describes endpoints for any client: a browser, a server, an SDK, a partner integration. MCP describes tools specifically for LLM agents, with runtime discovery, descriptions tuned for natural-language argument synthesis, and a stateful session over JSON-RPC 2.0.
MCP vs HTTP API at a glance
| Aspect | HTTP API | MCP |
|---|---|---|
| Designed for | General HTTP clients | LLM agents |
| Discovery | Static OpenAPI spec or docs | Runtime tools/list call |
| Argument format | Typed JSON Schema, strict | JSON Schema with LLM-friendly descriptions |
| Connection | Stateless HTTP requests | Persistent session with handshake |
| Unit of work | Endpoint (path + method) | Named tool with description |
Why a new protocol
APIs already work. The hole MCP fills sits above them. An OpenAPI spec describes an endpoint for a developer reading docs; an MCP tool description is written for an LLM choosing among options at runtime. MCP also defines a session: the client calls tools/list to discover what's available, then tools/call to invoke. That runtime introspection is what lets one Claude Desktop or Cursor install pick up a new tool without redeploying the client.
The non-obvious bit
MCP doesn't replace APIs, it sits on top of them. Many production MCP servers (GitHub's, Stripe's, Linear's) are thin wrappers around the same REST API a curl user would hit. The win is the agent-facing layer: tool names, descriptions, and argument hints rewritten so an LLM picks the right call on the first try instead of the fifth.
Pick when
Pick HTTP APIs when the consumer is a developer, an SDK, or a partner system, and stability matters more than agent ergonomics. Pick MCP when the consumer is an LLM agent and the tool list needs to change without client redeploys. Run both when you're shipping to mixed audiences: keep the OpenAPI surface, add an MCP layer that wraps it.
Last updated: May 20, 2026