MCP stands for Model Context Protocol, an open standard created by Anthropic in late 2024 so that language models can talk to external tools and data sources through a single interface. In under two years it stopped being one vendor's proposal and became the layer that practically every agent ecosystem now takes for granted.
It is worth understanding why, because the reason is not technical in the strict sense. MCP brought no new capability: everything it does was already possible by writing the integration by hand. What it brought was the elimination of work that created value for nobody and that every company was redoing on its own.
The problem it solves
Before MCP, connecting a model to a company's systems was a multiplication problem. Each model had its own way of declaring a tool, each system had its own API, and the bridge between them was code written for that specific pair. With four models and ten systems, you did not write fourteen integrations. You wrote forty, and you maintained all forty.
The real cost of that did not show up in the first project. It showed up in the second, when the team discovered that the ERP integration built for the purchasing assistant was no use to the finance agent, because it had been written glued to one model's format. And it showed up again on the first change of provider, when the decision to switch models meant rewriting the entire tool layer.
MCP turns that multiplication into addition. The system exposes its capabilities once, in an MCP server. Any model that speaks the protocol consumes them. Four models and ten systems go back to being fourteen pieces, and each one has a clear owner.
How it works, in practice
The architecture has two ends. The MCP server sits on the system side and publishes what that system knows how to do. The MCP client sits on the AI application side and consumes it. The conversation between the two is JSON-RPC, over standard input and output when the server runs on the same machine, or over HTTP when it is remote.
What a server publishes fits into three primitives, and the difference between them matters more than it looks:
- Tools are actions. Look up an order, open a ticket, post an invoice. This is the model asking for something to happen, and this is where the risk lives: a tool writes.
- Resources are read-only data. A document, a row in a table, the result of a query. They give context without giving power.
- Prompts are instruction templates the server offers ready-made, so whoever integrates does not have to guess the best way to ask for that thing.
The separation between tool and resource is the most underrated design decision in the protocol. It is what lets you give an agent broad read access and narrow write access, which is exactly the design that survives a security review. A server that exposes everything as a tool throws that advantage away.
Why it caught on, when so many standards do not
Integration standards are a category full of abandoned attempts. MCP got three things right that the earlier ones got wrong.
- A small scope. It solves transport and capability discovery, and stops there. It does not try to define how the agent thinks, how the model is served or how the data is stored. A standard that tries to standardize everything is adopted by nobody.
- Almost zero adoption cost for the publisher. Wrapping an API that already exists in an MCP server is days of work, not a quarter. Whoever has the API ready does not have to change any of it.
- Real neutrality. It was born at one vendor, but with no tie to it. An MCP server written for one model works with the others, and that is why Anthropic's competitors adopted it instead of proposing their own.
What MCP does not solve, and nobody warns you about
Here is the part that separates a demo from an operation. MCP standardizes the conversation between model and system. It does not standardize who may speak, what that person may ask for, or what gets recorded afterwards. Those three gaps are intentional, and they are exactly what a security team asks about in the first meeting.
Identity
The protocol does not carry the end user. From the system's point of view, the caller was the MCP server, with the MCP server's credential. If the agent serves the board and the intern over the same connection, the ERP sees the same identity in both cases. Propagating who actually asked is the responsibility of the layer you build on top.
Authorization
There is no concept of per-action permission in the protocol. If the invoice-issuing tool is published, it is available. The rule about who may trigger what, and under which value limit, lives outside MCP. Without that rule, the only effective protection is not publishing the tool, which reduces the agent to lookups.
Auditing
The protocol requires no record of anything. If nobody builds the trail, the answer to "why did the agent cancel that order in August" is a reconstruction by approximation. For a regulated sector that is not an operational detail: it is what decides whether the project goes to production.
The useful reading is this: MCP solved the plumbing, and solved it well. What it left open (identity, authorization, auditing and cost control) is precisely what separates an agent that impresses in a demo from an agent that internal audit approves.
How to decide where to use it
MCP is not the answer for every integration. It pays off when there is uncertainty about which capability will be used, and it weighs you down when there is none.
| Situation | Is MCP worth it? |
|---|---|
| Several agents will consume the same system | Yes. This is the canonical case: publish once, consume everywhere. |
| You want to switch models without rewriting tools | Yes. It is the main medium-term gain. |
| One agent, one fixed call, one system | No. A direct call is simpler to operate and to debug. |
| A deterministic flow, with no decision by the model | No. If there is no choice to make, you do not need a discovery protocol. |
| The system is legacy and has no API | It depends. MCP does not create the API that is missing, it only standardizes access to one. |
Three mistakes that show up every time
- Publishing the whole API as tools. A server with sixty tools does not make the agent more capable, it makes it more erratic: the model starts choosing wrong more often. Publish what the agent needs to do, not what the system knows how to do.
- Treating tools and resources as synonyms. Marking a read as a tool takes away the only cheap boundary you have between reading and writing, and it is the first thing a security review will ask you to put back.
- Leaving an unscoped credential on the server. The MCP server ends up with a broad token because that was the fastest way to get it working. That token becomes the agent's real permission ceiling, and nobody reviews it afterwards.
Where this touches Runflow
The Runflow platform speaks MCP and brings more than 150 ready connectors for ERPs, CRMs, APIs and channels, alongside the internal tools your team writes in the TypeScript SDK. MCP comes in there as one of the ways to connect, not as the whole architecture.
The three gaps described above are covered by the layer around it: access control and human approval before the agent acts where the risk demands it, sanitization of sensitive data before the information reaches the model, and an audit trail of every execution, decision and tool call. That layer is the difference between a well-implemented protocol and an agent your risk team signs off on.
