AI integration becomes enterprise-ready: The Model Context Protocol under the Linux Foundation

6 min read

When Anthropic unveiled the Model Context Protocol (MCP) in late 2024, it offered a clever way to connect language models to tools and data. Eighteen months later, MCP sits under the Linux Foundation umbrella, carries an Apache 2.0 license, and follows a predictable release schedule. What began as a single-vendor protocol has become a vendor-neutral foundation-exactly the kind of stability enterprise IT needs to take it seriously.

Key Takeaways

• Governance over solo runs: MCP is now a Linux Foundation project under Apache 2.0, removing its fate from any single vendor’s hands.
• Predictable lifecycle: The stable specification was published on 25 November 2025; the next version is already a Release Candidate dated 28 July 2026. Deprecations now come with at least a twelve-month grace window.
• Broad backing: Nine official SDKs, an official server registry, and pledged support from OpenAI and Google give companies the reach they require.

Related:AWS retires its agent framework-here’s the catch  /  Cursor Cloud Agents in the wild

From Anthropic protocol to Linux Foundation stewardship

The most important milestone of the past months is not technical but organizational. MCP has been transitioned into a Linux Foundation project, contributions licensed under Apache 2.0. For a protocol that governs how AI models connect to enterprise data, this shift is the real test of maturity. Any team building an integration wants assurance that a single vendor won’t rewrite the rules overnight.

Maintainers remain close to real-world use. Lead Maintainer David Soria Parra of Anthropic is joined by Den Delimarsky, who hails from Microsoft’s ecosystem. The C# SDK and .NET bindings still carry Microsoft fingerprints, while OpenAI and Google have publicly pledged support for their agent platforms. When the three largest model providers speak the same interface, it becomes the de-facto standard.

For enterprise IT, one word matters at this juncture: vendor independence. An openly licensed specification under neutral stewardship can be baked into architectural decisions without fear that a vendor’s licensing or strategic shift will upend the entire foundation.

What enterprise readiness actually means in practice

Maturity isn’t measured by feature count; it’s about how predictable a protocol remains over time. That’s exactly where MCP has delivered lately. The stable specification dated 25 November 2025 is the foundation teams are building on today. The next version has been available as a release candidate since late May, scheduled for 28 July 2026.

New and critical is the introduced lifecycle. Features move through clearly labeled states-active, deprecated, removed. A deprecated feature stays available for at least twelve months. For production integration, that’s the difference between calm planning and frantic catch-up with every update.

Language coverage is another plus. Nine official SDKs cover Python, TypeScript, Java, Kotlin, C#, Go, Rust, Swift and Ruby. An enterprise stack nearly always finds a supported connector without resorting to community-built workarounds.

The registry and the trust problem

With maturity comes a new challenge. Since 8 September 2025 an official MCP registry has been in preview, and the API was frozen at v0.1 on 24 October. Its role is to become what language package registries are: the central place where you discover and embed servers.

But MCP inherits the core problem of those registries. A registry full of servers that connect models to real systems is an attractive target. Plugging in a tampered server opens the door to data and actions for any language model. Recent supply-chain attacks in the npm ecosystem show where that leads. MCP servers deserve the same scrutiny.

No coincidence that security-focused companies sit on the registry working group. Deciding whom your organisation trusts in the registry isn’t a side issue-it sits at the heart of every MCP rollout.

What IT teams should evaluate now

MCP has reached the point where serious assessment is worthwhile. Four questions guide the decision.

1. Curate servers. Not every registry entry belongs in production. Build your own vetted, approved list instead of granting open access to everything.
2. Plan for deprecation. The twelve-month lifecycle invites scheduling migrations in advance. Monitoring states keeps you from being blindsided by any update.
3. Clarify registry trust. Document origin, maintenance and permissions for every embedded server. A server with far-reaching rights deserves the same checks as a new code dependency.
4. Choose an SDK. Your stack’s language dictates the SDK. An officially maintained connector beats a custom build because it automatically follows the lifecycle.

DIY setup vs. enterprise-grade deployment

The leap made over the past year and a half can be pinned down to a handful of points.

What this means in practice

MCP has made the jump from an interesting experiment to a predictable foundation. The neutral stewardship removes the biggest objection sceptics raise, while the lifecycle makes integrations maintainable. That turns the protocol into an option architecture boards can seriously weigh up.

The rest is craftsmanship. Anyone building with MCP today gains the most by treating the registry with the same caution they would any other supply chain. The protocol’s maturity doesn’t shift responsibility; it simply makes it predictable. That’s the moment when a trend becomes an infrastructure decision.

Frequently Asked Questions

Source of title image: AI-generated (July 2026)

Image source: AI-generated (July 2026)