Comparison
MCP vs API: how the Model Context Protocol and direct API calls fit together
A comparison of MCP and direct API calls across eight dimensions, with rules for when each fits, checked against the specification on 2026-10-07.
MCP and an API are layers, not rivals. An API is how a service exposes functions to code. MCP is a protocol that lets an AI application discover and call tools in a standard way, and many MCP servers call an ordinary API underneath. Use a direct call when your code decides what to call, and MCP when a model needs to discover and choose among tools.
Last verified 2026-10-07. Sources are listed at the end of the page.
Is MCP a replacement for APIs?
No. The MCP specification describes tools as a way for language models to interact with external systems, such as querying databases, calling APIs or performing computations. The API stays where it is. MCP adds a standard way for an AI application to learn what is available and ask for it. For the protocol itself, see What is MCP. For retrieval versus tool access, see RAG vs MCP.
Kong's documentation shows the layering. Its AI MCP Proxy plugin can proxy MCP requests to upstream MCP servers, convert REST APIs into MCP tools and expose grouped tools as a managed MCP server. The REST API is still there, and MCP is a front for it. Kong lists that plugin as part of its Enterprise offering.
How do MCP and a direct API call differ?
The MCP column describes revision 2026-07-28 of the specification. The API column describes what is common to REST, GraphQL and SDK calls, and varies by provider.
| Dimension | Direct API call (REST, GraphQL, SDK) | MCP |
|---|---|---|
| Discovery | You read the provider's documentation, or a machine-readable description if the provider publishes one. A developer picks the endpoint ahead of time. | The client sends tools/list and receives the tools the caller may use, with names and descriptions. It can also call server/discover for supported protocol versions and capabilities. A server can announce list changes. |
| Schema | Whatever the API publishes. Quality and format vary by provider. | Each tool carries a JSON Schema for its input and may declare one for its output. A server that declares an output schema must return results that match it, and clients should validate them. |
| Authentication | The API's own scheme, such as keys or OAuth, held by your code. | Optional in the protocol. HTTP servers should follow the OAuth-based flow in the specification. stdio servers should take credentials from the environment. Token passthrough is forbidden. |
| State | Depends on the API. Many are stateless. Some use sessions or cursors. | The current revision is stateless: every request carries its protocol version and capabilities. A server that needs state hands out an explicit handle that the model passes back as an argument. |
| Who is the caller | Code you wrote, calling a known endpoint with arguments you control. | Tools are model-controlled: the model can discover and call them from context. The specification says a human should always be able to deny calls. |
| Versioning | Set by each provider through URLs, headers or SDK versions, with its own deprecation policy. | A date-string protocol version is sent on every request, and a server answers an unsupported version with an error that lists the versions it supports. The tool list can change over time, so review changes yourself. |
| Error handling | HTTP status codes and the provider's error body. Your code decides what to retry. | Two kinds. Protocol errors are JSON-RPC errors, such as -32602 for an unknown tool. Tool execution errors return a result with isError true and text the model can use to correct itself. |
| Governance | Existing API management: gateways, keys, quotas and logs. Mature and well understood. | The protocol cannot enforce security principles itself, so the host and the server must. Streamable HTTP mirrors the method and tool name into headers so a gateway can route and inspect without parsing the body, and servers must reject mismatches. |
When is a direct API call better, and when is MCP?
| Situation | Better fit | Why |
|---|---|---|
| Your code always calls the same endpoint with arguments it computes | Direct API call | No model chooses anything, so discovery and tool schemas add a layer with no job to do. |
| A model must choose among many tools at run time | MCP | tools/list gives it names, descriptions and schemas in one standard shape. |
| One integration used by one application you control | Direct API call or SDK | Fewer moving parts. You can add MCP later if more clients appear. |
| The same integration must work in several AI clients | MCP | The MCP site says it is meant to make it easy to build once and integrate everywhere across clients that support MCP. |
| Bulk or batch data movement | Direct API call | A tool call is a request a model decides to make. A pipeline that moves many records is better as plain code. |
| You need exact control of every field, retry and timeout | Direct API call | You own the call, the validation and the error path. A tool result is content returned to a model. |
| People connect their own AI application to a service | MCP | A server address or command and a consent prompt replace custom integration code. |
| You need a record of actions a model initiated | Either, with a gateway or host in front | Neither gives you policy on its own. The specification says clients should log tool use, and the control point is the host or a gateway. |
Why do so many MCP servers wrap an API?
A typical MCP server is a thin adapter. It turns a tool call into one or more API requests, handles authentication, pagination and rate limits, and shapes the response so a model can use it. Kong's plugin follows the same pattern: it maps MCP payloads to HTTP endpoints using OpenAPI schemas.
Wrapping has a trap. A server with one tool per API endpoint can expose dozens of tool definitions, and a client may load all of them into the model's context. Design tools around tasks, not endpoints, and keep the list short.
What about token cost and tool sprawl?
Anthropic's engineering post on code execution with MCP (4 November 2025) states two costs. First, "Tool descriptions occupy more context window space, increasing response time and costs." With thousands of tools connected, an agent may "process hundreds of thousands of tokens before reading a request." Second, tool results pass through the model's context. The post's example is a meeting transcript that flows through twice.
The post proposes that the agent write code which calls MCP tools, instead of loading every definition and passing every result through the model. That is one vendor's engineering proposal with its own worked example. It does not measure your workload. Count the tokens your own tool definitions use before you restructure anything.
How do you decide for one integration?
1. Name the caller
If your code always makes the call, use the API or its SDK. If a model chooses at run time, MCP is a candidate.
2. Count the tools
Count the tool definitions a model would see at once. Many tools mean more context and more room for wrong choices.
3. List the clients
If several AI clients need the same integration, one MCP server is less work than one custom integration for each.
4. Decide where credentials live
Decide whether each user signs in with their own identity or the server holds one key. The OAuth flow in the specification covers the first case.
5. Put a control point in front
Choose where limits, approvals and logs apply. The protocol will not do it for you, whichever side you pick.
Where Swfte fits, and when you do not need it
Whether a model reaches a service by a direct API call or through MCP, the control point sits in front of it. Swfte Connect is an OpenAI-compatible model gateway with bring-your-own-key, routing and fallback chains, budgets and usage caps, content-policy detectors for secrets and personal data with a redact action, and an audit event stream (Built). Connect also resolves a workspace's MCP tools when a request uses tool calling (Built). In Swfte Cortex, in-app tool approvals are bound to the exact call.
You do not need Swfte if your application calls one API from code: your existing API gateway and logging do the job, and MCP is not relevant until models choose tools. Per-tool allow and deny rules for MCP on the gateway path are designed for, not built. The MCP gateway page carries the status of each control, and How to set up an LLM gateway covers the model side.
Sources and last verified
Every dated or technical fact on this page was read from the pages below on 2026-10-07. Anything that could not be confirmed is left out or marked as not verified.
- MCP tools specification. Tool discovery, schemas, error handling and security considerations.
- MCP specification overview. JSON-RPC 2.0, stateless requests and per-request capability negotiation.
- MCP versioning. Date-string versions and version negotiation.
- MCP Streamable HTTP transport. Request headers a gateway can inspect and header-body validation.
- MCP authorization. Optional authorisation and the stdio exception.
- What is MCP (official introduction). The project's statement about building once and integrating everywhere.
- Anthropic: code execution with MCP. Tool definition context cost and result passing, with the vendor's proposed approach.
- Kong: AI MCP Proxy plugin. An example of REST APIs converted into MCP tools, and its Enterprise tier.
Frequently asked questions
Is MCP better than REST APIs?
Neither is better in general, because they do different jobs. A REST API exposes functions to code that you write. MCP lets an AI application discover tools and call them through a standard protocol, and many MCP servers call a REST API underneath. Use the API directly when your code chooses the call, and MCP when a model chooses.
Can MCP replace my API?
No. An MCP server needs something to talk to, and in most cases that is your existing API or database. MCP is a front that makes those functions discoverable to AI applications. Your API keeps its own authentication, quotas and versioning, and you will still need those for every other caller.
Does MCP use REST or JSON-RPC?
MCP messages are JSON-RPC 2.0. On the Streamable HTTP transport each message is sent as an HTTP POST to a single endpoint, and the reply is a JSON object or a server-sent events stream. On stdio the same messages travel as newline-delimited text between a client and a subprocess.
Should I wrap my API as an MCP server?
Wrap it when AI applications need to discover and call it, and more than one client will use it. Skip it when one application of yours calls a known endpoint from code. If you wrap it, design a few task-shaped tools rather than one tool per endpoint, and add authentication, input validation and rate limits.
Does MCP cost more tokens than calling an API directly?
It can. Anthropic's engineering post says tool descriptions occupy context window space and that results flowing through the model add cost, and it proposes calling tools from code to reduce both. The size of the effect depends on how many tools you load and how large the results are, so measure your own setup.
Is MCP more secure than a direct API call?
No. The specification says MCP cannot enforce its security principles at the protocol level, and tools represent arbitrary code execution. A direct API call has its own risks, but mature controls such as keys and quotas already exist. With MCP you add consent prompts, input validation, scoped tokens and logging yourself.