MCP vs API: what actually changes

An API tells a program what it may call. MCP tells an agent what exists and lets it decide. The endpoints underneath are the same ones; what moves is the choice of which to call — out of your code and into a model's reasoning at runtime. That is the whole change, and the rest follows from it: discovery instead of documentation, sessions instead of stateless calls, and a caller you cannot fully predict.

Whether that is worth anything to you depends on whether an agent is a caller you care about. If it is not, nothing here changes for you, and the rest of this page is a description of work you do not need to do.

Most comparisons stop at "MCP is a protocol for AI", which is true and decides nothing. These are the differences that reach your design review.

• Discovery: a REST client is written against documentation someone read once, at build time. An MCP client asks the server what it offers at connect time, so a tool you add on Tuesday is callable on Tuesday, with no client release.
• Who picks the call: your code chooses the endpoint and the arguments. Under MCP a model chooses both, working from the descriptions you wrote — which makes those descriptions load-bearing in a way an OpenAPI summary never was.
• Shape of the contract: REST is resources and verbs, sized for a programmer holding the whole flow in their head. MCP is tools, sized for a caller with no memory of your domain and a few thousand tokens in which to learn it.
• State: a REST call is complete on its own. An MCP session is a connection with a lifetime, so the tool list, the credentials and cancellation all sit at the session level instead of being re-established per request.
• Errors: a 422 tells your code to stop. An MCP error is read by a model that will usually try again differently, so your error strings are prompts whether you intended them to be or not.
• Authorization: REST auth answers whether this client may call this endpoint. MCP auth answers that and also which end user the agent is acting for — the question OAuth exists for, arriving in front of internal APIs that never had to ask it.
• Granularity: an API is rewarded for being complete. An MCP server is rewarded for being small, because every extra tool costs context and raises the odds the model picks the wrong one. Good MCP servers usually expose fewer operations than the API beneath them.

MCP is additive. It sits on the same endpoints your API already exposes, which is why "put everything behind MCP" is the wrong shape of answer. Three cases where routing through it makes things worse:

• The nightly reconciliation job that pulls yesterday's orders into your warehouse. It runs on a schedule, the shape never varies, and nothing about it wants a language model's opinion. Putting it behind MCP adds a token bill and a nondeterminism budget to a cron job that was already correct.
• A checkout or payment write path, where the caller must be exactly your own frontend and argument validation is the security boundary. "The model picks the right account id almost every time" is not a sentence worth defending in a post-incident review.
• A high-volume, low-latency read your own product depends on, such as the autocomplete behind a search box. Session setup and tool negotiation buy nothing when the caller already knows exactly what it wants, and your p99 gets worse for the privilege.

Every dataset is useful to an agent, so asking whether one would want yours settles nothing. What matters is whether the caller has to work anything out. Where the set of possible calls is known in advance and small, code should pick, and REST is not the legacy option but the correct one. Where the request is one nobody anticipated, something still has to decide what to do with it, and MCP is the interface for putting that decision in the model rather than in a maintained integration.

Phrased for a roadmap: MCP is a distribution decision before it is an architectural one. Exposing a server puts your product inside a client your users already have open. That is worth a great deal or nothing at all, entirely depending on who your users are, and it is a different question from whether your API is any good.

Standing a server up over an API you already have is roughly a week, and the least interesting week of it. The costs that surprise teams are downstream.

Tool descriptions become product copy. A model reads them on every call, and a badly worded one is indistinguishable from a bug — the tool works, the model just never picks it, or picks it for the wrong request. They need revising the way UI strings get revised rather than the way OpenAPI summaries do, which is to say never.

Then there is the caller whose source you cannot read. You will not have the agent's prompt or its version, and it will call your tools in orders you did not design. That is an observability requirement before it is an engineering one: you need to see what was called, with what arguments, and what the model did with the answer. Without it, the first evidence of a bad tool description is a customer complaint.

One part of this is not our business at all: we do not host arbitrary third-party MCP servers.

We work the other direction. If you already run MCP servers, a ConnectAI agent consumes them — attached per agent rather than granted account-wide, over remote MCP on HTTPS, with tools discovered live from your server before the connection is saved, and four authentication modes: static headers, OAuth2 client credentials, a locally minted JWT, and the full authorization-code exchange with refresh. Our own MCP surface is managed for you, and the agent itself is buildable and operable through it without opening a dashboard.

The trade is the one on the MCP hub: you keep your stack, your servers and your client; we bring the customer-facing agent and the operational surface around it.