Model Context Protocol (MCP) is becoming one of the most important pieces of enterprise AI infrastructure. How are ERP leaders thinking about it inside their organizations and their AI stacks?
MCP, introduced by Anthropic in late 2024, gives AI applications a standard way to connect to external systems. In practical terms, it lets an AI agent discover and call approved tools, data sources, APIs, and workflows through a common protocol rather than requiring a custom integration for every system it touches.
That sounds technical, but for ERP teams, it is strategic.
Agentic ERP depends on the ability of AI agents to reach the systems where business work happens: finance, HR, procurement, manufacturing, supply chain, payroll, customer service, planning, and analytics. MCP is one of the standards for making those connections possible. It can reduce integration friction, but it also moves a sensitive control problem closer to the core of the enterprise stack.
The protocol decision being made now will shape how agents access ERP systems, how much custom integration work customers still need, and how securely AI can move from answering questions to taking action.
What MCP Actually Does
MCP works through a client-server model.
An MCP server exposes a set of tools or resources. That could mean reading a table, running a report, querying a customer record, checking inventory, opening a ticket, triggering an approval, or posting a transaction. An MCP client, usually the AI application or agent runtime, discovers those tools and invokes them when the user’s task requires it.
The easiest analogy is that MCP plays a role for AI agents similar to the one earlier integration standards played for applications and data. Open Database Connectivity (ODBC) gave applications a standard way to talk to databases. APIs gave software a standard way to connect services. MCP gives agents a standard way to discover and use tools.
That does not make MCP a replacement for ERP, APIs, identity management, data governance, or security architecture. It sits above those layers. The ERP still owns the business process. Identity still decides who the user or agent is. The data foundation still determines whether the output can be trusted. Governance still defines what the agent is allowed to do.
MCP gives agents a common doorway into those capabilities. The quality of what happens next depends on how that doorway is designed.
Why MCP Is Moving So Fast
MCP has momentum because the agent market needed a shared connection model.
- OpenAI now documents support for remote MCP servers and connectors in its developer platform.
- Microsoft supports MCP in Azure AI Foundry Agent Service.
- Databricks describes MCP as an open-source standard for connecting AI agents to tools, resources, prompts, and context, with Unity AI Gateway governing access and monitoring activity across MCP servers and LLM endpoints.
- Snowflake has a managed MCP server that lets agents retrieve data from Snowflake accounts without separate infrastructure.
- Salesforce has added MCP support to Agentforce.
- SAP has released MCP servers for developer workflows such as Fiori and CAP, while its broader AI roadmap includes Joule, Claude, and agent orchestration work.
That vendor movement shows ERP leaders that standards often become architecture by accumulation. A single MCP server may look like a developer convenience. Dozens of MCP servers across ERP, data platforms, SaaS tools, analytics systems, and developer environments become an integration strategy.
Instead of building a one-off connector for every agent-to-system interaction, teams can register an MCP server, expose scoped tools, and let compatible agents use them. That can make experimentation faster and reduce the cost of connecting agents to enterprise data.
It can also spread risk quickly if every team builds its own server without common governance.
Analysis
What this means: MCP is where agentic ERP earns control. ERP leaders should treat MCP server architecture as a design decision that will outlast the current AI cycle. Vendor-provided servers, custom servers, and governed data-product servers will create different trade-offs around agility, supportability, security, and lock-in.
The Permission Problem
MCP makes it easier to expose ERP capabilities to AI agents. That is also the danger.
A poorly designed MCP server can give an agent access to sensitive functions at a level no individual user would be granted through the normal ERP interface. Procurement, payroll, customer records, financial close data, pricing, production schedules, employee information, and supplier data all become more exposed when agents can discover and call tools directly.
The access model has to be designed at the protocol boundary. ERP teams need to know which user identity is being passed, how authorization is handled, which roles and scopes are active, which tool was invoked, what data was returned, and whether the agent only read information or changed business state.
The audit questions are just as important: Can the organization reconstruct what happened after an agent acted through MCP? Who initiated the request? Which agent or client made the call? Which server handled it? What authority did it use? What data was queried? What transaction, approval, or workflow changed?
Those questions cannot wait for production incidents. They belong in the design of every MCP server tied to ERP data or business process execution.
Analysis
What this means: Access control has to follow the agent into the workflow. Permissions that once lived mainly in the ERP interface, API gateway, or integration layer now need to be reflected in MCP scopes, identity propagation, tool design, and audit logs. CIOs and enterprise architects should redesign access models for agentic workflows before MCP exposes old weaknesses through new interfaces.
Sponsor Industry‑Grade Research
MCP Servers Need Product Discipline
ERP teams should treat MCP servers as governed enterprise interfaces.
Each server needs an owner, version history, documentation, testing, monitoring, rate controls, schema validation, and a clear purpose. Read and write capabilities should be separated where risk justifies it. High-impact actions should include human approval or escalation. Sensitive workflows should require stronger identity propagation and least-privilege scopes.
The cost model also deserves attention. Poorly designed servers can generate excessive tool calls, inflate token usage, increase latency, and degrade the user experience. An agent that queries five systems to answer a question that should have required one governed data product is not intelligent architecture. It is expensive integration sprawl with a conversational interface.
Security teams also need to account for prompt injection, tool poisoning, overbroad permissions, and supply-chain risk. MCP’s openness is part of its appeal, but open ecosystems require stronger control over which servers are approved, which tools are exposed, and which agents can reach them.
That is why enterprise MCP registries are gaining attention. A registry gives organizations a catalog of approved MCP servers and tools, turning discovery into a governed process rather than a free-for-all. For ERP environments, that registry could become the agent-era equivalent of an integration catalog.
Vendor MCP Strategies Taking Shape
ERP vendors do not—and will not—all use MCP in the same way.
Some will expose narrow, highly governed servers for approved agent actions. Others will use MCP mainly for developer productivity, documentation, or scaffolding. Data platform vendors will emphasize governed access to curated data. SaaS vendors will use MCP to make their applications easier for agents to call.
ERP customers should watch the boundaries carefully. A vendor-provided MCP server may be safer and easier to support, but it may also limit flexibility or reinforce platform lock-in. A custom MCP server built around governed internal data products may give the enterprise more control, but it also creates responsibility for security, maintenance, observability, and compliance.
The right answer will vary by workflow. A finance close assistant may need vendor-governed tools tied closely to ERP permissions. A reporting agent may work better against a governed lakehouse or warehouse layer. A procurement agent may need a mix of vendor tools, internal policy logic, and human approval gates.
The key is to make the architecture choice deliberate. MCP should not become the next place where shadow integrations accumulate.
Analysis
What this means: Agentic ERP will change integration economics. MCP can reduce the cost of connecting agents to systems, but easier connection increases the need for governance, observability, cost discipline, and lifecycle management. ERP teams can build MCP registries, approval models, and monitoring practices before agent adoption scales beyond pilot environments.
Get Our Free Weekly Newsletter
Shifting ERP Integration Economics
MCP changes the economics of connecting agents to enterprise systems.
When every new agent requires custom integration work, only the highest-value use cases clear the investment threshold. When a compatible agent can use approved MCP servers, more workflows become economically reasonable to attempt. That opens the door to broader agent experimentation across various operations.
The same shift increases the need for platform discipline. The marginal cost of connection may fall, but the governance burden rises. More agents touching more tools creates more demand for identity propagation, access reviews, observability, cost controls, testing, and lifecycle management.
ERP leaders should start building MCP strategy into agentic AI roadmaps now. The protocol may sit below the application layer, but the decisions around it will affect business process control, integration cost, vendor dependence, and audit readiness for years.
