If you’ve talked to anyone in tech about AI agents in the past year, you’ve probably heard the acronym MCP. It shows up in product announcements, vendor proposals and job postings. Plenty of people talk about it as if it were the piece that solves integration once and for all.
It solves an important part, and it’s worth knowing which one. Here we explain what the Model Context Protocol is, why it caught on so fast and what questions you still need to ask before letting an agent work in your systems.
What MCP is, in one sentence
MCP is an open protocol that defines how an AI agent discovers and uses tools and data from other systems. Anthropic published it in late 2024 and, over the course of 2025, it was adopted by the major model providers and developer tool makers.
The most common comparison is with USB. Before it, every device had its own cable. Afterwards, one plug worked for almost everything. Agents had the same problem: to connect a model to the CRM, the ERP or a spreadsheet, someone wrote an integration specific to that model and that system. Change the model, redo it. Add a new system, write it again.
With MCP, a system is exposed once, in a standard format, and any compatible agent can use it.
How it works in practice
There are three roles. The names are worth knowing because they come up in any technical conversation:
- Host: the application where the agent runs. It could be a desktop assistant, a coding tool or the agent your company built.
- Client: the part of the host that talks to each MCP server, one connection per server.
- Server: the program that sits in front of a system (the CRM, the database, the drive) and tells the agent what it can do there.
The server offers essentially three things. Tools, which are actions (create an order, look up a customer, send an email). Resources, which are data to read (a document, a record, a file). And prompts, which are ready-made instruction templates for common tasks.
When the agent starts working, it asks the server what’s available. The server replies with a list of tools, each with a name, a description and the fields it expects. The model reads that list and decides, during the task, which tool to call and with what data. The server runs it and returns the result.
The server can run on the same machine as the agent or at an address on the internet. In the second case, the spec includes an authentication flow based on OAuth, the same standard used when you sign in to an app with your Google account.
Why it became the standard so quickly
A good protocol isn’t enough to become a standard. MCP caught on thanks to a combination of factors:
- It solved a real, expensive pain. People building agents spent a big chunk of their time writing and maintaining connectors. None of it set any product apart.
- It launched open and simple. The spec is public, there are libraries in several languages and a basic server takes a few hours to build.
- Competitors adopted it. When vendors fighting for the same market accept the same plug, software companies get a reason to publish their own servers.
- Network effects. Every new server published makes every compatible agent a bit more useful, which attracts more people to publish.
For people on the operations side, the practical consequence is good. Switching models became less painful, because the connections still work. And many of the systems you already use probably have, or will have, an official MCP server.
MCP standardizes the plug. Who can use the plug, for what and with what record is still your call.
What MCP doesn’t solve: identity
The protocol defines how the agent connects to the server. On its own, it doesn’t answer on whose behalf the agent is acting.
Think of an agent that handles requests from several salespeople. When it queries the CRM, whose book of business does it see? The salesperson who asked, or everyone’s, because it was connected with a service account that sees everything? That’s the most common shortcut: one broad-access credential shared by every task. It works in the demo and becomes a problem at the first audit.
Before connecting, ask:
- Does the agent use the identity of the person who made the request, or its own account?
- If it uses its own account, does that account have only the access it needs, or did it inherit an administrator’s access?
- Can you tell, by looking at the target system, that the action was taken by an agent and at whose request?
What MCP doesn’t solve: authorization
Being authenticated is different from being authorized to do anything. An MCP server might expose ten tools, and your agent maybe should only use two. It might expose a refund tool with no limit on the amount. The protocol describes the tools, but the business rule (up to how much, in what situation, approved by whom) has to live somewhere.
There’s also a risk specific to this model. The agent decides what to do based on text: the tool descriptions, the content of documents, the customer’s message. If someone hides an instruction in an email or a CRM field, the agent may treat it as an order. This is called prompt injection, and no connection protocol prevents it on its own.
What tends to work:
- Give each agent only the tools it needs, and nothing more.
- Separate read tools from write tools, and treat the write tools with more care.
- Put limits outside the model: maximum amount, number per hour, allowed hours.
- Require human approval for actions involving money, customers or anything irreversible.
- Use only servers from known sources and review what changed when they’re updated.
What MCP doesn’t solve: auditing
When something goes wrong, someone will ask what happened. If the answer depends on reading the model’s conversation and guessing, you don’t have an audit trail.
A useful log answers, for every action: which agent acted, at whose request, with which tool, with what data, what the result was and whether there was human approval. MCP carries the calls, but keeping that history organized, searchable and protected is the job of whoever sets up the operation.
This matters even more when personal data is involved. Privacy laws like GDPR expect you to be able to explain how data was processed, and an agent that calls tools without leaving a trail makes that explanation impossible.
How to think about MCP at your company
Treat MCP the way you treat any integration standard: good news that lowers cost and lock-in, not a security guarantee. When evaluating a project or a vendor, four questions separate what’s production-ready from what’s a demo:
- Which MCP servers will be used, who maintains each one and where do they come from?
- With which identity and which permissions does the agent access each system?
- Where do the limit and human approval rules live?
- Where is every action logged, who can look it up and how long is it kept?
If the answers are clear, MCP will do its job very well. If they’re vague, the problem isn’t the protocol, it’s what’s missing around it.
MCP took the repetitive work of connecting systems off the table. What’s left is the work that always mattered: deciding who can do what, and being able to prove what was done.