MCP vs API: what's actually different, and why it matters

"We already have an API, why add a protocol?" It is the objection I hear most often in architecture reviews, and it is fair. The answer is not that MCP replaces your API. It is that your API and the model do not speak the same language. An endpoint that exists, and a model that knows when and how to call it at runtime, are two different problems.

The starting point: an API already exists, so why a standard

You probably already have a REST, GraphQL or gRPC API. It is documented, authenticated, versioned. From an engineer's seat, an agent that needs to read a customer record just calls GET /customers/:id, end of story. Except an API is written for a developer: someone who reads the docs, picks the right endpoint and writes the calling code. A model, at runtime, has none of that. It has a conversation, a context, and a decision to make. The whole gap between "the endpoint exists" and "the model knows how to use it at the right moment" is exactly what a standard fills.

What a plain API does, and what it never tells the model

An API exposes operations. What it does not provide, in a form a model can consume at runtime: the list of available actions, what each one is for in plain language, the expected arguments and their shape, what a call returns, and how to authenticate for this specific user. An OpenAPI spec covers part of it, but it is meant for build time, not for a model deciding live. So today teams hand-write one "tool" per endpoint, then rewrite it again for each framework. Invisible, repeated work, never quite identical from one app to the next.

• The description the model reads to understand when and why to use the tool.
• The argument schema, and its validation before the call.
• Per-user authentication, not one token that gives everyone everything.
• Formatting the result so it fits the context window: pagination, truncation.
• Turning API errors into something the model can understand and recover from.

What MCP adds: describing and calling your tools in a standard way

MCP does not replace your API: it sits in front of it. An MCP server exposes your capabilities in a standard shape the model layer already knows how to read: tools (actions), resources (readable data), and reusable prompt templates. Each tool carries its own description and input schema, and the client (Claude, or your agent runtime) discovers them at connection time, with nothing hard-coded. That is the real shift: the tool definition lives with the tool, once, server-side, instead of being copy-pasted into every application. The idea is close to an OpenAPI spec, but consumed at runtime by the model, plus the call transport and the authentication story. For the non-technical version, the one to hand a leader, I wrote MCP, the standard that plugs AI into your tools.

MCP vs proprietary plugins: the lock-in trap

Before MCP, wiring a model to tools meant each vendor's own format: one platform's plugins, one framework's "tools", another's "actions". Each with its own manifest, its own auth flow, its own lifecycle. A connector written for one does not run on the others: that is lock-in at the integration layer, the least visible kind and the most expensive to undo. MCP breaks that by being a shared standard: adopted by Anthropic, OpenAI, Google and Microsoft, then handed to the Linux Foundation in late 2025. What matters here, more than the tech, is the neutral governance: a connector written against MCP keeps working when you switch model or agent framework.

Write the connection once, reuse it everywhere

The concrete architectural payoff: you expose your CRM (or your ticketing tool, or an internal database) as a single MCP server. Then your support agent, your internal copilot and a future workflow all consume that same server. One place for authentication, quotas, the audit log and the tool descriptions. One place to fix when there is a bug, or to tighten when a permission is too broad. You stop maintaining N nearly-identical connectors scattered across N applications. It is the technical version of what I describe in connecting AI to your existing tools.

One connector per tool, not one connector for every tool / application / framework combination. That is where the integration cost stops multiplying.

When a plain API is enough, when MCP earns its place

Not everything needs MCP, and I will say it plainly. A direct call to your API is more than enough when the integration is deterministic, lives in a single application, and the control flow is written by a human: a cron job hitting an endpoint does not need a protocol for the model. The default rule I use: if a human wrote the control flow, a plain API call does the job; if the model writes the flow at runtime (an agent, in the real sense), you want your tools described in a standard the model layer understands.

• A model or agent decides for itself which tool to call, and in what order.
• Several applications or agents share the same tools.
• You want to switch models without rewriting your connectors.
• You expose your tools to other teams, or to third parties.

What it means for your architecture and your security

MCP concentrates the "what can the AI do" surface into a single, addressable layer. That is good for control, and it also concentrates the risk in one place. Treat an MCP server like any other privileged service: it gets tested, versioned and handles partial failures like a production API, which is the subject of reliability in production. Concretely, a few non-negotiable rules:

• Behind your authentication, scoped per user, not one all-powerful token.
• Least privilege per tool: each action only reaches what it strictly needs.
• Human validation on irreversible actions: payment, deletion, writing to a customer.
• Every call logged, so you can audit after the fact.
• Never a server exposed on the internet without authentication: hundreds have already been found wide open.

One last architectural point: because the server can run where your data lives, MCP pairs well with private or on-premise hosting when sovereignty matters. None of this is a plugin you install in five minutes: it is a design decision, sitting between your existing APIs, your agents and your security constraints. If you are weighing where MCP fits in your stack, that is exactly the kind of call I take on as an AI architect.