What AI Agents Need to Read Your Data: MCP and the New Integration Layer
Four systems, four integration projects?
An architecture review, a few months ago. The team wants their new assistant to reach the CRM, the ERP, SharePoint, and the ticketing system. The integration lead does the maths out loud: "So that's four connector projects. And when we switch copilots next year, four more."
Until fairly recently, the honest answer was yes, that is exactly what it meant. Every AI tool spoke its own dialect, every system needed a custom bridge, and the bridges died with the tool that owned them. Integration cost was the quiet reason so many assistant projects stayed trapped in the demo stage, working beautifully on pasted-in text and never touching a live system.
That answer has changed, and the thing that changed it has one of the least memorable names in software: the Model Context Protocol, or MCP.
What MCP actually is
MCP is an open standard for connecting AI applications to data and tools. Anthropic released it in late 2024, and through 2025 it did something open standards rarely do: the competition adopted it. OpenAI, Google, and Microsoft all ship MCP support, and by now it is simply how the industry wires agents to systems.
The comparison everyone reaches for is USB-C, and for once the analogy holds. Before a common port, every device shipped its own cable. After it, any device connects to any charger, and nobody writes a cable strategy anymore.
Mechanically, it works like this. A system, say your document store, runs a small piece of software called an MCP server, which publishes what the system offers: "search contracts", "fetch document", "list recent changes". Any AI application that speaks the protocol, called a client, can discover those capabilities and use them. The client does not care which system sits behind the server, and the server does not care which vendor's agent is calling.
The arithmetic that changes budgets
Here is why this deserves a place in your architecture discussion rather than just your engineers' bookmarks.
Without a standard, connecting M assistants to N systems means M times N connectors. Four assistants and six systems: twenty-four integration projects, each one bespoke, each one dying with a vendor switch. With a standard, it means M plus N: six servers, built once per system, that every current and future client can use.
The second-order effect matters as much as the first. When your integration work is tied to a copilot vendor, switching vendors means rebuilding the plumbing, so you don't switch, so your negotiating position is poor. When integrations live on the system side and follow a standard, the copilot becomes replaceable. Procurement people tend to sit up at this point in the conversation.
Your data architecture becomes a menu
An MCP server is more than plumbing. It is a public statement of what a system offers and on what terms, and writing that statement forces questions that most organisations have deferred for years. What exactly does "customer" mean in this system? How fresh is this data? Which fields are safe to expose, and to whom?
These are the same four properties we described in our piece on AI-ready data architecture: lineage, consistency, timeliness, access control. MCP does not solve any of them. It standardises the socket, and everything that flows through the socket keeps whatever quality it had. An agent with beautiful protocol-level access to inconsistent, undocumented data will produce confident nonsense at a much higher speed than before. If anything, the standard raises the stakes on data quality, because it removes the integration delay that used to hide the problem.
The hard question moves to permissions
Once connecting things is easy, the question that used to fill integration meetings, "can we connect it?", becomes trivial, and the question underneath it takes over: "what should this thing be allowed to do?"
Three parts of that question deserve attention before your first agent goes live.
Identity. When an agent queries the ERP on behalf of an account manager, who is asking, the person or the software? The answer determines what data comes back and what your auditors see in the log. Credentials need scoping per agent and per capability, not one service account with broad read access that everything shares. The lesson of shadow AI applies here in reverse: this time you have the chance to build visibility in from the start, because every call passes through a server you control and can log.
Write access. Reading a record and creating an invoice are different classes of risk, and the difference deserves architecture, not just policy. A practical starting rule: agents read freely within their scope, and every write action above a triviality threshold routes through a human approval. You can loosen this later with evidence. Tightening it after an incident is a much worse meeting.
Prompt injection. The uncomfortable one. An agent that reads documents can be steered by documents: a supplier PDF or an inbound email can contain text crafted to redirect the agent's behaviour. With read-only scopes, injection is embarrassing. Combined with write scopes, it gets expensive. This risk is manageable, but it has to be managed by design: narrow scopes, approval gates, logging, and a healthy refusal to give one agent broad access across many systems just because the protocol makes it convenient.
One more caution while we are here: public MCP server directories now list thousands of community-built servers, of very mixed quality. Installing one is running third-party code against your systems. Review them the way you would any dependency, which is to say: actually review them.
Three questions for your next vendor meeting
The practical upshot fits on an index card. Does your product expose an MCP server, so our agents can reach it? Can your agent act as an MCP client against servers we run? And what does identity look like on both paths: per-user credentials, or one big service account?
Vendors' answers to these questions are changing month by month, mostly in the right direction. But the direction of the whole market is no longer in doubt, and integration budgets planned on 2023 assumptions are due a rewrite.
Rethinking your integration layer before the agents arrive? Start with Data Architecture for AI Readiness, or get in touch to map what an MCP-based estate would look like for your systems.