Every tool suddenly wants to be “MCP-compatible”
Since late 2024 one acronym shows up in nearly every AI announcement: MCP, the Model Context Protocol. Tools advertise that they are “MCP-compatible”, platforms open an “MCP marketplace” and the word comes up at every conference. As with AI agents, the hype hides an idea that is actually easy to follow.
The reason is a practical problem. An AI agent only becomes useful once it can reach your real systems: your CRM, your calendar, your database, your documents. Until recently, connecting those took fresh work for every combination. MCP is the answer to that, and it was deliberately made an open standard rather than one vendor’s trick.
The problem: a separate integration for every tool
Say you have three AI applications (a chat assistant, a code assistant, a support bot) and you want all three to talk to three systems (Slack, your database, Google Drive). Without a standard you build each connection separately. Three applications times three systems is nine integrations, each with its own format, error handling and maintenance. Add a fourth tool and the count climbs fast.
Without a standard you write a separate integration for every AI tool and every system. That scales by multiplication, and that is exactly where it grinds to a halt in practice.
It is the pattern every developer knows from before the USB standard: every device its own cable and its own driver. It works, until you have ten of them. Building one connection is simple engineering. The bottleneck is the sheer count: how many connections you have to build and then keep maintaining.
MCP is a universal plug
MCP solves this with a single agreement on how an AI model and a tool talk to each other. Build your tool once as an MCP server and every AI application that speaks MCP can work with it straight away. The other way round, an AI application only has to support one protocol to reach the whole ecosystem.
MCP is to AI tools what USB-C became to peripherals: one plug that everything fits into, so you no longer have to invent a separate cable for every device.
That changes the sum from the previous paragraph. Three applications and three systems then take only six parts that all speak the same protocol: each application speaks MCP, each system offers an MCP server. Adding becomes addition instead of multiplication. The protocol is open and was introduced by Anthropic in late 2024, after which large players picked it up quickly.
Client and server: how MCP works technically
MCP follows a familiar model: a client that asks and a server that delivers. The AI application runs an MCP client, every system you want to expose runs an MCP server. Between them, messages travel in a fixed format.
The host with the MCP client
The AI application (think of a chat assistant or an agent) contains an MCP client. It connects to one or more servers and keeps track of the capabilities they offer.
The MCP server
A thin layer around a system or data source: your database, Slack, a calendar, your own API. The server translates the MCP protocol into what that system understands, and back again.
Tools, resources and prompts
A server offers three kinds of things: tools (actions the model can perform), resources (data the model can read) and prompts (ready-made instructions). The model discovers for itself what is available.
The transport in between
Messages travel over a fixed channel, locally between processes or across the network. The format is fixed, so client and server need to know nothing about each other's internals.
The important detail: the model does not need to know the tools in advance. On connecting, the client asks the server which tools and data exist, and hands that list to the model. Add a server and the agent’s arsenal grows without you having to change the agent itself.
MCP or function calling: what is the difference?
These two are often mixed up, while they are different layers that lean on each other. Function calling is the model’s ability to decide that it needs a tool and to fill in the parameters. MCP is the agreement on how that tool is described, found and reached.
Function calling: the model decides
The LLM sees which tools exist, picks one and fills in the parameters. This lives in the model and determines the choice: which tool, with which values.
MCP: the tool becomes reachable
The protocol handles how that tool announces itself, which actions it offers and how the result comes back. This sits between the application and the system and determines the connection.
They work together. Function calling is the decision, MCP is the plug along which that decision reaches a real system. You can use function calling with hand-built integrations, and then every tool does it its own way. MCP turns those integrations into one reusable standard, so the same tool works in every MCP application.
Where MCP fits in an agentic workflow
MCP rarely stands on its own. It is the connecting layer beneath the larger AI landscape we wrote about earlier. In an agentic workflow an agent runs through several steps and calls tools along the way. MCP is exactly how it reaches those tools: every step that touches the outside world runs over an MCP server.
The other building blocks slot in here too. A RAG system that searches your own documents can be offered as an MCP server, so any agent can ask “what do our sources say about this?” And the AI harness around it decides which servers an agent may use and under what conditions. MCP handles the connection, the harness handles the boundaries.
Where it goes wrong: one protocol is not a free pass
With MCP, connecting a tool becomes almost trivial, and that is where the catch sits. Every MCP server is a door to a real system: your database, your mailbox, your files. A protocol that makes connecting easy also makes connecting wrongly easy. The technique is simple, guarding it is the real work.
Permissions that are too broad
A server that offers 'read and write everything' is quick to build, but hands an agent far more power than a task needs. The starting point should be minimal: only what this task requires.
Prompt injection via tool results
An agent reads data from a tool and acts on it. If that data hides an instruction, an attacker can steer its behaviour. What a tool returns is not automatically to be trusted.
Unknown third-party servers
A server from a marketplace is one click away, but it runs code and sees your data. Without knowing who made it and what it does, you let a stranger into your systems.
No view of what happens
If you do not record which agent called which tool with which data, you cannot reconstruct an incident afterwards. Logging and approval belong in the setup, not after it.
MCP takes the effort out of connecting. As a result the difficulty shifts to the question that always mattered: what exactly may this agent touch, and how do you know afterwards what it did?
This is the work we do for clients. Building an MCP server is an afternoon. A setup where agents only hold the permissions they need, tool results are distrusted and every action is traceable, that is the engineering that separates a demo from something you dare to run your business on.
When MCP is worth it
MCP pays off the moment you want to connect AI to several tools or data sources and reuse those connections. For a single, fixed line it is often more than you need.
Choose MCP
You connect agents to multiple systems, want to share tools between applications, or ride along on the growing ecosystem of existing servers. One standard saves you a pile of separate integrations.
MCP is overkill
You have one application calling one API, fixed and predictable. Then a direct connection is simpler than a protocol with a client, a server and a transport around it.
Start as simply as possible here too. A clean connection with tight permissions takes you further than the longest list of connected servers. Every server you add is also one you have to trust, restrict and keep an eye on.
Conclusion: one plug, and then the control
MCP becomes clear once you see it as a universal plug for AI. Instead of building a separate integration for every combination of application and tool, everything speaks the same protocol. Adding a tool becomes addition, and the ecosystem grows along with you.
One protocol for every tool
Build a tool once as an MCP server and every AI application that speaks MCP can work with it. Connecting becomes addition instead of multiplication.
Function calling decides, MCP connects
The model picks which tool it needs, MCP handles how that tool is found and reached. Two layers that lean on each other.
Control is what it comes down to
Connecting has become easy, so the win sits in tight permissions, distrusted tool results and traceable actions. That is where a serious setup stands or falls.
Start small, give each agent only the tools it needs and record what it does. Then MCP is exactly what it promises: the easy way to let AI work with your real systems, without losing sight of it.
What is MCP (Model Context Protocol)?
Who developed MCP and is it an open standard?
What is the difference between MCP and function calling?
What is an MCP server?
Is MCP secure and what are the risks?
Do I need MCP?
Want AI to talk to your own systems?
We connect AI agents to your real tools and data through MCP, with tight permissions, distrusted tool results and traceable actions as the starting point. From first setup to ongoing management, so you capture the win without losing sight of it.
