AI agents are not just supposed to answer questions. They are supposed to access enterprise data, use tools, and carry out actions.
This is exactly where a new integration problem arises.
Because an agent can only act if it is able to communicate with a company's systems.
Until now, APIs, custom integrations, and proprietary connectors were built for that purpose.
With the Model Context Protocol (MCP), a standardized approach is now emerging for connecting AI applications to tools and data sources. MCP was originally introduced by Anthropic and is now being developed further by a broad community.
In July 2026, a substantially revised specification was published as version 2026-07-08. Among other things, it brings a stateless protocol core, new extension mechanisms, improvements to authorization, and better scalability.
That makes MCP increasingly interesting for enterprise architectures.
But MCP does not replace classic APIs.
What MCP actually solves
Traditionally, an application had to implement a custom integration for every new system.
CRM system A requires one integration.
ERP system B requires another.
Document platform C requires yet another.
The problem grows with every new agent.
MCP starts from a different angle.
An MCP server exposes tools or data in a standardized way to an MCP client.
This creates a shared interface between agents and enterprise systems.
The goal is not to abolish APIs.
The goal is to make AI applications' access to existing capabilities more standardized.
MCP is not a replacement for integration architecture
This is where an important distinction lies.
A company still needs:
- APIs
- Identity management
- Data integration
- Eventing
- Security
- Governance
- Monitoring
MCP sits above, or rather in between.
An ERP system does not suddenly have to migrate its entire internal architecture to MCP.
Instead, an MCP layer can make specific functions of the system accessible to agents.
That can mean, for example:
"Find the customer."
"Check the order status."
"Create a support case."
The agent does not need to know how the backend works technically.
Why this is becoming relevant right now
MCP is developing remarkably fast.
The current specification is aimed far more strongly at enterprise requirements than earlier versions. Among other things, the new version relies on stateless communication, better routing options, and stricter authorization mechanisms.
The MCP roadmap now explicitly focuses on topics such as agent identity, enterprise security, and HTTP-native transport mechanisms as well.
This shows: MCP is evolving from a developer tool toward infrastructure for agentic systems.
What does this mean for APIs?
APIs remain the foundation, but their role is changing.
A classic API answers the question: "How can an application access a function?"
An agent-ready interface must additionally answer: "How can an AI system understand what this function does and when it is allowed to use it?"
That makes description and context more important.
A tool should not simply be called "create_case", for example.
An agent has to understand:
- What does the tool do?
- Which parameters does it require?
- Which data does it change?
- Which errors can occur?
- Which permissions are required?
API design is therefore increasingly becoming AI tool design as well.
The security problem
More access also means more risk.
If an agent can use ten tools, it potentially holds ten ways to intervene in enterprise systems.
This is why providing an MCP server is not enough.
Companies need clear rules.
Authentication
Who is the calling client?
Authorization
What is this client allowed to do?
Scope
Which concrete resources may it use?
Audit
What was called, and when?
Monitoring
Which actions occur unusually often?
In the enterprise environment in particular, MCP therefore becomes not only a developer topic but a governance topic as well.
MCP and MuleSoft
For integration platforms, this development is especially interesting.
MuleSoft has pursued an API-first approach for years. APIs form the connection between applications, data, and processes.
MCP can build on that.
An existing business function does not have to be integrated individually for every new agent. Instead, a standardized MCP access layer can be placed on top.
This creates one possible architecture:
Agent --> MCP --> API Layer --> Integration --> Backend
The decisive point:
The agent does not get direct access to every backend.
The existing integration architecture remains the control layer.
MCP or API?
The answer is usually: both.
APIs remain useful when applications communicate directly with each other.
MCP becomes interesting when AI systems are supposed to use tools and context dynamically.
For example:
API: A commerce application retrieves the order status.
MCP: An AI agent is given a tool with which it can determine the order status, and decides for itself when that tool is needed within a task.
This is an important difference.
What companies should prepare now
Anyone who wants to adopt MCP should not immediately make every system "MCP-ready".
A step-by-step approach is better.
-
Analyze existing APIs
Which business functions already exist?
-
Identify agent use cases
Which functions should agents use in the future?
-
Define tools
Which actions have to be available as safe and comprehensible tools?
-
Set permissions
Which agents may use which tools?
-
Integrate governance
How are new tools reviewed and approved?
-
Build monitoring
How do tool calls and agent actions become traceable?
Conclusion
MCP is not a replacement for APIs.
It is a new layer for a world in which AI systems interact with enterprise software on their own.
For companies, that means an important change: APIs do not have to disappear — they have to become usable for agents.
Anyone who has a clean API and integration architecture today therefore holds an important advantage.
Because the next generation of enterprise software will not be operated by humans through user interfaces alone.
It will increasingly be used by agents through standardized interfaces.