Every agent vendor now says their product supports MCP, and most operators nod because asking what it is feels like admitting something. It is worth asking, because MCP is the piece of the agent story that is actually settled, and knowing what it settles tells you what is still your decision.
This is the explanation for the person who runs operations, not the person who writes the code.
An agent that does a real job has to reach several systems. To draft a quote it reads the account in the CRM, the price list wherever that lives, the stock position in the warehouse system, and the last invoices in the books. Before this year, each of those reaches was a custom integration: someone wrote code against the CRM's interface, different code against the books' interface, different code again for the warehouse, and every one of them broke in its own way when the vendor changed something.
That is how integration has always worked, and it is why most companies of 50 to 500 people have a drawer of half-working connectors. We have built a good many of them, and wrote about what distinguishes the ones that last in Zoho integration services done by engineers. An agent multiplies the problem, because an agent wants to reach everything, and a drawer of bespoke connectors cannot be audited as one thing.
The Model Context Protocol is a standard shape for the plug between an agent and a system. A system that supports it publishes a server, which is a small program that answers three questions in a fixed format.
What can you do? The server lists its tools: create a lead, read an invoice, update a stock count, search accounts by name. Each tool has a name, the inputs it takes and what it returns, described so that an agent can read the list and use the tools without anyone writing code for that pairing.
What do you hold? The server lists its resources: the records, documents or data the agent may read, in a form the agent can take in as context.
Who am I? The server runs under an identity, with that identity's permissions. The agent does not get the system's keys. It gets a plug that only turns as far as the user it runs as is allowed to turn it.
That is the whole protocol, from the operator's side. A system that has an MCP server can be reached by any agent that speaks MCP, and an agent that speaks MCP can reach any system that has a server, through the same shape of plug. The CRM, the books and the warehouse each publish one, and one agent reaches all three.
Three things, and they are all plumbing.
The integration between an agent and a system stops being custom code and becomes configuration: which server, which identity, which tools the agent may call. When the vendor changes the system, the vendor updates the server, and the agent's side does not change. That is the end of the drawer of connectors, or at least the start of the end.
The agent's reach becomes legible. Because every system describes its tools in the same format, a person can read the list of what the agent can do across the whole estate in one place, which was impossible when each connector was its own program. That matters for the permission question more than for the engineering one.
And the mixed estate stops being a reason to wait. A company that will not replace its warehouse system, and should not, can put a server in front of it and bring it into the same agent that reaches the CRM. The layer sits over what you run.
Take the quote. The agent, running as the rep, calls the CRM server's tool that reads an account and gets the account. It calls the books server's tool that lists invoices for a customer and gets the last three. It calls the warehouse server's tool that reads stock for a product list and gets the positions. It reasons, drafts the quote, and calls the CRM server's tool that creates a quote in draft. Four tools, three servers, one identity per server, and a trail of four calls with the agent's reason stored beside each.
Nothing in that sequence was custom code for this company. The servers were published by the vendors or stood up in front of the systems that lack one. What was custom was the decision that the agent may read the books but not write them, may create a quote but not send it, and runs as a rep rather than as an administrator. That is a page of configuration, and it is the page that matters.
This is the part worth remembering when a vendor says MCP as though it were an answer.
MCP does not decide what the agent may do. It describes what the system can do and under which identity. Whether the agent running as a sales rep may create an account, or only propose one, is a permission in the CRM and a boundary in the agent's instructions, and both are the company's decision. We went through one server's permission model in detail in the Zoho MCP server permission model, and the conclusion holds for every server: it respects the permissions you already set, which means the permissions you already set are now the agent's limits, and most companies have never reviewed them with an agent in mind.
MCP does not decide which system owns a record. If the CRM and the books both expose the customer, the agent can read both, and when they disagree the protocol has no opinion. The company has to say which one wins, and that is a data decision that predates agents by decades.
MCP does not keep the trail. A server can log the calls it receives; whether anyone reads them, and whether the agent's reason for each call is stored beside it, is the company's operation, not the protocol's.
And MCP does not make the agent right. It makes the agent able to reach the records. If the records are thin or disagree, the agent reaches thin, disagreeing records faster.
To the vendor: which of my systems do you reach through MCP, which through something else, and under whose identity does each plug run? A vendor who reaches your systems through their own proprietary connectors is selling the drawer back to you with a new label.
To yourself: have the permissions each server inherits been reviewed for an agent, rather than a person? Which system owns the customer, the product and the price, so the agent knows where the truth is? Who reads the trail?
Those are the agentic workflow's real design decisions. MCP settles the plug. Everything the plug carries is still yours to decide, and that is the honest reason the protocol is good news: it removes the plumbing from the argument so the argument can be about the right things.
We run the layer over mixed estates as a managed subscription: the servers, the identities, the boundaries and the trail, with one party accountable for whether the agent's actions were right. Discovery is no-risk: we map which of your systems can be reached through a standard plug today and which need one, and you pay only if you go ahead.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
