MCP vs API: when a connector beats a normal integration

By Gerald · 9 August 2026

Railway tracks curving through a junction where multiple lines converge and switch

Is MCP just an API with extra steps? I get this question from developers who already have a working REST API and are being told they need an MCP server too. The honest answer is that MCP is not a replacement for your API, it is a standard way to describe that API so an AI model's client can find it, understand its shape, and call it correctly without you writing custom prompt instructions for every integration.

You need MCP when more than one AI client will call your service and you do not control what each client looks like. You do not need it when you are the only caller and you already know the shape of your own endpoints.

MCP is not a new way to move data. It is a standard way to describe the data you already move, so a model can use it without a human writing glue code first.

What each one is responsible for

An API, in the REST sense most developers mean, is a contract for moving data between two systems. Both sides already know the shape of that contract. You write the endpoint, you write the client that calls it, and both were built with knowledge of each other.

MCP, the Model Context Protocol, is different. It is a specification for how an AI client discovers and calls tools exposed by a server, using structured schemas the client did not need to be told about in advance. The protocol's own documentation describes servers exposing tools, resources, and prompts through one consistent interface a client can introspect at runtime.

The distinction that matters: a REST API assumes the caller was written with knowledge of the API. MCP assumes the caller has never seen your service before. It needs to learn the shape of your service from the protocol itself, not from a document a person read and translated into code.

The part MCP standardises that an API does not

A pencil and ruler resting on a technical blueprint drawing — MCP is closer to a wiring standard than a new kind of pipe.

Every AI integration built directly against a REST API needs a translation layer: which endpoint does what, what the parameters mean, when to call it, what a valid response looks like. Historically that translation lived in a system prompt, hand-written and specific to one model client. It broke quietly whenever the API changed and the prompt did not.

MCP moves that translation into the protocol layer instead. A server describes its own tools with names, descriptions, and JSON Schema parameter definitions that travel with the connection itself. Any MCP-compatible client, Claude, ChatGPT, or another agent, can read that description and call the tool correctly. No developer has to write model-specific instructions first.

This is the actual value MCP adds over calling your API directly: it is not a faster way to move bytes, it is a way to stop hand-writing and maintaining a natural-language description of your API for every model client that wants to use it.

Tool discovery and why it changes the integration cost

With a plain API, adding a new endpoint means updating whatever documentation or prompt tells the calling system that endpoint exists. If three different AI products integrate with your API, that update happens three times, in three different formats, and drifts out of sync in practice.

With MCP, a client calls a discovery method and receives the current list of available tools with their schemas, generated from the server's own definitions. Add a tool to the server and every compliant client sees it on the next connection, no separate documentation update required for each caller. This is the mechanism that makes MCP worth building when your service has, or will have, more than one AI client integrating with it: the discovery cost is paid once, at the protocol level, instead of once per client.

Auth, permissions, and audit differences

MCP's authorization model has matured significantly since the protocol's early releases. The current specification builds authorization on OAuth 2.1, with a protected MCP server acting as an OAuth resource server and the client obtaining scoped, resource-specific access tokens rather than a single all-or-nothing API key. A release candidate published July 28, 2026 hardens this further: mandatory issuer validation per RFC 9207, explicit OpenID Connect application-type declarations during client registration, and clearer refresh-token guidance, on top of a stateless core that removes the old session-handshake requirement entirely.

A plain REST API gives you whatever auth you build: API keys, OAuth, mutual TLS, anything you choose, with full control and full responsibility. MCP gives you a standard shape for that auth so a client does not need custom code per server to authenticate, at the cost of following the protocol's assumptions rather than your own.

Where this matters concretely: Flow's own MCP connector issues a per-user token and explicitly withholds delete access and confidential notes from every tool call, a permission boundary that exists at the protocol layer rather than being re-implemented by every AI client that connects. That is the pattern MCP is good at: one permission model, enforced once, usable by any compliant client.

When a plain API is still the right choice

Build a plain API, and skip MCP, when you control every caller. If your own backend calls your own service, you already know the exact shape of the request and response, and MCP's discovery and generality solve a problem you do not have. Adding an MCP server here is overhead: more surface area to secure, more code to maintain, for a benefit (discovery by unknown clients) that never applies because there are no unknown clients.

A plain API also wins when latency matters more than flexibility. Direct API calls are simpler round trips. MCP does not have to add meaningful latency by design, but a bespoke internal call with a shape you control end to end will generally be simpler to optimize than a protocol layer built for generality.

If you are a small product and nobody is asking an AI assistant to talk to your service yet, you do not need to build an MCP server speculatively. Ship the API. Add MCP when a real client, your own AI feature, or a customer's, actually needs it. Building the connector before the demand exists just gives you another surface to patch and version for a client that may never arrive.

A decision table

Situation	Better fit
You control every caller	Plain API
Multiple unknown AI clients will call your service	MCP
Latency-sensitive internal calls	Plain API
You want one permission model enforced for every client	MCP
You are validating whether AI access to your product is even wanted	Plain API first, MCP once demand is real
Your API changes often and you serve several AI integrations	MCP

Frequently asked questions

Is MCP just a wrapper around a REST API? Not quite. MCP is a specification for how a client discovers and calls a server's tools, with structured schemas that travel with the connection. It is commonly implemented on top of an existing API's logic, but the protocol adds discovery, standard schemas, and a shared auth model that a bare REST wrapper does not provide by itself.

Do I need to rewrite my API to support MCP? No. An MCP server is typically a thin layer that exposes your existing API's functionality through MCP's tool format. Your underlying API, database calls, and business logic stay as they are; you are adding a description layer, not replacing the implementation.

Does MCP handle authentication? The current MCP specification defines an authorization model built on OAuth 2.1, with servers acting as resource servers and clients requesting scoped tokens. It is a standard to implement, not something that happens automatically. You still choose what a given token is allowed to do.

Is MCP slower than calling an API directly? There is no verified, published benchmark showing a meaningful latency difference for typical tool calls, and the protocol's stateless design (as of the 2026-07-28 release candidate) removes the old session-handshake overhead. Treat any specific speed claim you read as unverified until you measure it against your own service.

Should a small product build an MCP server at all? Only once a real AI client needs to call your service, whether that is your own AI feature or a third-party assistant your customers use. Building one speculatively, before any client exists, adds maintenance and security surface for a benefit you cannot yet use.

My verdict

Keep your API. Add MCP only when a real, unknown-in-advance AI client needs to call it, and let the protocol earn its keep by replacing the hand-written glue you would otherwise maintain per client. For a single caller you already control, that glue was never the bottleneck.