MCP explained to CIOs: the standard that plugs AI into your IT estate

MCP (Model Context Protocol) is an open standard that describes how an AI agent connects to tools and data sources: reading a file, querying an ERP, preparing a send. Published by Anthropic at the end of 2024, adopted across the industry in 2025 and then placed under neutral governance, it has become the common socket between models and the IT estate. For a CIO, it changes two very concrete things: the cost of integration, and vendor dependence. Here is how, and the questions to ask before plugging anything in.

The problem it solves: N x M integration

Before a standard, every AI assistant had to be integrated with every tool: N tools multiplied by M assistants, each pair requiring its own custom development, its maintenance, its error surface. That is the economics that long condemned AI integration projects to a narrow scope.

MCP replaces that matrix with a socket: one connector per tool (an "MCP server"), usable by any agent that speaks the protocol. The ERP exposes what it can do once; all your agents, present and future, know how to use it. One connector per tool, not one integration per tool-assistant pair.

How it works, without jargon

Three roles. The MCP server is a small service that describes what a tool can do, as named, typed capabilities: "read this month's invoices", "search the document base", "prepare an email". The agent discovers those capabilities and calls them when its task requires it. The protocol is the common language between the two, published and documented publicly.

Two properties of this mechanism matter directly to a CIO. First, capabilities are enumerable: you can list, exactly, what an agent can do on each tool. That is an audit surface, where a custom integration is a box to pry open. Second, every call is individually loggable: which agent, which capability, which parameters, which result. The trace is as granular as the action, not the session.

What it changes for reversibility

The connector belongs to the standard, not to the platform. If you change your AI layer, the MCP servers for your tools remain valid; if you change a tool, your agents learn the new connector without being rewritten. Integration stops being what binds you to a vendor, and that is a notable inversion: in classic SaaS, integration is precisely where the dependence gets built.

It is also a selection criterion. An AI vendor offering you proprietary integrations where a standard exists is offering, implicitly, to rebuild the N x M matrix in its own favour.

The six governance questions to ask

1. Where does the MCP server run? On your infrastructure, or at a third party? A remote server sees your data and your requests pass through: its location and jurisdiction matter as much as your host's.
2. Who holds the access tokens? An MCP server authenticates against your tools. Dedicated service accounts, least privilege, revocation available: the classic rules, applied without exception. Never an employee's personal credentials.
3. What scope per agent? Read-only is a healthy default. A reconciliation agent does not need to write to the ERP; the one preparing emails does not need to read the accounts.
4. Who wrote the server? A community MCP server is code you execute with your access. Provenance review is the same as for any software dependency, with higher stakes: that code holds your keys.
5. Is every call logged? The protocol makes the trace possible; your platform is what makes it mandatory, queryable and exportable. An MCP integration without a log loses most of the governance benefit.
6. Does writing go through validation? Any outbound action (send, edit, publish) deserves human validation, whatever the connector. The standard does not impose that safeguard: your architecture must.

What MCP does not solve

MCP is a socket, not a policy. It does not decide where your data resides, does not choose your models, sets no scope, and does not by itself protect against an agent being hijacked: a booby-trapped document can try to make a tool-equipped agent perform unintended actions, and it is precisely the restricted scope, the human validation and the log that contain that risk. An integration standard replaces neither the architecture nor the security policy. It makes both simpler to build, which is already a lot.

The socket, root's side

root Workspace uses MCP natively: connectors run on your instance, not through a third-party relay; every agent has a declared scope; every call feeds the audit log; writing waits for validation. The tools covered are detailed on the connectors page, and what a CIO can demand from the whole layer is on the page for CIOs and CISOs.

Frequently asked questions

Is MCP tied to a model vendor?

No. The specification is public, governance was handed to a neutral foundation at the end of 2025, and implementations exist at every major vendor and across open source. That is precisely its point: the socket does not commit you to the model using it.

What is the difference between MCP and an API?

Your API exposes a tool to developers; an MCP server exposes the same capabilities to agents, in a form they can discover and call on their own, with types and descriptions. In practice, an MCP server is often a thin layer over an existing API: if your tools have an API, they are within a connector's reach.

Is an MCP server a security risk?

Like any code executed with access: the risk lies in provenance, scope and trace, not in the protocol. The six questions above cover it; a reviewed server, run on your side, under least privilege and logged, is more auditable than the equivalent custom integration.

Our business tools have no official MCP server. Is that a blocker?

No, and it is actually the most common case: a server is built on top of the tool's existing API, including for in-house software. It is classic, bounded integration work, the kind we run in a workshop on your exact configuration.