MCP One Year In — What's Working, What Isn't

A bit over a year since Model Context Protocol was published as an attempt at standardising how AI applications connect to tools, resources, and data. In our delivery work across the Gulf region and North America since then, MCP has shown up in most serious AI architecture conversations. It is no longer a curiosity. It also hasn't transformed enterprise integration the way some of the early framings suggested it would.

This is a reflection on what's worked, what's disappointed, and where MCP sits as we head deeper into 2026.

What's worked

The connector multiplier effect

The clearest win. Where vendor MCP servers exist for systems we used to integrate by hand — SharePoint, Confluence, ServiceNow, several core banking systems — the integration time has dropped meaningfully. What used to take weeks of bespoke work for each AI initiative now takes days of configuration on top of a shared MCP server.

This is the value an integration standard is supposed to provide. The economics have started to show.

Internal MCP servers

Several of the enterprises and government bodies we work with have built internal MCP servers exposing their own systems. The pattern is: build it once, expose it as MCP, multiple AI workloads consume it.

The leverage compounds. The first workload pays for the server; subsequent workloads inherit it for free.

A shared vocabulary

Even where MCP isn't the deployed standard, the conceptual model — clients, servers, tools, resources, prompts — has become a shared vocabulary. Conversations about AI integration architecture happen in MCP-shaped terms even when the protocol isn't being used.

The Claude desktop and developer surfaces

Anthropic's own products and several developer tools use MCP heavily. The ecosystem effect — being part of a larger ecosystem, not a standalone integration — is real for teams building inside that ecosystem.

What's disappointed

Adoption breadth

Not every major vendor has shipped MCP servers. The ecosystem is real but uneven. For some systems we still build bespoke integrations because the MCP option doesn't exist.

Cross-ecosystem support

While Anthropic drove the standard, other major model providers have been slower to adopt it natively. Bridges and adapters exist; first-class support is uneven. The hope of a single standard that works equally well across providers hasn't fully materialised.

Authentication and authorisation

MCP doesn't standardise auth. Each server handles it. The result is an authentication and authorisation surface that requires per-server reasoning, which is exactly what enterprises hoped a standard would let them stop doing.

Discoverability

A standard for connecting clients to servers requires the clients to know which servers to connect to. The discovery layer is informal — registries, documentation, community lists. The enterprise version of this hasn't fully emerged.

Sophistication of available servers

Many MCP servers we encounter are wrappers around APIs, not sophisticated integrations. They expose the underlying system's capabilities but not domain-specific helpers, common patterns, or curated views. The semantic layer is still per-deployment.

What we've changed because of MCP

In the engagements I've led this past year, MCP has affected our patterns in specific ways:

We build MCP-first for new integration work

When we need to connect AI workloads to a system, we build an MCP server. The marginal cost is small. The option value — being able to use that integration from multiple AI clients — is real.

We evaluate vendor MCP support in procurement

When a vendor offers an MCP server, we factor that into procurement. The integration cost saving is material.

We've rewritten some custom integrations

For high-leverage internal integrations, we've moved some bespoke work to MCP servers. The investment paid back as additional AI workloads adopted the same servers.

We treat MCP as one option, not the answer

For some workloads, direct integration is still appropriate — when the workload is unique, when the MCP overhead doesn't justify itself, when the underlying system has constraints that MCP doesn't accommodate well. The standard is useful; it isn't universal.

Where I see MCP heading

In 2026, my expectations:

Continued vendor adoption

More vendors will ship MCP servers. The economic argument — your enterprise customers want this — is real and growing.

Enterprise registries

Internal MCP server registries will become more common. Discovering what MCP capabilities exist inside the organisation is currently informal; that won't last.

Authentication standardisation

The auth gap will start to close. Either MCP itself will specify more, or surrounding patterns (federated auth, OAuth flows) will become standard practice.

Cross-provider parity

Other model providers will reach better native MCP support. The single-standard hope may not fully materialise but the major providers will all support it acceptably.

Domain-specific extensions

MCP for specific domains — financial services MCP servers with sector-specific patterns; healthcare MCP servers with HIPAA-aware patterns. The standard becomes the substrate for sector-specific tooling.

What hasn't changed and won't

A few things MCP doesn't solve and won't:

Integration architecture is still architecture

A protocol doesn't make integration easy. The architectural decisions — what to expose, how to model the domain, how to manage state — remain hard.

Governance is still required

MCP servers expose capability. Capability without governance is exposure. The governance discipline applies to MCP-mediated integrations as it does to any other.

The semantic layer is still per-deployment

How your business entities relate, what your specific terminology means, what your domain rules are — MCP doesn't standardise this. It can't. Each deployment has to do this work.

Vendor responsibility doesn't transfer

If a vendor ships a buggy MCP server, you're depending on a buggy vendor server. Vendor governance still matters; the standard doesn't replace it.

My recommendation a year in

A year ago we recommended tracking the standard, building MCP-aware for new work, and avoiding wholesale rewrites. That recommendation has aged well. Updated for 2026:

1. MCP is now the default consideration for new AI integration work. The standard has earned that.
2. For new internal integrations, build MCP servers. The leverage is real.
3. Continue to use direct integration where MCP doesn't fit. The standard is a tool, not a religion.
4. Engage your vendor relationships on MCP support. The economic argument from your side will accelerate vendor adoption.
5. Build the internal discovery and governance for MCP. The standard helps with the protocol; you still need to manage your own surface.
6. Don't expect MCP to solve architecture, governance, or domain modelling. Those remain your work.

MCP a year in is doing what a useful standard does — reducing the routine integration work, letting teams focus on the harder problems above the protocol layer. It hasn't transformed enterprise AI; few things do. But it has made the work meaningfully easier in specific ways. The teams that engaged with it early are getting the value. The teams that ignored it are doing more bespoke integration than they need to. Either choice is defensible; the first is now clearly the better one.