Protocol

MCP vs API

REST and GraphQL APIs move data between systems. The Model Context Protocol (MCP) standardizes how an LLM client discovers an external tool, learns its input schema, and invokes it during a conversation. Different layer of the stack, different contract.

Browse trust-scored servers Scan a server

The framing

A REST or GraphQL API exposes endpoints. The caller already knows the URL, the auth scheme, the request shape, and the response shape from out-of-band documentation (an OpenAPI spec, a GraphQL schema, a README). Every integration is hand-written against that documentation.

MCP runs one level up. It is a wire protocol over JSON-RPC 2.0 that standardizes three things: how an LLM client discovers what an external server offers, how the client and server negotiate supported features during an initialize handshake, and how the client invokes operations once it knows they exist. The model context protocol vs api distinction is layer, scope, and audience. APIs target application code; MCP targets the LLM agent loop.

The structural analog is the Language Server Protocol (LSP). Before LSP, every editor wrote per-language plugins for autocomplete and diagnostics. After LSP, any editor speaking the protocol works with any language server speaking it. MCP applies the same pattern to LLM clients and external tools.

What an MCP server gives you that a raw REST API doesn't

A REST API answers requests. An MCP server answers requests and advertises what it can do, in a format the LLM client can read and reason about at session start. Concretely:

Capability negotiation. The initialize handshake exchanges supported features. The server declares which of Resources, Tools, and Prompts it exposes. The client declares which of Roots, Sampling, and Elicitation it supports. Each side knows what is on the table before any operation runs.
JSON Schema for tool inputs. Every Tool ships with a JSON Schema describing its arguments. The LLM uses the schema to format requests. There is no per-vendor "function calling format" to translate against.
Structured outputs and standardized errors. Responses use the JSON-RPC 2.0 envelope (id + result or error), with reserved codes (-32601 Method Not Found, -32700 Parse Error) and MCP-specific application errors layered on top.
Change notifications. One-way JSON-RPC notifications let the server tell the client that its tool list changed mid-session, without polling.

The three server primitives vs the REST equivalent

MCP standardizes interaction around three server-side primitives, negotiated during the initialize handshake:

Resources are read-only data exposed via URIs (file contents, database schemas, API responses) that the model can pull into its context window.
Tools are invocable verbs with side effects, accompanied by JSON Schema for their arguments and structured results.
Prompts are parameterized message templates that the server provides for the client to offer to the user.

With a REST API, every one of these is custom integration code. The agent has to know which endpoint reads which file, how to pass arguments through a schema you wrote yourself, and how to surface server-suggested workflows in the UI. Every model vendor, every agent framework, every tool author writes their own glue.

One protocol instead of every pairwise integration

Before MCP, integrating each model vendor with each external tool required its own glue layer. OpenAI's 2023 function-calling API and ChatGPT plugins were vendor-specific implementations of this idea, and tool builders had to target OpenAI's specific schema. MCP collapses that combinatorial cost. Every model speaks one protocol; every tool exposes one server. Anthropic shipped the protocol in November 2024 and donated it to the Linux Foundation's Agentic AI Foundation in December 2025; OpenAI, Google, AWS, Cloudflare, and Bloomberg back the foundation. The protocol is now a neutral standard with the same governance pattern Kubernetes and OpenTelemetry use.

Side by side

How is MCP different from API integration in practice? The contract differs across every axis that matters to an agent engineer:

	REST / GraphQL API	MCP server
Audience	Application code	LLM client (agent)
Wire format	HTTP + JSON / GraphQL	JSON-RPC 2.0 over stdio, SSE, or HTTP
Discovery	Out-of-band (OpenAPI, README, schema)	In-band via `initialize` handshake
Input contract	Per-endpoint, written by hand	JSON Schema attached to each Tool
Vendor coupling	One integration per (model, tool) pair	Any MCP client works with any MCP server
Error semantics	HTTP status codes plus per-API conventions	JSON-RPC error codes plus MCP application errors
Change signaling	Polling or webhooks (per-API)	JSON-RPC notifications (`tools/list_changed`)
Security model	HTTP auth (Bearer, OAuth) at transport	Transport-dependent; stdio runs with host shell privileges

When to reach for which

Use a REST or GraphQL API when two systems exchange data and the calling code is written by a human who reads the docs. Use MCP when an LLM agent needs to discover and invoke tools at inference time without bespoke integration per (model, tool) pair. The two coexist. An MCP server often wraps a REST API: the server speaks MCP to the agent, then translates each Tool call into the underlying API request. The protocol does not replace APIs; it standardizes the surface an LLM sees.