What Even Is an MCP (and Why Not Just Use APIs)?

By Domenic DiNatale

If you have been anywhere near AI tooling this year, you have heard the acronym MCP, usually spoken as if everyone already knows what it means. And underneath the hype there is a fair question that almost nobody stops to answer: we already have APIs, which are how programs have talked to each other for decades. So why do we suddenly need a new thing?

The honest answer is that MCP does not replace anything you already have. It solves a specific, boring, expensive problem that shows up the moment you put AI in front of more than one system. Once you see the problem, the reason MCP exists becomes obvious. So let's build up to it the same way the problem actually appears.

An API Is Just How Two Programs Talk

Start with the piece you already have. An API is how one program talks to another. Say you have written Program A, and it needs to read messages from Slack. Slack is Program B.

Slack exposes an endpoint, which is really just a URL, something like api.slack.com/messages. Your program sends a request to that URL, and Slack sends back a response with the data. That is the whole idea. Nothing here is new, and nothing here is wrong. APIs work, and they are not going anywhere.

The Problem Isn't One API. It's Ten.

In a real production system, your app almost never talks to just Slack. It talks to Slack for alerts, Gmail for email, Jira for tickets, Notion for documents, your own database for user records, and a handful more besides. Call it ten services.

And for every one of those ten, you write the same kind of plumbing: the authentication, the API calls, the error handling, the retries for when a call fails. Ten times. By hand. Every integration is its own little pile of code that someone on your team wrote and someone on your team now has to maintain forever.

Add a Model, and Nothing Gets Easier

Now upgrade Program A: drop a language model into it, so the application can reason about what to do rather than follow a fixed script.

Here is the detail that trips people up, and it is worth slowing down for: the model does not make the API call. The model looks at the situation and says what action it wants to take. Your application, which is ordinary software sitting outside the model, is what actually performs that action.

So has anything really changed? Not underneath. You still wrote all ten integrations by hand. The model now decides which call to make, but you still built every single call it is choosing from. The AI made the application smarter about picking. It did nothing to shrink the pile of plumbing.

Now Build a Second App

This is where the cost quietly explodes. Imagine your company builds a second AI app, say a customer support assistant. It needs to reach the same ten services all over again.

Two apps, ten services each. That is twenty separate piles of integration code your team is writing and maintaining. Add a third app next year and you are at thirty. The work grows with the apps multiplied by the services, and every one of those boxes is auth, error handling, and retries that somebody owns. This is the same structural trap I keep coming back to: AI systems have an architecture problem, and this is one of its sharpest edges.

The Idea Behind MCP

So here is the question that led to MCP: what if nobody had to hardcode these calls into every app?

The arrangement looks like this. Each of your apps gets one standard piece called an MCP client. Each service (Slack, Gmail, Jira, Notion, your database) gets a small program sitting next to it called an MCP server. The client and the server speak one common language, which means any client can talk to any server without custom glue in between.

Now count it again. Two apps means two clients. Ten services means ten servers. Two plus ten is twelve pieces to build, instead of twenty separate integrations. And the third app next year? It reuses the same ten servers. You just add one more client. The math flips from apps times services to apps plus services, and that difference only widens as you grow.

Discovery Is the Part People Get Wrong

Here is the detail most explanations skip, and it is the one that makes the whole thing click. The MCP client inside your app connects to each server and asks a simple question: what actions do you offer? That step is called discovery.

The app takes the list of available actions and shows it to the model. The model then chooses which action fits the task in front of it. You are no longer hardcoding every decision into your application. You hand the model a labeled toolbox and let it pick the right tool, from a set of tools you decided it was allowed to use. (That boundary matters, and it is the same guardrail I have argued for elsewhere: let it draft, never let it decide anything you have not explicitly handed it.)

And the Slack MCP server is still the only piece that actually talks to Slack. It calls Slack's normal API, the same one that existed all along.

So Does MCP Replace Your APIs? No.

This is the misunderstanding worth killing on sight. MCP is not a replacement for APIs. If a system already has an API, the MCP server sits in front of that API and acts as a translator: it speaks the common MCP language to your apps on one side, and it speaks the service's ordinary API on the other. Your API stays exactly where it is, doing exactly what it did.

The cleanest way to say it: MCP is a common, AI-facing layer that sits in front of the APIs you already have. The APIs are the plumbing. MCP is the standard socket you plug your AI apps into so you stop rewiring the plumbing for every new app.

The Takeaway

If you are running a single script against a single service, you do not need MCP, and anyone telling you otherwise is selling something. The value shows up with scale: more than one AI app, more than a couple of systems, and a team that is tired of maintaining the same integration code in five different places.

What MCP buys you is reuse and a standard. Build the server for a service once, and every AI app you ever write can use it. That is the entire pitch, and it is a good one, as long as you remember what it is not. It is not magic, it does not replace your APIs, and it does not decide anything for you. It just stops you from building the same twenty boxes when twelve will do.

We build the AI systems that have to talk to everything a business already runs, without turning the integration layer into a maintenance tax. If that is the problem you are staring at, let's talk. More plain-English explainers on the Intellitech blog.