MCP for Enterprise AI Integration: A 2026 Business Guide

Connecting a language model to your ERP stopped being a technical problem in 2026. There is a shared protocol, tens of thousands of ready-made connectors, and most major enterprise software vendors now publish their own. The real issue sits somewhere else: the moment you open that connection, the decision about which data goes where stops being written in code and starts being made by a model.

That sounds like a small distinction. It is not. In a conventional integration, if a field leaves your system, a developer put it there and you can point at the line. In an AI integration, the model calls a tool with parameters it chose, and whatever comes back lands directly in the context. The scope is decided at runtime.

This article maps the technical and governance ground around that decision. The subject is MCP, the Model Context Protocol: announced by Anthropic in November 2024, handed to the Linux Foundation in December 2025, and today, on 28 July 2026, receiving the largest revision since its launch. If you want the full picture of infrastructure choices first, our guide to AI infrastructure decisions is the pillar for this series. Here we go one level down, into the integration layer.

What is MCP, and why is everyone talking about it in 2026?

MCP is an open protocol that describes how an AI application connects to outside tools and data sources. Put plainly: it is the shared language a model uses when it talks to your systems. Anthropic built it, but since December 2025 it has been governed by the Agentic AI Foundation under the Linux Foundation. Platinum members include AWS, Google, Microsoft, OpenAI, Bloomberg and Cloudflare.

For a decision maker, that governance change matters more than any technical detail. In 2025, "does adopting MCP lock us into Anthropic?" was a fair question. Today the protocol is owned by an independent foundation funded by eight of the largest players in the field. The risk profile behind the standard is simply different now.

The adoption numbers back it up. Anthropic reported over 97 million monthly SDK downloads and more than 10,000 public servers as of December 2025. The official registry listed 9,652 servers in May 2026. Salesforce moved its own platform onto MCP in April 2026 and reported 4.5 million calls within a month.

One number deserves a caveat. You will find claims that 78% of enterprise AI teams run MCP-backed agents in production. That figure has no published methodology behind it. The best-sourced survey available puts production use at 41% of software organisations, split between limited and broad deployment. Plan against 41%, not 78%.

What did integration look like before MCP?

Short answer: every AI application was wired to every tool separately. Five models and ten systems meant fifty integrations. The industry calls this the N×M problem, and MCP reduces it to N+M. You wrap each system once, and the whole ecosystem can use it.

A common misunderstanding is worth clearing up here. MCP did not replace function calling. It is a standardisation layer sitting on top of it. Function calling still describes how a model invokes a tool; MCP describes how that tool is discovered and packaged. If you have one agent, a small fixed set of tools, and nobody else will ever consume them, plain function calling is still enough. What MCP buys you is reuse.

In practice that means a server you write once runs inside Claude, ChatGPT, Microsoft Copilot Studio and your own agent platform without modification. You connect the system once, and swapping model providers no longer means rewriting the integration. Turning model choice into a reversible decision is the clearest business argument for MCP.

The architecture, in three words

MCP has three roles. The host is the AI application itself: a desktop client, an IDE, your internal agent platform. It acts as the security broker and decides which connections are permitted. The client is the connection endpoint the host opens for each server. The server is the side that publishes tools, resources and prompt templates, which in your case is the layer you put in front of your ERP or database.

A server can expose three things: actions the model can invoke, readable data, and prepared prompt templates. The connection runs either as a local process on the machine or as a remote HTTP service.

Today's revision changes something significant here: the protocol became stateless. Session management is gone. Translated into infrastructure terms, a remote MCP server can now sit behind an ordinary load balancer with no sticky routing and no shared session store. Costs and complexity drop. The same revision opened a 12-month migration window, so existing deployments will not break tomorrow, but the date belongs on your roadmap.

How many MCP servers should you connect?

Far fewer than you think. This is also the answer to the most common mistake in the field: the assumption that more connected systems is automatically better works in reverse.

The measurements are blunt. In one production deployment, three servers exposing roughly forty tools consumed 143,000 of a 200,000-token context window. That is 72% of the window spent on tool definitions before the user typed a single question. Sessions with five to ten servers installed can burn 50,000 to 67,000 tokens before the first prompt. Some clients now enforce hard caps, and output quality is reported to degrade noticeably past forty tools.

Every tool you attach to an agent takes a slice of that agent's room to think. Integration is a budgeting exercise, not a collection contest.

The counterargument deserves airtime. One of the protocol's creators argues this is a client implementation problem rather than a protocol flaw, and progressive discovery, where tools are searched on demand instead of loaded upfront, has already cut main-context load by roughly 47% in newer clients. Still, if you are deploying today, the practical advice holds: add systems one at a time and measure after each.

Is MCP secure?

Being a standard does not make it safe. The protocol standardises discovery and invocation; authentication, authorisation, data hygiene and error semantics remain entirely yours. The incident record of the past two years makes the point better than any argument.

The most instructive case is Asana's. An access control flaw in its MCP server, live from May 2025, made one organisation's projects, tasks, comments and files visible to other customers. The bug was present from day one, went unnoticed for about a month, and affected roughly a thousand customer organisations. In September 2025, a package impersonating an email service was found forwarding a blind copy of every sent message to an attacker, the first documented case of a malicious MCP server distributed through a public registry.

More alarming than individual incidents is the baseline that scanning reveals. A security firm analysed 2,614 MCP implementations: 82% used file operations vulnerable to path traversal, and 34% touched APIs exposed to command injection. A separate scan found over 24,000 secrets in MCP-related configuration files, of which 8.8% were still valid at scan time.

Three attack patterns cover most of the risk. Prompt injection: any external content reaching the model, an email, a customer ticket, a repository issue, can be read as an instruction. Tool poisoning: malicious instructions hidden inside a tool's description, because tool descriptions are effectively executable text. Rug pull: a tool you approved once quietly rewrites its own definition later. The only real defence is enforcing authorisation in your own architecture rather than trusting the protocol to do it.

Where does your data actually go?

This is the question that decides whether the project is approved, and it is worth answering before any procurement conversation starts.

If your model runs on a provider's infrastructure in another jurisdiction, every personal data record returned from your ERP constitutes a cross-border transfer. Most data protection regimes treat that as a distinct legal act requiring its own basis, and several regulators have stated explicitly that using AI systems hosted abroad qualifies. Regional note for readers operating in Turkey: the data protection authority has confirmed this reading in its generative AI guidance, so the transfer analysis applies from the first query, not from the first incident.

What makes MCP specific here is that you cannot fully write down the scope of the transfer in advance, because the model decides which records to fetch. A conventional integration lets you say "these three fields leave the building". An agent architecture does not.

The healthiest starting pattern we see in the field is to open the MCP server read-only and column-restricted: never publish columns containing personal data, and begin with impersonal records such as stock levels, order volumes and account movements. If keeping data inside your own perimeter is the deciding factor, our analysis of self-hosting an LLM covers what that choice costs in practice.

What does building an MCP server take?

A straightforward server connecting a single system is a two to four week job for an experienced developer. Add role-based access control and audit logging and it becomes four to eight weeks. A multi-tenant, enterprise-grade deployment starts at twelve weeks. Treat these as effort magnitudes rather than quotes.

If the software you already use publishes an official server, the picture changes completely. Salesforce, ServiceNow, SAP, Microsoft, Atlassian, GitHub, Slack, Box, HubSpot, Snowflake and AWS all ship one. In that case, decision to production can take a matter of days.

The line nobody budgets for is maintenance. Vendor APIs change, authorisation flows get updated, the protocol itself ships new versions, which is exactly why today's revision includes a 12-month migration window. Budgeting roughly half of the first-year build cost as annual maintenance is a realistic planning assumption. For a concrete walkthrough of what these cost lines look like end to end, our agent setup story itemises them.

Frequently asked questions

Do we need MCP, or is function calling enough? Function calling is enough for a single agent with a small fixed toolset that nothing else consumes. Choose MCP in three cases: multiple AI applications will connect to the same system, you may switch model providers, or other teams should be able to reuse the connection.

Can an MCP server run entirely on our own infrastructure? Yes. The server can run inside your network and connect to a model you host yourself. That combination removes the cross-border transfer question altogether, at the cost of hardware and model quality.

Are servers from public registries safe to use? Not by default. Servers published by the software vendor itself and community packages do not carry the same level of assurance, and at least one registry-distributed package has been confirmed as backdoored.

Will switching models force us to rewrite the integration? No, and this is the core problem MCP solves. The same server works across different providers' applications; only the host-side configuration changes.

So what should you actually do?

• Start with one system. Pick the one people ask the most questions about, usually the sales and inventory side of the ERP. Do not connect two at once, or you will not be able to attribute the gain.
• Open it read-only. Give the model no write permission in the first release. Write access comes after three clean months of reads, and only behind a human approval step.
• Manage tool count like a budget. Measure context consumption and answer quality after every new server. Past forty tools, stop and prune.
• Do not delegate authorisation to the protocol. Which user may see which record has to be decided in your server, bound to a verified identity. A request from the model is not a justification on its own.
• Write the data question down on one page. Which fields may leave, where the model is hosted, and what the legal basis for the transfer is. If that page does not exist, the integration does not go live.
• Review third-party servers before production. Read the source of anything you did not write, or have someone read it. Backdoored packages are no longer a theoretical risk.

The genuine value of MCP is that it turns AI integration from a one-off project into a replaceable layer. Built well, switching model providers becomes a weekend task. Built badly, you have installed a door in front of your most sensitive data, and what comes through it is decided probabilistically. The protocol does not determine which of those you end up with. The boundaries you draw do.

If you are working out where those boundaries belong in your own stack, an hour of structured review usually settles it.