MCP solved the integration problem. It just made the governance problem bigger.

On 9 December 2025, Anthropic donated the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. Three months later, the Python and TypeScript SDKs were seeing roughly 97 million monthly downloads. There are now more than 10,000 publicly listed MCP servers, with hundreds being added every week. Microsoft, Google DeepMind, Salesforce, Cloudflare, Replit, GitHub and the major coding-assistant tools all ship MCP support natively. The protocol war is over. MCP won. The question that hasn't been seriously asked yet — at least not at the level that European enterprises ought to be asking it — is what they have actually adopted when they adopted MCP. The protocol is genuinely good engineering. It is also a new perimeter that most enterprises have not yet drawn around.

This is the sixth piece in the series I've been writing for neuland.ai. The thread running through it is straightforward: in enterprise AI, the value, risk and moat all sit in the layer above and around the model rather than in the model itself. The arc has been control plane, then drift and observability, then model topology, then tool-call sovereignty, then agent architecture and the lethal trifecta. [¹] This piece extends one more step. The tool layer is now the new perimeter. And MCP — its rise, its governance shift, its current limitations, and what the 2026 roadmap explicitly admits — is the cleanest demonstration of why that statement matters.

What MCP actually solved

It is worth being clear about what the protocol is and what it changed, because the case for adoption is real. Before MCP, every AI application that wanted to use a tool wrote a custom integration. An assistant that needed Postgres access, Slack messaging and GitHub repository search required three separately engineered connectors, each coupled to both the AI model's API format and the external tool's interface. Multiply that across the dozens of tools a serious enterprise agent needs and you have what the literature calls the N×M problem: every model talking to every tool through bespoke glue, all of it written from scratch, none of it reusable. [²]

MCP, introduced by Anthropic engineers David Soria Parra and Justin Spahr-Summers in November 2024, replaced that with a single open standard. A tool exposes its capabilities through an MCP server. Any MCP-aware AI client can discover and use those capabilities through the same protocol. The wire format is JSON-RPC 2.0; the transport since the November 2025 spec release is Streamable HTTP. [³] One server, every client. One client, every server. The engineering case is genuinely strong.

The growth has been correspondingly steep. MCP went from around two million monthly SDK downloads at launch to 97 million by March 2026 — roughly a 50x increase in 16 months. For comparison, Kubernetes took about four years to reach comparable deployment density. [⁴] The protocol now sits behind the major coding-assistant ecosystems (Claude Code, Cursor, Zed, Windsurf), behind enterprise platforms (Salesforce Agentforce, Microsoft Semantic Kernel, Azure OpenAI), and behind the agentic frameworks proliferating across every vertical from finance to manufacturing.

The transition to Linux Foundation governance, announced on 9 December 2025, did one more important thing: it removed the single-vendor risk that had kept procurement teams cautious. MCP is no longer Anthropic's protocol. It is the industry's protocol, on the same governance path as Kubernetes, PyTorch and Node.js. [⁵] For an enterprise architect signing a multi-year integration commitment, that is meaningful and it should be acknowledged. It is also a necessary condition for what comes next, not a sufficient one.

MCP is one execution surface, not the only one

A point worth being precise about before going further, because I made it in the February piece in this series and it has only become more relevant since. MCP is one execution surface among several that a serious enterprise agent stack needs to govern. CLI and shell-based tool execution, direct code execution sandboxes, browser automation, workflow fabrics like n8n, and bespoke enterprise connectors are all execution surfaces in their own right. None of them is going away. The honest engineering position is not "MCP versus CLI" or "MCP versus everything else" — the debate as it gets framed online is more ideological than the underlying engineering deserves. It is "which execution surface fits which task, and what governs across all of them." [²]

MCP's recurring failure mode at scale is one I argued in February and which the 2026 deployment data has largely confirmed. The protocol works beautifully for tool discovery and invocation, but its payload and composition model can inadvertently encourage LLM-centric data processing: tool definitions are pulled into the model context, tool outputs are often verbose, filtering and aggregation get done by the model rather than by deterministic preprocessing, and every added capability increases context entropy. The architecturally cleaner pattern — execute, reduce deterministically, present a bounded result, then let the model plan the next step — is harder to maintain when MCP is treated as the default rather than as one option among several. None of this makes MCP a bad protocol. It makes MCP a protocol whose strengths reward governance discipline and whose weaknesses are amplified by its absence. [¹⁵]

What the headline doesn't tell you

Here is the part of the story that the 97 million number obscures. Every MCP server an enterprise connects to is, simultaneously, a piece of third-party code in its trust boundary, a credential holder representing real organisational privilege, and a jurisdiction whose data-flow implications most enterprises have not assessed. None of those three properties is new to enterprise IT individually. What is new is the speed at which they are being assembled and the scale at which they are being deployed, on a protocol whose specification still does not mandate authentication.

Authentication in MCP is optional. It is a recommended best practice. It is not a requirement of the protocol. Research published in early 2026 documented more than 1,800 active MCP servers on the public internet running with no authentication at all — typically because they were built from tutorials written before OAuth support was added to the spec. [⁶] Trend Micro has so far catalogued 102 MCP-specific CVEs. [⁷] OpenSSF's SAFE-MCP catalogue documents over 80 attack techniques specifically targeting MCP-based tool systems, including prompt injection, confused-deputy attacks where agents delegate tasks without narrowing authorisation scope, context-integrity failures from insufficient audit trails, and "rug-pull" attacks in which a previously-trusted MCP server gets quietly modified to be malicious after enterprise adoption. [⁸] Atlassian's own security guidance for customers adopting MCP separately documents naming-collision and tool-impersonation attacks, in which an agent reaching for "Safe Operation Guide" silently lands on "Safe Operations Guide" instead. [⁹]

The supply-chain dimension here is the same pattern I flagged in last week's piece on the lethal trifecta. [¹⁰] When 12 percent of skills on the OpenClaw ClawHub registry are malicious, when there are 8,000 open MCP servers exposed on the public internet according to Bishop Fox's AIMap research, the implication is not that any specific protocol is broken. The implication is that the agent tool layer now has a supply-chain attack surface comparable to npm or PyPI, and the procurement, audit and governance processes that European enterprises have built around npm and PyPI over the past decade do not yet exist for MCP.

The roadmap is the admission

The strongest evidence that this gap is real comes from the MCP project itself. The 2026 MCP roadmap, published 5 March 2026 under the new Linux Foundation governance, lists four strategic priority areas. The fourth is named, plainly, "Enterprise Readiness." [¹¹] Under that heading sit the things every enterprise architect has been asking the protocol to provide:

• End-to-end audit trails sufficient for regulatory compliance

• SSO-integrated authentication, replacing static client secrets with managed flows

• Defined gateway and proxy behaviour, so that traffic routed through an intermediary has clear semantics for authorisation propagation and session affinity

• Configuration portability across MCP clients

The roadmap also notes, candidly, that "an Enterprise WG does not yet exist," that the working group is in formation, and that "most of the enterprise readiness work to land as extensions rather than core spec changes." [¹¹] That is the language of a community making the right strategic choice — keep the base protocol lean and let enterprise concerns live in extensions — and it is exactly the right thing to do at the protocol governance level. It is also the public acknowledgement that the properties an enterprise needs to operate MCP in compliance with European regulatory obligations are not yet shipped, and the design of how they will be shipped is open work.

For an organisation deploying MCP in 2026 against the realities of GDPR audit obligations, DORA logging requirements, or the EU AI Act's traceability provisions, this is the gap. The protocol is production-grade. The enterprise governance layer above the protocol is, by the maintainers' own description, an open work item being volunteered into by interested community members.

The jurisdictional dimension nobody is talking about

Beyond the security and audit gaps, there is a third issue specific to European enterprises that almost no one in the broader MCP conversation is addressing properly. Every MCP server runs somewhere. Calling an MCP server is a data flow. The protocol is jurisdiction-neutral; the deployment of the protocol is not.

When an EU-hosted AI agent calls a US-hosted MCP server — and the major commercial MCP servers from US providers typically are US-hosted by default — the agent's context, including any data it has retrieved from internal European systems, crosses the Atlantic. That data is subject to the CLOUD Act and to US contract law from the moment it lands at the foreign endpoint. No amount of EU-residency for the model layer changes that. The EU-hosted model has done its inference inside the European Data Boundary; the tool call that followed has taken the data outside it. [¹²] The whole reason I argued in the last Copilot piece that compliance is a system property is this exact pattern. [¹³] MCP makes the pattern easier to assemble, easier to deploy at scale, and easier to overlook in a procurement review.

This is not an argument against MCP. It is an argument against MCP-without-an-orchestration-layer. The protocol gives you the wire format. It does not give you the perimeter.

What enforcement-by-construction looks like for MCP

The architectural answer to the issues above is, structurally, the same answer I have been arguing for across the previous five pieces. The orchestration layer is where the work gets done, because the orchestration layer is the only place where the whole MCP topology is visible at once. Concretely, what an MCP-aware orchestration layer enforces:

Execution surface selection. The first question is whether a task should go through MCP at all. Some workloads are better expressed as a CLI invocation with deterministic output reduction; some belong in a sandboxed code-execution module; some fit a workflow fabric like n8n; some genuinely need the MCP ecosystem reach. The orchestration layer picks the right execution surface per task rather than forcing everything through one protocol. MCP is a powerful adapter for ecosystem leverage; it is not the default tool layer just because the SDK is convenient.

Server allowlisting and provenance verification. Not every MCP server is in scope. First-party servers from established enterprise vendors are different from a community-maintained server from an individual GitHub account active for three months. The orchestration layer enforces the allowlist; the agent never sees servers outside it.

Identity propagation and audit. Every MCP tool call carries the identity of the human user who initiated it, with the audit trail living in the orchestration layer's environment rather than in the MCP server's. The "right to be forgotten" under GDPR, the audit obligations under DORA, and the traceability requirements under the EU AI Act all rely on this being deterministic.

Scope minimisation. Each MCP server gets exactly the tool scope and data scope its specific role requires. Agents reaching for a tool see only the tools they are authorised to use in that context. This is the same principle as least-privilege in classical identity management, applied to tool calls.

Capability decomposition against the lethal trifecta. No single agent in the system simultaneously holds an MCP server that reads private data, an MCP server that ingests untrusted content, and an MCP server that can externally communicate. The orchestration layer composes execution paths that respect that separation.

Jurisdictional routing. When an agent needs a capability, the orchestration layer routes to MCP servers in the appropriate jurisdiction. EU-resident workloads call EU-hosted MCP servers; the option to call non-EU MCP servers is a deliberate policy decision logged in the audit trail, not an accidental data flow.

Where neuland.ai stands

This is, structurally, what the neuland.ai HUB is built to do for MCP and for the broader execution-surface landscape it sits within. The HUB is hyperscaler-independent and deployable on-premises or in EU-located private cloud. It sits above heterogeneous execution surfaces — MCP servers (first-party and approved third-party), CLI and shell execution modules, controlled code-execution sandboxes, browser automation surfaces, workflow fabrics like n8n, and direct enterprise connectors — applying identity, RBAC, audit, policy and capability abstraction uniformly across all of them. Tool-call metadata is enforced; capability decomposition is automatic rather than optional; jurisdictional routing is a policy parameter rather than an architectural accident. [¹⁴]

The point I want to be precise about, because I made a closely related argument in February: MCP-as-adapter remains the right design. [¹⁵] What has changed since February is the scale and the position the protocol now occupies in the agentic AI market. Adopting MCP through a governance layer that also governs the other execution surfaces is good architecture. Adopting MCP directly into the enterprise without that governance layer above it is the same mistake as connecting laptops to the corporate network without an identity provider — and it will be remembered the same way.

Personal take

The Linux Foundation governance step is good for the industry. MCP becoming a vendor-neutral standard removes one of the structural barriers that had kept serious enterprise procurement teams in a holding pattern through 2024 and most of 2025. That is a win, and it should be acknowledged as one.

What it is not, and was never going to be, is a substitute for the enterprise governance layer that sits above the protocol. The 2026 MCP roadmap is, in effect, the project's own public acknowledgement of this — the Enterprise Readiness items are real work being done in the open, but they are not done yet, and most of them will land as extensions rather than core changes. The honest read of that, from an enterprise architect's seat, is: the protocol stabilised faster than the governance around it. The next twelve months are the gap between those two states. Organisations that use the gap to build the management layer above the protocol will be production-ready for the second wave of agentic deployment. Organisations that treat MCP as plug-and-play infrastructure will spend 2027 retrofitting compliance onto integrations that were never designed for it.

A brief note on the regulatory backdrop, since I have written about it in the previous two pieces and the situation has continued to develop. On 7 May 2026, the EU's Digital Omnibus on AI agreement postponed the high-risk Annex III obligations to 2 December 2027 and Annex I obligations to 2 August 2028. [¹⁶] GPAI enforcement powers under Chapter V remain on the original 2 August 2026 schedule. The strategic implication is unchanged: regulatory deadline pressure has weakened slightly, buyer scrutiny has intensified, and the organisations doing the architectural work now will be the ones still winning enterprise procurement decisions in 2028.

The protocol won. The governance is still up for grabs. That is the work in front of us.

¹ Series articles at neuland.ai/insights. Previous pieces: "Control Panels, Execution Surfaces…" (Feb 2026); "Wenn KI-Systeme plötzlich schlechter werden" (Apr 2026); "Open weights took the top spot. Meta walked away." (Apr/May 2026); "Compliance is a system property, not a checkbox" (May 2026); "The lethal trifecta is not a vulnerability. It is a property of the system." (May 2026).

² The N×M integration problem and its formalisation; see WorkOS, "Everything your team needs to know about MCP in 2026," March 2026; Decode The Future, "What Is MCP? Model Context Protocol Explained for 2026," March 2026. For the broader framing of MCP as one execution surface among several (alongside CLI/shell, code execution, browser automation, workflow fabrics like n8n, and bespoke connectors), see Section 3 of "Control Panels, Execution Surfaces…" (neuland.ai, February 2026).

³ MCP introduced November 2024 by Anthropic, engineered by David Soria Parra and Justin Spahr-Summers. Current canonical specification version: 2025-11-25. Wire format: JSON-RPC 2.0. Primary transport: Streamable HTTP. Official SDKs: Python, TypeScript, C#, Java, Swift; third-party SDKs in Rust and Go.

⁴ MCP monthly SDK download figures: ~2 million at launch (November 2024), 97 million by March 2026. Kubernetes comparison cited in industry coverage of the Linux Foundation governance transition; see ai2.work, "Model Context Protocol Hits 97M Installs as Linux Foundation Takes Over," April 2026.

⁵ Anthropic donation of MCP to the Agentic AI Foundation (AAIF), 9 December 2025. AAIF is a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI. See GitHub Blog, "MCP joins the Linux Foundation," December 2025; Linux Foundation press materials, December 2025.

⁶ Epinium research, Q1 2026: 1,800+ active MCP servers on the public internet with no authentication layer. Authentication in MCP specification is optional, not required. See Epinium, "MCP Enterprise Security and Governance," 2026.

⁷ Trend Micro: 102 MCP-specific CVEs catalogued as of April 2026. See Pomerium, "MCP Server Security Risks: What Development Teams Need to Know in 2026," April 2026.

⁸ OpenSSF AI/ML Security Working Group, SAFE-MCP catalogue: 80+ attack techniques specifically targeting tool-based LLM systems via MCP, including prompt injection, confused-deputy attacks, context-integrity failures and rug-pull attacks. OWASP GenAI Security Project, "A Practical Guide for Securely Using Third-Party MCP Servers," November 2025.

⁹ Atlassian, "MCP Clients: Understanding the potential security risks," June 2025. Documents prompt injection, malicious server instructions, rug-pull/tool-redefinition, and naming-collision/impersonation attacks against enterprise MCP deployments.

¹⁰ See footnote 1 and the lethal trifecta piece, May 2026. Supply-chain figures: 12% of OpenClaw ClawHub skills flagged as malicious (Zscaler ThreatLabz, May 2026); 8,000+ open MCP servers and 175,000+ exposed Ollama instances identified by Bishop Fox's AIMap tool (released 30 April 2026); 40,000+ exposed OpenClaw instances identified by SecurityScorecard, default configuration stores credentials in plain-text local files.

¹¹ Model Context Protocol 2026 Roadmap, published 5 March 2026 by David Soria Parra (Lead Maintainer). Four strategic priority areas: (1) Transport Evolution and Scalability, (2) Agent Communication primitives, (3) Governance Maturation, (4) Enterprise Readiness. Enterprise Readiness items: audit trails, SSO-integrated auth, gateway/proxy patterns, configuration portability. Roadmap notes: "an Enterprise WG does not yet exist… most of the enterprise readiness work to land as extensions rather than core spec changes." See blog.modelcontextprotocol.io.

¹² For the underlying compliance argument — CLOUD Act exposure, Schrems II case law, EU Data Boundary scope limitations, EDPS reprimand of the European Commission's own M365 use — see the previous piece in this series, "Compliance is a system property," May 2026. Microsoft's published documentation explicitly excludes Bing web search and Anthropic-model traffic in Microsoft 365 Copilot from EU Data Boundary commitments.

¹³ See footnote 1; "Compliance is a system property, not a checkbox," May 2026.

¹⁴ neuland.ai HUB capabilities referenced: identity / RBAC / audit trail / tool-call governance / capability abstraction / Multi-LLM routing / hyperscaler-independent deployment (on-premises, EU private cloud, hyperscaler region as required) / MCP server allowlisting and jurisdictional routing. neuland.ai AG retains responsibility for content quality and clean delivery of results.

¹⁵ See "Control Panels, Execution Surfaces und das Ende der Prompt-First-Automatisierung," neuland.ai, 19 February 2026. The piece took two positions worth restating here. First: MCP is best understood as an adapter pattern within a control plane architecture, not as a foundation in its own right — and rejecting MCP long-term would be strategically naive because ecosystems and interop win. Second: MCP's recurring failure mode at scale is that it can inadvertently encourage LLM-centric data processing — verbose tool outputs fed back into the model, filtering and transformation done by the LLM rather than by deterministic preprocessing, context entropy increasing with every added capability. The architectural counter-pattern is "always reduce before reasoning" — execute, deterministically shape the output, then let the model plan the next step. Both positions hold in May 2026; what has changed is the scale at which MCP is deployed and the resulting governance gap the current piece addresses.

¹⁶ Council of the EU and European Parliament provisional political agreement on the Digital Omnibus on AI, 7 May 2026. Annex III high-risk obligations postponed from 2 August 2026 to 2 December 2027 (16-month delay); Annex I obligations postponed to 2 August 2028 (12-month delay); Article 50(2) watermarking moved to 2 December 2026; new prohibition on AI-generated non-consensual intimate imagery and CSAM. GPAI enforcement powers under Chapter V remain on the original schedule (2 August 2026). Formal adoption expected before that date.