MCP and managed agents: how to connect to data without writing one-off glue code
The Model Context Protocol changes how agents connect to external systems. I break down what this means for architecture and data management in enterprise.
When companies start building agentic systems, they quickly hit the same question: how should an agent get access to data and external systems? The first solutions are almost always makeshift: hardcoded URLs, API keys in config files, a wrapper built for a specific task. It works - but it does not scale.
The Model Context Protocol (MCP) is an attempt to give a standard answer to this question.
What MCP is
MCP is an open protocol proposed by Anthropic in late 2024 that describes a standardised way for language models and agents to connect to external data sources and tools. Instead of solving from scratch each time how an agent will talk to a database, a file system, a calendar, or an internal API, MCP provides a unified interface.
The logic is similar to how HTTP unified the web: you do not need to negotiate a communication protocol every time. Everyone speaks the same language.
For developers this means: write an MCP server for your system once, and any agent that supports the protocol can work with it.
Why this matters for enterprise
In a corporate environment, data is spread across dozens of systems: ERP, CRM, databases, file storage, internal APIs, message queues. Every integration built from scratch is time, risk, and ongoing maintenance.
MCP changes the equation: a system that has an MCP server becomes available to any agent in the ecosystem. This is a shift from "we built this for the specific task" to "we connected via the standard".
The second important dimension is managed agents. The term refers to agents that operate in a controlled environment: with defined permissions, with action logging, with the ability to audit. MCP supports this model because the connection interface is standardised and because the server can control exactly what it exposes to the agent.
What this changes architecturally
Without a standard, agent integrations with systems look like spaghetti: every agent knows the internals of every system it connects to. That is fragile - a change to one system's API breaks every agent that uses it.
With MCP, the agent knows the protocol, not the internals of the specific system. The MCP server handles the translation: it knows how to talk to the system and exposes a standardised interface to the agent.
This separation of concerns reduces coupling and simplifies maintenance.
Practical questions when adopting
MCP is a young protocol - the ecosystem is growing but is not yet complete. Before building on top of it, it is worth understanding:
- Which systems in your landscape are the priority sources for agents?
- Are there ready-made MCP servers for them, or does development work need to happen?
- How will access control be structured - which data is an agent allowed to see?
- How will you log what the agent accessed and what it did with the data?
- Who on the team is responsible for maintaining MCP servers as infrastructure?
The standard solves the protocol problem. It does not solve the problems of governance, security, and architecture for you. Those need to be designed separately, using what the standard provides as a building block.
How to think about this now
MCP is not a mandatory requirement for every AI project right now. But it is a signal about the direction in which the agentic ecosystem is moving. Companies building agent integrations with their own systems will eventually face a choice: continue with one-off glue code or move to the standard.
It is better to start thinking about that choice before a large pile of custom integration code has accumulated.