Model Context Protocol vs API: when to use MCP, an API, or both

Key takeaways

• APIs expose operations that software can call.
• MCP exposes selected capabilities so AI applications can discover and use them.
• MCP commonly sits over an existing API. Add it only when task-dependent discovery earns the extra protocol and operating cost.

The useful Model Context Protocol vs API comparison starts with two separate boundaries. One boundary executes a capability. The other presents selected capabilities to an AI application. Once those jobs are clear, the architecture becomes a practical choice among a direct API, MCP over an API, and MCP traffic operated through a gateway.

Is Model Context Protocol an API?

MCP can be described as an API in a broad sense, but that label hides the important distinction. An API exposes operations that other software can call. An MCP server exposes capabilities to AI applications through a standard protocol. It describes tools and data sources in a model-agnostic form so language models can discover and use them through a structured API.

At the operation layer, an application may call a REST, GraphQL, or RPC interface. At the AI-facing layer, MCP presents selected capabilities in a form an AI application can inspect. MCP is built on JSON-RPC 2.0 and uses date-based versioning. That specifies how MCP participants communicate. It does not erase the service interface underneath.

The service API names operations available to software. Separately, the structured MCP API describes tools and data sources in a model-agnostic form for language models. JSON-RPC 2.0 provides the MCP communication basis, while the date-based version identifies the protocol revision. These are distinct architecture surfaces.

So the precise answer is: MCP is a protocol with a structured API surface for AI applications. A conventional service API and an MCP server can both exist in one request path because they solve different integration jobs.

Why use MCP instead of a direct API integration?

A conventional integration asks the developer to choose the required operations and encode those calls in advance. MCP lets an AI application inspect what a server has exposed and choose among those capabilities for its current task. The difference is who selects the operation and when that selection is expressed in the system.

The key mechanism is the tool definition. An MCP server can advertise a tool with a name, a natural-language description, and typed inputs. The AI application can compare that definition with its current task. The abstract shape looks like this:

name: <tool-name>
description: <what this capability does>
input: { <field>: <type> }
selection: match the advertised capability to the current task

Tools are only one MCP primitive. Servers can expose three different kinds of building blocks:

• A tool is an executable function.
• A resource is a data source.
• A prompt is a template.

That distinction keeps execution, data, and reusable prompt material visible in the server surface. MCP also supports notifications for dynamic updates and real-time synchronization. The capability surface can therefore advertise more than callable functions, while the AI application still chooses among the exposed capabilities for its task.

Discovery is the reason to add MCP. If the application already knows the exact operation it must call, the fixed API integration may already express the required behavior with less machinery.

Who talks to whom in MCP?

An MCP path has three named participants: the host, the client, and the server. The host is the AI application. A client is the protocol connector, and a server provides capabilities. One host can manage multiple client connections to servers. That arrangement lets the host connect through separate clients to more than one capability provider.

The basic request path is:

AI application (host)
 -> MCP client (protocol connector)
 -> MCP server (capability provider)

Transport depends on where the connection runs:

Local: host -> client -> STDIO -> server
Remote: host -> client -> Streamable HTTP, with optional SSE -> server

STDIO carries a local connection. Streamable HTTP carries a remote connection and can use optional SSE. These are transport choices inside the client-server architecture. They do not merge the three participant roles.

This separation matters when drawing the system boundary. The AI application is not the MCP server, and the connector is not the capability provider. Each client connection gives the host a route to a server surface. A host that manages several connections is therefore managing several protocol paths, not one undifferentiated pool of capabilities. For a deeper treatment of server placement and connections, use our MCP servers architecture reference.

The participant map also tells you where another layer could sit. A gateway belongs on the MCP traffic path when that traffic needs centralized operating controls. It does not change which participant owns the underlying capability.

When should you use MCP vs API?

An MCP request still lands on an API

MCP does not replace the API underneath it. In many implementations, the MCP tool ultimately calls the same REST, GraphQL, or RPC interface already used by the product. The model context protocol vs API example becomes much clearer when the full request path is visible.

Consider a Zotero MCP server. It gives an AI assistant access to a Zotero library and can run against either the desktop application's local API or the Zotero Web API:

AI assistant
 -> MCP client
 -> Zotero MCP server
 -> Zotero local API or Zotero Web API

The MCP surface changes how the AI assistant reaches the capability. The local or web API still performs the product-side operation. As an MCP API example, the path shows both layers at once. As an MCP vs API example, it keeps their jobs legible. The desktop path terminates at a local API. The web path terminates at a Web API. In both forms, the MCP server is the AI-facing capability provider.

LangGraph shows another implementation shape. A LangGraph agent can be exposed as an MCP tool to clients that support Streamable HTTP. Here, the agent itself is the capability presented to the MCP client. In its current implementation, each /mcp request is stateless and independent because sessions are not supported. That behavior belongs to this implementation. It should not be treated as the session model for MCP as a whole.

Together, the Zotero and LangGraph shapes show why “Is MCP replacing APIs?” is the wrong architecture test. The real question is which capability sits behind the MCP surface and how the request reaches it.

Discovery has a context and tool-design cost

Discovery consumes resources. When too many MCP servers are connected, tool definitions and results can consume excessive tokens and reduce agent efficiency. The cost comes from both the definitions presented to the model and the results returned through those tools. A larger catalog is not automatically a better interface for the model.

When API functionality becomes MCP tools, the useful change is in the granularity of the exposed surface:

Code execution can also let agents use familiar programming constructs to interact with MCP servers more efficiently. It is one available interaction pattern, not a reason to connect an unlimited tool catalog.

Authentication must preserve the MCP boundary

MCP authorization must preserve the server's validation boundary. Token passthrough is explicitly forbidden by the MCP authorization specification. Passing a downstream API token through the server avoids the validation boundary that the server is supposed to enforce.

A sound authority path has separate steps:

Client request and token
 -> MCP server validates the client and token audience
 -> MCP server applies its controls before a downstream API request

If a client uses a downstream API token without proper MCP-server validation, it can bypass controls that depend on token audience or credential constraints. Rate limiting may depend on that boundary. Request validation and traffic monitoring may depend on it as well.

An opaque token issued upstream creates a different audit problem. The MCP server may be unable to identify or distinguish the clients calling it. Several clients can then appear behind a credential the server cannot use to separate their identities. The server loses the client-level distinction needed to attribute those calls.

The design question is not merely whether authentication exists. It is whether the MCP server can validate who is calling, preserve the intended token audience, and apply its own controls before reaching the downstream API. Our authorization boundary reference provides a useful frame for marking where identity and permission change.

Local MCP servers inherit the client's authority

A local connection can move the MCP server inside the client's machine-level authority boundary. If that server is untrusted or inadequately restricted, it can execute commands with the MCP client's privileges. The mechanism is direct:

MCP client privilege
 -> local MCP server executes a command
 -> command affects files on the host machine
 -> an attacker or bug can cause irrecoverable data loss

The user may have no visibility into the commands such a server executes. Local transport does not remove that risk. It places command execution and host data within the authority available to the client process.

That changes the review standard for a local MCP server. The capability description alone is not enough to understand the possible consequence. The server's restrictions and trustworthiness govern whether the stated risk applies. When restrictions are inadequate or the source is untrusted, commands can run with client privileges and reach data on the host machine.

Visibility and impact are separate concerns. A user may not see the commands the server executes. An attacker or a bug can still use that command path in a way that causes irrecoverable host data loss. The absence of a visible command trail does not narrow the authority inherited from the client process.

This is why a convenient local path still needs an explicit authority map. Mark the process privilege, the commands the server can execute, and the host data inside that boundary before treating the connection as routine.

Tool descriptions are part of the attack surface

The descriptions that make MCP tools discoverable are also text read by the model. Tool poisoning occurs when a malicious or compromised server embeds adversarial instructions in those natural-language descriptions. The attack travels through the discovery surface itself.

A description-control path can be kept concrete:

Approved baseline: <known-good tool description>
Changed version: <description containing an unexpected instruction>
Control: compare with baseline -> detect anomaly -> alert on change

Tool-poisoning defenses need known-good baselines, anomaly detection, and alerts when descriptions change. Baseline validation compares the current description with an approved version. Anomaly detection looks for unexpected content. A change alert makes the difference visible between sessions. Each control addresses a separate part of the description-change path.

The tool description is one action path. User input is another. Malicious input can cause an AI assistant to invoke unintended MCP tool actions. An agent can also misuse delegated authority by reaching resources or performing actions it should not.

These risks meet at invocation. Discovery tells the model what it can call, input affects what it chooses, and delegated authority determines what the chosen action can do. Description monitoring, permission boundaries, and invocation controls each cover a different point on that path.

Gate and recover production MCP traffic

An MCP gateway can operate traffic before invocation through session-aware routing, SSE streaming support, authentication, rate limiting, and observability. It can limit tool calls per minute, cap concurrent sessions, and set per-agent budget caps. This is the MCP vs API gateway distinction that matters in production: the gateway operates MCP traffic, while the service API remains the capability's execution interface.

A gateway does not make the traffic safe by itself. Its value comes from the controls that are actually configured and observed. The call-rate limit constrains invocation volume. The session cap constrains concurrency per agent or MCP server. The budget cap constrains runaway costs from expensive tool calls.

Recovery starts after prevention fails. Incident-response planning for AI components can include credential rotation and a quick return to known-good versions. Both actions need a prepared target. Rotation applies to the credentials in the affected path. Reversion applies to an earlier known-good component version.

That gives the operating plan two explicit recovery moves after a compromise is found. Rotate the relevant credentials. Revert the affected AI component to the selected known-good version. These actions belong in incident-response planning for the gateway path.

Use the direct API, MCP-over-API, and gateway options as architecture boundaries, not category labels. Then compare MCP with the larger agent system at the layer, authority, and control points that decide what can act and how you recover.