MCP vs API

If you have spent any real time building systems that talk to each other, you already know what an API is in your bones, even if you have never memorized a formal definition. An API is a contract. It says: send me a request formatted this way, with these credentials, at this endpoint, and I will send back a response formatted that way. REST, GraphQL, SOAP, gRPC: different flavors, different trade-offs, but the same underlying philosophy. The machine on one end knows exactly what the machine on the other end expects.

The most important design decision baked into that philosophy is statelessness. Every API call carries everything the server needs to fulfill it. The server has no memory of your last call, no awareness of where you are in a broader workflow, no interest in what you are trying to accomplish. That is not a flaw. It is precisely what makes APIs predictable at scale. You can route any request to any instance of the server, and the result is identical. Statelessness is what lets you put ten servers behind a load balancer and not worry about which one answers.

APIs were designed for developers. The caller already knows the endpoint. The caller formats the request correctly. The caller handles the token. The API itself is passive; it does not explain what it does. Documentation does that. This assumption, that the caller is a human engineer who has read the docs and knows the system, is everywhere in API design, so pervasive that it is invisible until you encounter a caller who cannot read documentation at all.

That caller is an AI agent. And that is where the story of MCP begins.

What MCP is, where it came from, and the specific frustration it addresses

The origin of the Model Context Protocol is refreshingly unglamorous. A developer named David Soria Parra was tired of manually copying code between Claude Desktop and his IDE. Not a grand architectural insight. Not a whiteboard full of systems diagrams. A specific, daily annoyance. Anthropic published the spec in November 2024, and the practical itch it scratched resonated immediately.

By May 2025, the ecosystem had grown from roughly 100 public servers to over 4,000, according to Pulse. By December 2025, Anthropic's own ecosystem update reported more than 10,000 active public servers and 97 million or more monthly SDK downloads across Python and TypeScript. That rate of adoption is not driven by hype alone. It is driven by developers recognizing the same friction David was experiencing.

MCP is, technically, an open JSON-RPC-based standard. An AI application connects to an MCP server through a session. The server exposes capabilities as discoverable, typed functions. The agent can ask, at runtime: what tools do you offer? The server answers with a machine-readable list, including what each function expects as inputs and what it returns. The agent then invokes the appropriate function.

Three components do this work. The host is the AI application the human actually uses, something like Claude Desktop or ChatGPT. The client lives inside the host and maintains a persistent, one-to-one connection with a specific server. The server is where the capabilities live, the thing that exposes tools, prompts, and resources. Transport runs either through stdio for local connections or Streamable HTTP for remote ones; an older HTTP with server-sent events transport was deprecated in 2025. Authentication, historically a free-for-all across API ecosystems, was standardized to OAuth 2.1 for remote servers in the March 2025 spec update, with token handling tightened further in November 2025.

The governance signal worth noting: MCP is no longer Anthropic's protocol. It moved to the Agentic AI Foundation under the Linux Foundation at the end of 2025, with Anthropic, Block, and OpenAI as co-founders, and Google, Microsoft, AWS, Cloudflare, and Bloomberg among the backers. That vendor-neutral stewardship matters enormously for any organization deciding whether to build infrastructure around it.

The structural difference that makes MCP and APIs distinct

Here is the sharpest way I know to state it: APIs connect machines to machines. MCP connects intelligence to machines.

The distinction is not rhetorical. Consider what happens when you ask a large language model to call an API directly. The model has no built-in execution environment. It cannot store credentials securely. It has no inherent scope limits; left unconstrained, it could make arbitrary network requests, expose keys, access private data, or trigger unintended writes. The model needs a controlled intermediary between its reasoning and your systems. MCP is that intermediary.

Discovery is the most consequential structural difference, and it is easy to understate. A traditional API does not explain itself. The caller must already know the endpoint, the schema, the authentication pattern. None of that knowledge lives in the API; it lives in documentation, in the developer's memory, in a Postman collection someone maintains. An MCP server, by contrast, can be queried. Ask it what tools it offers, and it answers, in a format the agent can parse and act on. The agent learns what is possible at runtime, without a human having pre-programmed every contingency.

This is what enables autonomous multi-step workflows. A stateless API call is self-contained; the API has no awareness of the agent's broader goal or of what happened three calls ago. An MCP session maintains that context. Each action is informed by prior ones. The agent is not just executing a function; it is navigating toward an objective.

The endpoint-versus-capability distinction matters too, even if it sounds subtle. APIs expose URLs: /users, /weather. MCP exposes typed functions: getuserinfo, get_weather. But why exactly does this matter? The model calls functions and interprets their outputs as meaningful operations, not as HTTP verbs pointed at resource paths. The semantic layer is built in — and that changes how an agent reasons about what to do next, not just how it formats a request.

The N×M integration problem MCP was built to collapse

Imagine you have five AI agents and ten tools. Under a traditional integration model, each agent needs a custom integration for each tool: its own auth handling, its own schema mapping, its own error-handling logic. That is fifty bespoke integrations. Add one new tool, and you write five new integrations, one per agent. Add one new agent, and you write ten new integrations, one per tool. The combinatorial math is punishing.

MCP changes the arithmetic. Each tool implements one MCP server. Each agent implements one MCP client. Five agents plus ten tools equals fifteen implementations, not fifty. The crossover point where MCP starts generating a real return on setup investment sits at roughly three to five integrations. Below that threshold, the overhead of standing up an MCP server may not be worth it. Above it, the economics compound quickly.

For enterprises, this is not a hypothetical calculation. Large organizations are not connecting one agent to one tool. They are building systems where multiple agents need simultaneous access to overlapping sets of internal data, SaaS platforms, and underlying APIs. The integration surface is enormous, and it grows every time a new agent or a new data source is added. An 87% majority of IT leaders rated interoperability as crucial for agentic AI adoption in 2025. Gartner's strategic forecasts suggest that by 2026, three-quarters of API gateway vendors and half of iPaaS vendors will have incorporated MCP features. The integration layer is precisely where the industry expects the pressure to concentrate.

How MCP and APIs actually work together in practice

The most important thing to understand about MCP in a production environment is that it does not replace your APIs. It wraps them.

Your existing endpoints stay where they are. Your data pathways stay intact. What MCP adds is an orchestration layer: an AI agent can now discover which API to call based on its goal, interpret the results in the context of a broader workflow, and connect data points across multiple API responses without a human manually stitching them together. The underlying plumbing is unchanged. The intelligence operating on top of it is new.

A useful concrete case: a web-data service that offers screenshot capture, metadata extraction, scraping, and HTML-to-markdown conversion can expose exactly the same capabilities through both a conventional REST API and an MCP server. A developer building a deterministic, high-throughput pipeline uses the REST API directly. A developer building an autonomous agent that needs to decide at runtime whether to screenshot or scrape uses the MCP server. Same underlying service. Different interface for different contexts.

Three broad patterns have emerged in enterprise deployments. First, internal-data MCP servers that expose data lakes, knowledge bases, and ticketing systems to AI assistants without requiring per-agent custom code. Second, vendor-published MCP servers from major SaaS platforms, Snowflake, Databricks, Salesforce, ServiceNow, Atlassian, GitHub among them, making the SaaS layer natively accessible to agents. Third, MCP gateway and proxy patterns that layer authentication, audit logging, and policy enforcement on top of existing API infrastructure. Each pattern is additive. None of them require dismantling what already works.

When to use APIs directly and when to route through MCP

This is the practical question, and I want to answer it plainly.

Use direct API calls when the workflow is deterministic: fixed endpoints, known logic, no AI reasoning involved. A cron job pulling metrics every hour gains nothing from dynamic tool discovery or stateful sessions. A webhook receiver, a scheduled export, a health-check monitor, a bulk data pull with complex pagination: these are all cases where a developer-managed API call with explicit filtering is more reliable, less expensive, and considerably faster. A direct API call runs in the neighborhood of 100 milliseconds.

Route through MCP when an AI agent needs to discover and select tools at runtime rather than at build time. When multi-step workflows require that prior actions shape subsequent ones. When multiple agents need access to the same tool ecosystem without per-agent custom code. When your integration count has crossed the threshold where MCP's economics start compounding in your favor.

The latency and cost reality deserves a clear look. When an agent uses an MCP tool, it reads the tool's description, which consumes somewhere between 500 and 1,000 tokens depending on schema complexity. It decides whether to call the tool, constructs the parameters, makes the call (still roughly 100 milliseconds at the network layer), and processes the response. The full round-trip runs closer to two to three seconds and roughly 2,000 tokens. At current model pricing in the range of a few dollars per million input tokens, a single MCP tool call costs in the vicinity of one to two cents. A session involving five to ten tool calls runs perhaps five to twenty cents. Trivial for conversational workflows. Material for high-volume automation where you are running thousands of sessions a day.

It is also worth considering context window overhead as a real constraint. Each MCP tool definition consumes somewhere between 550 and 1,400 tokens depending on schema complexity. Load too many tools simultaneously and you start crowding out the context the agent needs to reason about the actual task. This is a design consideration, not a reason to avoid MCP, but it is a consideration you should be making deliberately.

Pagination, bulk data pulls, and complex transformations remain areas where MCP is weaker than direct API management. For those use cases, hand the reins back to the developer.

What governing MCP servers requires that API governance didn't

API governance was, broadly speaking, a solved problem. You knew your endpoints. Your schemas were documented. Rate limits were set. Auth was static. Audit logs could be reconstructed from request logs after the fact. The systems you were governing were passive; they did what they were told.

MCP changes the threat surface in ways that API management tools were not designed to handle.

Agents select tools dynamically at runtime. The set of systems touched during a single session is not predetermined. You cannot write a policy based on which endpoints will be called, because neither you nor the agent knows in advance. A single MCP server can expose multiple tools across multiple underlying systems; one ungoverned server is not one ungoverned access path, it is several. And without a registry, you have no inventory of what servers exist, what they expose, or which agents are calling them.

There is a security dimension that deserves specific attention. MCP servers introduce prompt injection as a distinct attack vector. A malicious or misconfigured server can instruct an agent to take actions the human operator never intended. Security researcher Simon Willison has written about this specifically in the context of MCP, and it is not a theoretical concern. When an agent trusts the output of a server to inform its next action, the server becomes a mechanism for influencing the agent's behavior.

What governance at the MCP layer actually requires is different in kind from API governance. You need a server registry: every MCP server your organization runs or consumes needs an identity and an owner. You need real-time observability into which tools an agent invoked during a session, not an after-the-fact log review. You need role-based access control scoped to agents, not just users, because what this agent is permitted to call is a deliberate policy decision that cannot be inferred from the user's permissions alone. And you need a gateway or proxy layer that enforces those policies before calls reach underlying APIs or data systems.

Stacklok's 2026 survey found that 41% of software organizations were already in limited or broad production with MCP servers. Governance at the MCP layer is not a future concern. Organizations are already operating in production environments where ungoverned servers create real exposure. The gap between experimentation and governed deployment is precisely this layer.

What the MCP-and-API stack looks like for enterprises building agentic systems now

The mature enterprise stack is not MCP replacing APIs. It is layers, each with a distinct job.

APIs remain the stable, high-throughput, deterministic data and integration layer. Nothing about MCP's arrival changes what APIs do well or makes them less appropriate for the use cases they were built for. MCP servers sit on top, forming the orchestration and discovery layer that makes those APIs accessible to AI agents without per-agent custom integration work. An MCP gateway sits on top of that, providing policy enforcement, access control, and the observability that makes the whole layer safe to operate in production.

The practical sequencing question organizations face is not whether to replace their API infrastructure. It is: which existing APIs are worth exposing through MCP servers, to which agents, under what access policies? That is a governance and architecture question, not a migration question.

The vendor-neutral stewardship of the protocol under the Linux Foundation matters for this decision. Building governance infrastructure around a protocol controlled by a single AI vendor is a different risk posture than building around an openly governed standard with broad industry backing. That distinction will affect procurement decisions, compliance conversations, and long-term architecture commitments.

Where most enterprises actually are right now is somewhere between experimentation and governed production. The protocol is ready. The ecosystem is substantial. The tooling for governance is emerging. The gap is organizational: most teams have not yet built the registry, the access-control model scoped to agents, or the real-time observability that distinguishes a governed MCP deployment from an ungoverned one.

That raises an important question: is the "MCP versus API" framing even the right one? The answer is not which one to use. It is what each one is for, and whether your governance model has kept pace with the layer you are actually now operating at. For most organizations building agentic systems today, the candid answer to that second question is: not yet, but that is the work.