If you've spent time around enterprise AI agents in the past year, you've probably seen this pattern. Someone builds a Claude or GPT agent that needs to read from Confluence, query Jira and update a record in Dynamics, so they write three custom integrations. Six weeks later another team wants the same agent connected to SharePoint, ServiceNow and Salesforce. They write three more.
The Model Context Protocol was designed to stop that. Anthropic open-sourced MCP in late 2024, and by mid-2026 it's the default way enterprise AI agents connect to the systems they work with.
What MCP is
MCP is an open protocol, not a product. It sets out a standard way for an AI client (Claude Desktop, an IDE, a custom agent, a Copilot extension) to discover and call the tools, resources and prompts that an MCP server exposes.
The server can be whatever you need. A wrapper around your Jira API, a connector that knows SQL for your warehouse, a read-only view of your wiki, a controlled writer to your CRM. You build it once and every MCP-aware client can use it.
The separation is what makes it worthwhile. The model doesn't need to know anything about your systems, and your systems don't need to know anything about AI. MCP sits in the middle.
Why it matters now
Before MCP, every team building agents was reinventing the same integration patterns, badly. Custom tool definitions for each model provider, hand-rolled auth, no discovery (the agent only knew about tools you'd hard-coded), and no standard way to return results, errors or progress.
MCP sorted that out. A connector built once works with Claude, with IDE assistants and with a growing number of agent platforms that have added MCP support. For a large organisation, that's the difference between one AI integration per system and one connector that everything can use.
Patterns that are working
1. A shared internal MCP server
This is the most common pattern among enterprises doing it 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. They're deployed centrally with proper auth and scoped permissions.
Other teams point their agents at those servers instead of building their own integrations. The platform team looks after versioning, rate limits, observability and security, and application teams get to concentrate on agent logic.
2. Mostly read, with narrow write paths
The MCP servers that go well are heavily biased towards reading. Agents can search, query and summarise freely. Writes are narrow, clearly defined and often need confirmation. "Create a draft Jira ticket with these fields" is far safer than "do whatever you need to in Jira".
The protocol will happily expose any tool you like, so this is a matter of discipline. Teams that give agents broad write APIs tend to roll them back after the first incident.
3. Per-user auth instead of service accounts
Early MCP deployments often gave the server a shared service account for the backend systems. That caused two problems. Every agent could see everything, whatever the user's real permissions were, and audit logs lost the user's identity at the MCP boundary.
The mature pattern is per-user auth, usually via OAuth, where the server acts on behalf of the calling user and the backend enforces its normal access controls. It takes more work to set up, but it's the only model I've seen survive a security review.
Building your own MCP server
The SDKs are good. Anthropic maintains official Python and TypeScript implementations, and there are community ones for most other major languages. A simple read-only server wrapping a REST API is a few hundred lines of code.
I'd start with one high-value system, the one your agents most often need to reach into. That's usually the knowledge base or the ticketing system.
Build the read tools first: search, lookup and list. Get the agent reliably finding the right information before it can change anything. Then add narrow write tools such as "create draft", "add comment" or "set status to X", each one explicit and auditable.
Log every tool call with the user, the inputs and the result. That log is your safety net and your main debugging tool.
Rough edges
MCP is a young protocol and a few things are worth knowing.
Tool descriptions matter more than you'd think. The agent picks a tool based on the description you wrote, and vague or overlapping descriptions send it to the wrong one. Write them like API documentation, because the model is going to read them.
Latency adds up. Every tool call is a round trip, so an agent making ten calls in one interaction makes ten network hops. Design tools that do meaningful work in one call instead of tiny ones the agent has to chain together.
Permissions are your job. MCP has no opinion about who may call what. If you expose a write tool, anyone who can reach the server can call it. Put the auth layer at the server boundary, not in the agent.
Where this is heading
By the end of 2026 I expect most enterprise AI platforms to either speak MCP natively or offer a compatibility layer. Microsoft has signalled support and several agent platforms have added MCP clients. My bet is that if you're building agent integrations today without MCP, you'll be migrating to it within a year.
The payoff is the usual one for adopting a standard early. You build your connectors once and they work with whichever model and client you end up on.
Working out how MCP fits your AI architecture, or which system to wrap first? Get in touch and we can talk it through.
