MCP: The Quiet Standard That's Finally Making AI Agents Useful

If you've spent any time around enterprise AI agents in the past year, you've probably watched a familiar pattern repeat. Someone builds a Claude or GPT agent that needs to read from Confluence, query Jira, and update a record in Dynamics. They write three custom integrations. Six weeks later another team wants the same agent connected to SharePoint, ServiceNow, and Salesforce. They write three more.

This is the problem the Model Context Protocol was designed to solve. Anthropic open-sourced MCP in late 2024, and by mid-2026 it's the default way enterprise AI agents connect to the systems they need to work against.

What MCP actually is

MCP is an open protocol — not a product. It defines a standard way for an AI client (Claude Desktop, an IDE, a custom agent, a Copilot extension) to discover and call tools, resources, and prompts exposed by an MCP server.

The server side is whatever you want it to be. A wrapper around your Jira API. A SQL-aware connector for your warehouse. A read-only view of your wiki. A controlled writer to your CRM. You build the server once. Every MCP-aware client can use it.

The point of the separation is leverage. The AI model doesn't need to know anything about your specific systems, and your systems don't need to know anything about AI. MCP sits in between and handles the negotiation.

Why this matters in 2026

Before MCP, every team building AI agents was reinventing the same integration patterns badly. Custom tool definitions for each model provider. Bespoke auth handling. No discoverability — the agent only knew about the tools you'd hardcoded. No standardised way to pass back results, errors, or progress updates.

MCP fixed all of this. A single connector built once works across Claude, IDE assistants, and increasingly across other agent platforms that have added MCP support. For enterprises, this is the difference between "we built one AI integration per system" and "we built one connector and now everything can use it."

The patterns I'm seeing work

1. The shared internal MCP server

The most common pattern in enterprises that are doing this well: one platform team builds a small set of MCP servers for the core systems — the CRM, the ticketing system, the knowledge base, the data warehouse. These are deployed centrally with proper auth and scoped permissions.

Other teams then point their AI agents at these servers rather than building their own integrations. The platform team handles versioning, rate limits, observability, and security. The application teams focus on the agent logic.

2. Read-mostly with surgical write paths

The MCP servers that go well in enterprise are aggressively read-biased. Agents can search, query, and summarise freely. The write operations are narrow, well-defined, and often require confirmation. "Create a draft Jira ticket with these fields" is much safer than "do whatever you need to in Jira."

This isn't an MCP limitation — the protocol supports any tool you want to expose. It's a discipline. The teams that expose broad write APIs to agents are the ones that end up rolling them back after the first incident.

3. Per-user auth, not service accounts

Early MCP deployments often used a shared service account for the server's access to backend systems. This caused two problems: every agent could see everything regardless of the user's actual permissions, and audit logs lost the user identity at the MCP boundary.

The mature pattern is per-user auth, usually OAuth-based, where the MCP server acts on behalf of the calling user and the backend system enforces normal access controls. This is more work to set up but it's the only model that survives a security review.

Building your own MCP server

The SDKs are good. There are official Python and TypeScript implementations from Anthropic, and community implementations for most other major languages. A simple read-only MCP server wrapping a REST API can be built in a few hundred lines of code.

What I'd start with:

• Pick a single high-value system — the one your AI agents most often need to reach into. Usually the knowledge base or the ticketing system.
• Build read tools first — search, lookup, list. Get the agent reliably finding the right information before you give it any write capability.
• Add narrow write tools second — "create draft", "add comment", "update status to X". Each one explicit, each one auditable.
• Instrument heavily — log every tool call with the user, the inputs, and the result. This is your safety net and your debugging tool both.

What to watch out for

MCP is a young protocol and a few rough edges are worth knowing.

Tool description quality matters enormously. The agent decides which tool to call based on the description you provide. Vague or overlapping descriptions cause the agent to pick the wrong one. Treat tool descriptions like API documentation that the model is going to read.

Latency adds up. Every MCP tool call is a round trip. An agent making ten tool calls in a single interaction is making ten network hops. Design tools that do meaningful work in one call rather than tools that the agent has to chain together.

Permissions are your responsibility. MCP itself doesn't have an opinion about who can call what. If you expose a write tool, anyone who can talk to the server can call it. Build the auth layer at the server boundary, not in the agent.

Where this is going

By the end of 2026 I'd expect most enterprise AI platforms to either speak MCP natively or have a compatibility layer. Microsoft has signalled support, and several agent platforms have added MCP client capabilities. My bet: if you're building integrations for AI agents today and you're not using MCP, you'll be migrating to it within a year.

The payoff for adopting early is the same as with any standard. Build your connectors once, and they'll work with whatever model and whatever client you end up using.

If you're thinking about how MCP fits into your AI architecture, or which systems to wrap first, get in touch.