Is MCP The New Enterprise Integration Layer, And Should Your Business Care?

Last Updated: 31 October 2026

Yes, MCP is becoming the enterprise integration layer, and yes, your business should care, but not for the reason most vendors imply. MCP matters because it turns integration from a per-vendor project into a described interface: one agent, one protocol, many systems. It does not remove the hard work of permissions, and it does not make an unsafe system safe. It makes the plumbing standard.

The signal this week is that large enterprise vendors are shipping MCP servers as products rather than demos. On 22 October 2026, ADP released new capabilities in ADP API Central that put APIs, MCP servers and AI tools in a single platform, so an organisation can connect its preferred AI agent to workforce data while keeping enterprise security, governance and control. Precisely published a walkthrough for an MCP server that connects AI agents to customer communications. Two vendors, two very different systems of record, same protocol.

That is the pattern worth understanding. This post covers what MCP actually is, why enterprise vendors adopted it now, where the security boundary sits, what an on-prem MCP server looks like for an Australian mid-market business, and what to build first.

What is MCP, in plain terms?

The Model Context Protocol is an open standard for describing what a system can do so an AI agent can discover and call it. Think of it as a menu with instructions: the server publishes its capabilities, the agent reads them, and the agent calls the ones it needs. The protocol carries three kinds of capability: tools the agent can invoke, resources it can read and prompts that package a workflow.

Before MCP, connecting an agent to a system meant writing a connector for that agent framework, then rewriting it when the framework changed, then rewriting it again for the next framework. Each connector encoded the same business logic in a different dialect. MCP moves that logic into a server that any compliant agent can use, which is why the analogy to USB-C keeps appearing. The socket is standard. The device behind it is still yours to secure.

The important consequence is architectural. When the description lives in one server, the permissions, the rate limits and the audit logging live there too. That is a much better place to enforce policy than inside a prompt, because a prompt can be talked out of a rule and a server cannot.

Why did enterprise vendors adopt MCP now?

Because their customers asked for the same thing three times in different words: connect the agent to our data, do not copy our data out, and let us control who can do what. MCP is the first protocol that answers all three with one interface.

ADP's release is a good example of how a serious vendor implements it. The MCP servers sit alongside APIs and AI tools in API Central. Access is protected with mutual TLS and OAuth 2.0, so only approved users, applications and AI agents can reach workforce data. Configurable data entitlements define the specific information an agent can access and the actions it can perform. And the capabilities are split by role: employee self-service covers payroll, compensation, time-off balances and benefits questions, while manager self-service covers onboarding, timecards, attendance and scheduling.

Anthony Maggio, vice president and general manager of ADP Marketplace, described the intent: "The next wave of enterprise AI is about connecting intelligence to action. With these new capabilities in API Central, we're providing clients with the infrastructure to move beyond experimentation and quickly deploy intelligent workflows that connect workforce data with the applications employees are already using."

Isabel Espina, vice president of product development for shared products at ADP, added the buyer's view: "Organizations want to move quickly from AI proof-of-concept to real business outcomes, but they need secure and trusted access to workforce data to do that."

Read those two quotes together and the commercial logic is clear. The blocker was never the model. It was trusted access. MCP is the shape that trusted access now takes.

Where does the security boundary sit?

At the server, and at the gateway in front of it. An MCP server publishes tools, and every tool it publishes becomes reachable by every agent you connect. If a server exposes "read employee record" and "update bank details" with the same credential, then any agent that can call one can call the other. The protocol does not fix that. Your scoping does.

Three failure modes show up repeatedly. The first is an over-broad tool surface: a server that exposes the whole system because it was easier than choosing the twenty operations the workflow needs. The second is credential sprawl: each server holding its own long-lived secret, rotated by nobody. The third is no audit trail: calls happen, but nobody can say which agent called what, under whose authority, and when.

The fix is the same pattern as any API integration, applied with more discipline because the caller is autonomous. Put the server behind a gateway that holds the credentials, enforces an allowlist, checks argument schemas and logs every call with the agent's identity. Give each agent its own identity rather than a shared key. Scope tools to the workflow, not to the system.

What does an on-prem MCP server look like in practice?

For an Australian mid-market business, the useful pattern is a small server that sits inside the network and describes a narrow slice of one system. Take a wholesale distributor running an ERP with a customer master, price lists and open orders. The MCP server exposes four read tools and two write tools. Read tools cover customer lookup, price lookup, stock availability and order status. Write tools cover creating a quote and adding a note to an order. Nothing else is exposed.

The agent that drafts quotes uses the read tools freely and the write tools behind an approval gate. The credentials for the ERP live in the server's secret store, never in the agent's context. Every call is logged with the agent's identity, the tool name, the arguments and the outcome. If the agent is compromised, the blast radius is four reads and two gated writes, not the ERP.

This is where on-prem earns its keep. The server can reach systems that were never designed for internet exposure, and the data does not leave the building to be integrated. For businesses with confidentiality obligations or customers who ask where their data sits, that is a simpler answer than a chain of cloud connectors.

The trade-off is that you own the server's uptime, its schema changes and its security patches. That is a real operating cost, and it is the same cost you already carry for any internal integration.

What should you build first?

One read-only server over one system, in a week. Pick the system that creates the most manual lookup work, describe the five operations people ask about most often, and expose them as read tools. Run an agent against it in a sandbox and log every call. You will learn more about your data quality in that week than in a quarter of architecture meetings.

Then add writes, one at a time, each behind an approval gate. Then measure. Count the calls, the approval rate and the time saved per task. If the numbers hold, widen the surface. If they do not, you have spent a week and learned something concrete, which is a better outcome than a six-month integration programme that nobody can evaluate.

What does this mean for Australian mid-market businesses?

Two things. First, MCP lowers the cost of connecting an agent to the systems you already run, which makes automation viable for businesses that could not justify a bespoke integration per workflow. Second, it raises the importance of the privilege boundary, because a standard interface is also a standard attack surface.

The practical answer is to treat an MCP server the way you would treat any internal API: owned by someone, documented, versioned, logged and reviewed. If you already have an integration gateway, put the MCP server behind it rather than beside it. If you do not, build the gateway first, because you will need it the moment a second agent connects.

If you want to see how we structure agent workflows around a real pipeline, our post on building an agent around a content workflow covers the harness side. If you are weighing an on-prem stack against a cloud one, our post on self-hosted agents covers the data custody trade-offs. And if you want an MCP server scoped for your ERP or CRM, talk to us.

Frequently asked questions

What is the Model Context Protocol?

MCP is an open standard for describing what a system can do so an AI agent can discover and call it. A server publishes tools, resources and prompts, and any compliant agent can use them without a bespoke connector per framework.

Is MCP only for developer tools?

No. ADP shipped MCP servers for workforce data inside API Central in October 2026, and Precisely published an MCP server for customer communications. Enterprise systems of record are adopting it because it gives one interface for many agents.

Does MCP make an integration secure?

No. MCP standardises the interface, not the permissions. Security comes from scoping the tools, giving each agent its own identity, holding credentials in a gateway and logging every call. An over-broad MCP server is a larger attack surface, not a smaller one.

Should an MCP server run on-premises or in the cloud?

It depends on where the system of record lives and what confidentiality obligations apply. An on-premises server keeps credentials and data inside the network and can reach systems never designed for internet exposure. The trade-off is that you own its uptime and patching.

What should we expose first?

Five read-only operations over the system that creates the most manual lookup work. Run them in a sandbox with full logging, then add write tools one at a time behind approval gates, and widen the surface only when the numbers justify it.