MCP stands for Model Context Protocol, and the plainest way to say what it is: a standard way to hand an AI model a set of tools and data it can use on your behalf. That is the whole thing. You will hear it called the new API, usually by someone selling you something, and that phrase is where the confusion starts. An MCP is not a new kind of API. It is a wrapper around the APIs you already have, written in a format a model can read. Calling it the new API sells the wrapper and hides the part that actually changed.
So here is the stance, and I am not going to soften it. The protocol is the boring part. The interface is the point. What an MCP really does is move the work from you clicking through a screen for thirty minutes to you asking for the thing in one plain sentence and getting it back. The plumbing underneath is the same plumbing that was already there. If you walk away thinking MCP replaced your API, you learned the wrong lesson. If you walk away thinking it changed who has to do the clicking, you learned the right one.
I did not arrive at this from a conference talk. I designed and built an MCP over a large product catalog, with the brand and pricing rules enforced inside the server, and it is now a V1 in pilot. I have also built internal MCP servers so an AI can query my own analytics, from site traffic to search data. I also founded an AI company and run its agent pipeline. I have written the tool definitions, watched the model call them, and fixed the ones it misused late at night. Everything here comes from that, not from a thread predicting the death of the API.
What an MCP actually is, under the hood
Strip away the marketing and an MCP is a small, well-defined contract between two programs. Anthropic, which introduced the protocol in November 2024, built it on a client-server model: your AI application is the host, and each tool source runs as a server the host connects to. The messages between them are plain JSON-RPC 2.0 (opens in new tab), the same request-and-response format that has been moving data between programs for years. There is nothing exotic in the pipe.
The server exposes three kinds of things: tools the model can call to do something, resources it can read for context, and prompts that template an interaction. Read the protocol’s own description of a tool and the argument writes itself. A tool is an executable function the AI can invoke to perform actions, and the spec’s own examples are file operations, database queries, and, in its exact words, API calls. The MCP does not replace the API. It stands in front of it and describes it so a model can pick it up and use it.
The best analogy is not mine, it is in the documentation. "Think of MCP like a USB-C port for AI applications," the official docs (opens in new tab) say, and that is exactly why the new API framing falls apart. USB-C did not replace the hard drive, the monitor, or the charger. It standardized the plug so any device could talk to any port without a drawer full of adapters. MCP standardizes the plug between a model and your tools. The tools, and the APIs behind them, are still the tools.
An MCP does not replace your API. It stands in front of it and describes it in a language the model can read.
Why ’the new API’ sells the wrong thing
The phrase is seductive because it sounds like a category shift, and category shifts are how people justify budgets. Look instead at what the protocol’s own creators claim for it. Anthropic describes MCP as a way to replace fragmented integrations with a single protocol (opens in new tab), a standard for connecting AI assistants to the systems where data already lives. Read that carefully. The value is not a new data source. It is a single, consistent way to reach the ones you have. That is an integration story, not a new-API story.
This matters because the two framings send you to build different things. If you believe MCP is the new API, you go rewrite your backend and treat the last decade of endpoints as legacy. That is wasted money. If you understand MCP is a wrapper, you keep your API exactly as it is and add a thin layer that tells a model what the endpoints do and when to call them. One of those plans costs a quarter. The other costs an afternoon. The framing is not academic. It decides how much you spend and how much you throw away.
The wrapper framing also explains why the standard spread so fast. A new kind of API would force everyone to rebuild. A shared wrapper only asks them to agree on a plug, which is a far easier yes. Within months, OpenAI wired MCP into its own Agents SDK, describing it plainly as an open protocol that standardizes how applications provide context to LLMs (opens in new tab). When your closest rival adopts your format, it is because the format is cheap to adopt, and it is cheap because it wraps what already exists instead of replacing it.
Where the real leverage is
Here is the part worth paying for. Before, if I wanted last week’s sales broken down by product from a store admin, I opened the dashboard, clicked into analytics, set the date range, picked the right report, filtered by product, and exported it. Ten minutes on a good day, thirty when the UI fought me or I had the wrong view saved. With those actions wired through an MCP, I ask for exactly that in one sentence, the model calls the same endpoints the dashboard calls, in the right order, and hands me the answer. The data did not change. The API did not change. The thirty minutes of hunting through someone else’s menu structure went away.
The shift is not a new pipe. You stop hunting through a UI for thirty minutes and get what you need in one plain sentence.
That is the leverage, and it is an interface leverage, not a plumbing one. Every piece of software you use buries its real capability under a UI designed for the average case, which is never your case. You learn where the buttons are, you memorize the click path, you rebuild that muscle memory for every new tool. An MCP lets a model hold the click path for you and drive it from a sentence. The work you were doing, translating your intent into a specific sequence of clicks, is the work that disappears. That is a genuinely new thing, and notice it has nothing to do with the API being new.
If you are deciding whether to build one
Build an MCP when you have a real API or a real set of actions, and a person who keeps translating plain requests into tedious sequences against it. That is the sweet spot: a support team pulling the same five reports, an ops person running the same runbook, an engineer who lives in three dashboards. Wrap the actions they already take, write plain tool descriptions so the model knows when to reach for each one, and you have handed them a sentence-shaped interface over work that used to cost them clicks. You are not building new capability. You are removing the translation tax on capability you already shipped.
When an MCP is not the answer
It is the wrong tool more often than the hype admits, and I would rather you skip it than ship one that sits unused. If there is no natural-language step in the loop, an MCP adds a layer and buys you nothing. A cron job that syncs two systems every night should stay a cron job. A service calling another service a million times a day wants a direct API call, not a model in the middle deciding whether to make it. The moment reliability and volume matter more than flexible phrasing, the plain API wins, and it is not close.
It is also the wrong tool when your API is a mess. An MCP inherits every ambiguity underneath it. If your endpoints are inconsistent, badly named, or do three things at once, wrapping them in tool descriptions just teaches the model to be confused in a new format. Fix the API first, or the wrapper amplifies the problem. And if the task is truly one clean action a user does once, a button beats a sentence. Do not make someone describe in prose what a single click already does well.
None of this is a knock on MCP. I built one on purpose and I would do it again. It is a knock on the sentence "MCP is the new API," which points you at the plumbing and away from the thing that changed. The protocol is a tidy wrapper around the APIs you already have. The leverage is that a model can now drive those APIs from one plain sentence, so the thirty minutes you used to spend translating intent into clicks goes back in your day. If you want the way I decide whether an AI idea is even worth building in the first place, I wrote that in how I evaluate an AI product idea. The short version for MCP is this. Do not buy the new API. Buy the new interface, and keep the API you already have.