How does MCP compare to a plain REST/GraphQL API as an integration mechanism for LLMs?
Quick Answer
A REST or GraphQL API is designed for a developer to read documentation, understand the available endpoints, and write code calling them — there's no built-in mechanism for an LLM-driven client to discover what operations exist or what arguments they take at runtime. MCP adds exactly that missing layer on top: a standard way to enumerate available operations (tools/list, resources/list) with machine-readable schemas and descriptions specifically written for a model to reason about, plus a shared lifecycle/capability model so any MCP client can connect without bespoke integration code. In effect, an MCP server is often built on top of an existing REST/GraphQL API. It doesn't replace the underlying API. It wraps it in a self-describing, LLM-consumable interface, similar in spirit to how an OpenAPI/Swagger spec makes a REST API more discoverable, but purpose-built for the tool-calling/resource-reading patterns LLM applications actually need.
Detailed Answer
A REST API and an MCP server frequently sit on top of the exact same backend logic. The difference is who, or what, the interface is designed to be consumed by.
What a REST API assumes about its consumer
GET /api/v2/orders/{id}
Docs: "Returns order details. Requires an API key. See schema.json for the response shape."
A human developer reads this documentation once, writes integration code, and ships it. There's no standard, runtime-queryable way for an LLM-driven client that has never seen this API before to discover this endpoint exists, what it needs, or how to call it correctly. That knowledge has to be hand-encoded by a developer ahead of time, per app, per API.
What MCP adds on top
// tools/list response — discoverable and model-readable at runtime
{"tools": [{
"name": "get_order",
"description": "Fetch order details by order ID.",
"inputSchema": {"type": "object", "properties": {"id": {"type": "string"}}, "required": ["id"]}
}]}
Any MCP client, without prior knowledge of this specific API, can fetch this list at connection time and immediately know what's callable and how. The underlying implementation might literally just call GET /api/v2/orders/{id} internally. MCP hasn't replaced the REST API — it's wrapped it in a self-describing, model-consumable interface.
The analogy worth reaching for
This is similar in spirit to what an OpenAPI/Swagger spec does for human tooling: auto-generating clients, interactive docs. MCP is purpose-built for the specific patterns an LLM-driven agent needs instead: model-controlled tools with natural-language descriptions optimized for a model's reasoning, application-controlled resources, and a lifecycle designed around a conversational, multi-turn interaction rather than a one-shot request/response.
When plain REST/GraphQL is still the right choice
If the consumer is always going to be human-written application code, not an LLM deciding at runtime what to call, a conventional REST/GraphQL API remains simpler and better-tooled for that job. There's no reason to wrap it in MCP if no LLM-driven client will ever need to discover and call it dynamically. MCP earns its overhead specifically when the caller is an LLM that needs runtime discoverability, not compile-time-known integration code.