MCP vs API: Pick by Who Chooses the Call

MCP is an API with a different customer. The customer is a model.

That's the whole answer to MCP vs API, and it's why the argument people keep having about it goes nowhere.

An API is how one program calls another. MCP is a standard way for a server to describe what it can do, so an AI model can pick a call while it works, with no developer wiring that call in first. Underneath nearly every MCP server, an ordinary API is still doing the job.

So both sides of the fight are wrong. One side says MCP replaces APIs, and it doesn't. The other says MCP is an API with extra steps, which is half right, and the half it misses is the part that matters.

The mistakes on both sides are expensive. Some teams wrap a nightly job in a protocol built for models. Other teams hand-wire ten integrations that their own users could have added themselves.

Use the API when you already know the call. Use MCP when the model, or the person driving it, decides the call mid-task.

A direct API call is ordering "the usual" from a cook who knows you

Think of a restaurant.

The kitchen does the work. It makes the same dishes the same way whether or not anyone prints a menu.

A direct API call is walking in as a regular and saying "the usual." The cook knows you, knows the dish and knows what you mean. It only works because someone, once, taught the cook what "the usual" is.

That teaching is the integration. A developer reads the docs, picks the endpoint, writes the call, sets up the login and decides when it fires. Everything about the call is settled before the program runs a single line.

Take a small request: summarize yesterday's messages from a Slack channel. Slack's conversations.history method doesn't take a channel name. It takes a channel ID, plus oldest and latest Unix timestamps for the window, and the messages come back with user IDs instead of names. So the code finds the channel, converts "yesterday" into timestamps, pulls the history and swaps the IDs for names. A developer wrote that sequence once, and it runs the same way every time.

That's the strength of an API: nothing happens that you didn't write down.

It's also the limit. The program can only do what a developer already told it to do.

And none of this needs a model. A nightly job that posts yesterday's revenue to a channel is an API integration, and it should stay one. If your code already knows which call to make and when, adding AI gives you another place for the job to fail and nothing else.

MCP is the printed menu, handed to someone who has never eaten there

MCP doesn't replace the kitchen. It tells a stranger what the kitchen can make, what each dish needs from them and what they'll get back.

The Model Context Protocol is an open standard that Anthropic released in November 2024, created by David Soria Parra and Justin Spahr-Summers. Anthropic's launch announcement frames it as one protocol in place of a separate connector for every data source. The plain-English explainer on the Model Context Protocol goes further into the idea.

The mechanics are small. A server answers two kinds of request: what can you do, and do this. The first is tools/list, which returns each tool's name, a description and a JSON schema for its inputs. The second is tools/call, which names a tool and passes its arguments. This is the spec's own example, with the required metadata trimmed:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" }
  }
}

Now the part that trips people up. The model never sends that request.

The model reads the menu and writes out what it wants. The application it runs inside, called the host, hands that to an MCP client. The client sends it to the server. The server calls the underlying API. The model is the guest at the table, and the guest never walks into the kitchen.

That's why the spec treats tools as something to supervise. It says there should always be "a human in the loop with the ability to deny tool invocations," and it tells apps to show which tools the model can use and to confirm operations with the user.

Errors change shape too. A failed API call returns a status code written for a developer. A failed MCP tool call can come back flagged isError: true with a message the model can read and act on. The spec's own example is "Invalid departure date: must be in the future." The model fixes the date and tries again, with no developer in the loop.

Same kitchen, different front of house.

MCP vs API comes down to who chooses the call, and when

Every difference between the two traces back to one question: who decides which call to make, and when? These are the differences that matter in practice.

The fourth row changes what MCP is for. With an API, adding Notion to an app means a developer writes the Notion integration and ships it. With MCP, a user in an app that supports it adds the Notion server's URL and the model has Notion's tools the same afternoon. The person who adds the capability is no longer the person who built the app.

The second thing to count is integrations. Say you run five AI apps and each needs ten services. Built by hand, that's fifty integrations. With a shared protocol, it's five clients and ten servers, so fifteen pieces. Add a sixth app and you build one more client, because the ten servers already exist. That's the reason MCP exists: one shared protocol is cheaper than fifty private ones.

Then comes the objection. "Can't I just hand the model the API docs?" You can, and for one app it works. The model reads the docs and writes the calls. But something still has to hold the credentials, make the request, retry the failure and give the result back to the model, and that something is code you now own, for every app that needs it.

An OpenAPI description also covers web APIs only. A local file system, a terminal or a database has no web API to describe, and an MCP server can sit in front of any of them. For one app and a handful of known calls, skip the protocol. Past that, you're rebuilding MCP in private.

MCP sits on top of the API, and Stripe shows how

Stripe's hosted server at mcp.stripe.com is the clearest example, because the API underneath is thoroughly documented and you can compare the two side by side.

According to Stripe's MCP docs, the server gives an agent tools to search Stripe's API methods, get a method's parameters, read with any GET method and write with any POST, PATCH, PUT or DELETE method. It adds account info and documentation search. Stripe says this puts much of the API behind MCP without loading the context window with one tool per endpoint.

So the MCP server isn't a different system. It's four generic tools in front of the REST API you could have called yourself.

But the door isn't the same as the API, and three differences show up right away:

1. Stripe requires human confirmation before certain write actions, such as refunds and outbound payments. The agent gives you a URL, you review the request and approve it, and then you tell the agent to retry. If you don't approve within 24 hours, the request expires. A direct API call with a key that can issue refunds will issue them.
2. Stripe offers two ways to sign in, one for each kind of caller. OAuth is for a client acting on behalf of a Stripe user. API keys are for an AI application that needs independent, persistent access. The second path is changing: starting October 31, 2026, Stripe MCP stops accepting full-access secret keys and restricted keys without the Agent tag, and those requests get a 401. The replacement is a purpose-built agent key.
3. Platform work follows its own rules. A Connect platform can use MCP on behalf of its connected accounts, but not with OAuth. It authenticates with an API key and passes the Stripe-Account header.

The layer added an approval step and a narrower kind of key, and left the work to the API. A layer can be stricter than the API under it, which is the right way round for something that can be talked into things.

Stripe's docs recommend enabling human confirmation and taking care when you combine its server with others, to avoid prompt injection attacks. The server is also in public preview, so check the docs before you build on any detail here.

MCP is no longer stateful, so redraw the diagram

You may carry a picture in your head: an API is a fresh phone call every time, and MCP is a line left open all day while the server remembers who you are.

Redraw it.

The current revision of the spec, dated July 28, 2026, removed protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport. It also removed the initialize handshake. Every request now carries its protocol version and the client's capabilities in its own metadata. The spec's overview sums up the base protocol as stateless, self-contained requests with per-request capability negotiation.

The changelog and the tools page spell out what that changes in practice:

1. tools/list can't vary by connection anymore. It can vary by the authorization on the request, such as the scopes a caller was granted, and by nothing else.
2. Every HTTP request carries Mcp-Method and Mcp-Name headers, so a proxy or firewall can route a tools/call without opening the body.
3. Results from tools/list carry ttlMs and cacheScope fields, so clients can cache the menu instead of re-reading it.

A request no longer has to reach the same server instance as the one before it. State, when a tool needs it, lives in the server's data, and the model carries the key.

That key is a handle. A server that runs a shopping cart exposes a create_basket tool that returns an ID like bsk_a1b2c3, and the model passes that ID into every later call, such as add_item. The spec adds that a handle is a name, not a capability, so the server should check the caller's authorization against it on every call.

The "context" in Model Context Protocol means the model's context: the information put in front of the model. It never meant a server that remembers you.

Plenty of servers still speak earlier revisions, and those keep sessions. A server on the new revision answers server/discover with the protocol versions it supports, so that's the first thing to check. For anything new, the gap between MCP and a plain API on state has mostly closed. What's left is the difference that was always the point: discovery, and who chooses the call.

Use the API when you already know the call

Run the work through four questions:

1. Who chooses the action? If your code decides, as in "when an invoice is paid, post to #sales," it's an API call. A model adds nothing to a decision that's already made.
2. Is the list of tools fixed? If you know all ten calls on the day you ship, you don't need a menu. You need ten functions.
3. How often does it run? A model reading a menu and picking a tool costs tokens and time that a direct call doesn't. For ten thousand identical calls, don't pay a model to choose ten thousand times.
4. Does anything have to arrive without being asked? A webhook is the service calling you with an event. An MCP tool call is a model asking the service for something. Work that reacts to events, like reconciling payments as they land, wants the API's delivery model.

The first question settles most cases. Write the call as a function signature, such as post_revenue(channel, date). If you can write the signature and fill in the arguments today, you don't need a model choosing it.

Speed follows from the same logic. An MCP call adds hops: the model picks, the client sends, the server calls the API. For a single known call, the direct API is the faster path, and nobody has to wonder which layer failed.

Control of the contract matters too. A hosted server's tool list belongs to the server's owner, and the spec says that list can change over time, which is why it lets servers announce changes. With a direct API, you choose when to change your code.

Take the nightly revenue post again. Two API calls on a schedule, no model. Put MCP in the middle and you've added a client, a server and a model's judgment to a task that never needed judgment. When it breaks, you have one more place to look.

The usual failure here is adding MCP because everyone is talking about it. You end up with a model choosing between one tool.

Use MCP when someone besides the developer decides what's connected

MCP earns its overhead in four situations:

1. A user adds tools while the app is running. The user pastes a server's URL and the model gets new abilities. Hardcoded API calls can't do that, because every addition needs a developer and a deploy.
2. Several AI apps need the same service. This is the fifty-versus-fifteen math from earlier. Build the server once and every compatible app can use it, which is what Anthropic pitched at launch: stop maintaining a separate connector for each data source.
3. The model has to choose among many tools mid-task. A request that touches your drive, your chat and your CRM can't be scripted in advance, because the path depends on what the first query returns. The model needs a menu, and MCP is a shared format for menus.
4. You want policy at the tool layer. Stripe's approval step for refunds lives in the MCP layer, and you can put the same kind of gate in front of any tool a model touches.

Carry the third case through. Say you want an assistant that preps you for a client call: pull the last notes document, check the calendar for the next open slot, draft the follow-up email. With a script, you fix that order forever. Real days vary. One client has no notes yet, another needs the CRM first. With a menu, the model skips the step that doesn't apply and reaches for the one that does. Automating social media with MCP is the same pattern, where one workspace reaches several social tools and the model decides which to use at each step.

If you run a service and want AI apps to use it, there's a fifth case. Publish one MCP server instead of waiting for each AI app's integration team to get around to you.

Most real systems use both. The refund agent a finance lead talks to runs on MCP, because a person is present to approve each refund. The job that fires when a payment lands stays on the API. Same service, two doors, and the caller picks the door.

MCP costs context and trust

The costs are real, and they land in two places: the model's context window and your trust boundary.

Start with context. Anthropic's engineering team points out that most MCP clients load every tool definition into the model's context up front, and that agents connected to thousands of tools can process hundreds of thousands of tokens before they read a single request. Results cost too. Moving a transcript from Google Drive into Salesforce through the model means the full text passes through twice, which for a two-hour sales call could add about 50,000 tokens.

Their fix is to present MCP servers as code that the agent writes and runs in a sandbox, loading only the tools it needs. In their example that took a task from 150,000 tokens to 2,000, a 98.7% saving. They also name the catch: agent-written code needs sandboxing, resource limits and monitoring, which direct tool calls don't.

Then trust. The spec says tools represent arbitrary code execution and "must be treated with appropriate caution," and that descriptions of tool behavior, such as annotations, should be considered untrusted unless they come from a trusted server. Read that plainly: the text that tells your model what a tool does is written by whoever runs the server.

An instruction hidden in a document, a message or a web page can also try to steer a model that has tools, which is the prompt injection risk Stripe's docs warn about. Two servers that each expose a tool called search can collide as well, and the spec tells clients that combine servers to disambiguate.

Before you connect a server, run this checklist:

1. Read its tool list first, and know which tools write, send or delete.
2. Start read-only when the server offers it.
3. Keep a human approval on anything that moves money, sends a message or deletes data.
4. Connect only what the task needs. Fewer tools means less context spent and fewer places for a bad instruction to hide.
5. Note which revision of the spec the server speaks.

Our breakdown of which MCP servers are worth connecting covers the servers that earn the effort.

Try it in Magai: one server, three models, one thread

The quickest way to feel the difference is to separate the tool from the model, and Magai's MCP connector does that. You add an MCP server by its URL, and its tools work in the chat and in your agents, on GPT, Claude, Gemini and dozens more models, with nothing to install. The full list of models in Magai shows what you can switch between.

Here's a test that takes about ten minutes:

1. Pick a server that only reads, such as a docs server or a calendar. A read-only server can't change anything while you learn how the menu behaves.
2. Add its URL in the MCP connector.
3. Ask for something that needs two tools, such as "find the two most recent onboarding docs and tell me what changed between them."
4. Switch models inside the same thread by typing /Claude, then /GPT, then /Gemini, and ask again. Magai keeps the conversation's context when you switch, so each model starts with everything the thread already knows.
5. Watch which tools each model picks, whether it asks before anything that writes, and how it handles an error.
6. Then do the same job with one of Magai's 150+ built-in integrations, such as Gmail or Google Drive, and compare what each one took to set up.

You're testing the point of the protocol: the tool belongs to the connection, not the model. If the menu stays put when the model changes, MCP is doing its job.

The built-in integrations are the ready-made side of the same idea. Connect an app once and every model can use it. MCP covers the long tail, the servers a vendor or your own team runs.

The same menu travels into agents. Any agent in Magai can connect to external MCP servers, so a job you tested by hand can become a reusable assistant, which our guide to building an AI agent without writing code walks through. For the model switching itself, see switching between AI models in one workflow.

If you don't have a workspace yet, start at app.magai.co. The Artificial Intelligence category has more on how the models and the plumbing around them differ.

Keep the kitchen, add the menu when guests show up

Back to the restaurant.

A regular doesn't need a menu. A regular needs the cook to remember "the usual," and a direct API call is exactly that: settled in advance, fast and exact. Keep it for every job where you already know the order.

A menu is for the table that has never eaten here. A new app, a new user, a model that has to choose between a dozen dishes it has never heard of. MCP is how the kitchen explains itself to them, and the kitchen behind it is still the same API.

So ask one question about each job you're about to build. Who chooses the call?

If it's you, write the API call. If it's a model, or a person driving one, hand it a menu.

Know your customer, then pick.