A practical guide to Model Context Protocol (MCP) — what it is, how it works, and how enterprise teams can use it to connect Claude to their internal systems securely.
Every enterprise AI agent eventually hits the same wall. Claude is reasoning well. The prompts are clean. The use case is clear. But the agent can't actually do anything useful because it has no access to your real systems — your CRM, your ERP, your ticketing platform, your data warehouse. Connecting them one by one, with custom integrations for every tool, is slow, fragile, and impossible to scale. That is the problem Model Context Protocol was built to solve.
What is MCP?
Model Context Protocol, or MCP, is an open standard introduced by Anthropic in late 2024 that defines a consistent way for AI systems to connect to external tools and data sources. Think of it as a universal adapter layer between your AI model and your enterprise systems. Instead of building a custom integration every time you want Claude to talk to a new system, you build or install an MCP server for that system once. Any MCP-compatible AI client — including Claude — can then use it. The official MCP specification is now community-maintained at modelcontextprotocol.io, which means it is not locked to Anthropic or Claude. Other AI systems are adopting it too, which makes it a safer long-term investment for enterprise architecture.
The problem MCP solves
Before MCP, connecting an AI agent to enterprise systems looked like this: one custom function for Salesforce, another for ServiceNow, another for your data warehouse, another for SharePoint. Each integration was hand-built, inconsistently documented, and tied to a specific agent or workflow. When you added a new agent, you rebuilt the same connectors. When a system changed its API, integrations broke silently. There was no standard for access control, logging, or permissions across tools. MCP replaces that fragmentation with a single protocol. Build the connector once, use it across every agent that needs it.
How MCP works
MCP has three components: the host, the client, and the server. The host is the application running the AI model — in enterprise contexts, this is typically your agent orchestration layer or platform. The client is the interface inside the host that speaks the MCP protocol. The server is a lightweight process that exposes tools, resources, and prompts from a specific system — your CRM, ERP, or internal database. When Claude needs to retrieve data or take an action, it requests a tool call. Your host sends that request to the relevant MCP server. The MCP server executes it against the real system and returns a structured result. Claude continues its reasoning based on that result. The key point is that Claude never talks directly to your enterprise systems. The MCP server mediates every interaction, which is where you enforce permissions, logging, and security policy.
MCP architecture
Claude (reasoning) → Host / Orchestrator → MCP Client → MCP Server → Enterprise System (CRM / ERP / Ticketing / Database)MCP vs traditional API integration
Both approaches can connect Claude to your systems. The difference is scale and maintainability.
| Dimension | Traditional API integration | MCP |
|---|---|---|
| Setup | Custom per tool | Standardised server |
| Reusability | Tied to one agent or workflow | Shared across all agents |
| Access control | Implemented per integration | Centralised at MCP gateway |
| Logging | Inconsistent | Uniform across all tools |
| Maintenance | Each integration owned separately | Single server to maintain |
| Adoption | High engineering effort | Growing ecosystem of ready-made servers |
For a single agent connecting to one or two systems, a direct API integration is fine. For an enterprise deploying multiple agents across multiple systems, MCP becomes the more practical and governable approach.
What you can connect via MCP
Any system with an API can be wrapped in an MCP server. Common enterprise integrations include:
- CRM — Salesforce, HubSpot, Microsoft Dynamics
- ERP — SAP, Oracle, NetSuite
- Ticketing and ITSM — ServiceNow, Jira, Zendesk
- Collaboration — Slack, Microsoft Teams, email
- Document management — SharePoint, Confluence, Google Drive
- Data warehouse — Snowflake, BigQuery, Redshift
- Identity and access — Okta, Azure AD
- Finance — accounts payable systems, invoice platforms
- HR — Workday, BambooHR
- Internal knowledge bases and policy repositories
Anthropic and the broader community have published a growing library of pre-built MCP servers. For many common systems you will not need to build from scratch — you will configure and secure an existing server.
Setting up an MCP gateway for enterprise
In a production enterprise environment, you should not connect MCP servers directly to your agents without a control layer in between. The recommended pattern is an MCP gateway — a centralised layer that sits between your agent orchestrator and all MCP servers. The gateway handles four things: identity and authentication (which user or agent is making the request), authorisation (is this agent allowed to call this tool with these arguments), logging (a full audit trail of every tool call, argument, and result), and rate limiting (preventing runaway agents from flooding downstream systems). This is the same pattern described in our guide to building enterprise AI agents with Claude — Claude proposes, your system disposes. The MCP gateway is where your system disposes.
Agent Orchestrator
|
MCP Gateway
| - Identity verification
| - Authorisation check
| - Audit logging
| - Rate limiting
|
+--> MCP Server: CRM
+--> MCP Server: ERP
+--> MCP Server: Ticketing
+--> MCP Server: Data Warehouse
+--> MCP Server: Policy RepositoryStart a conversation that leads to progress.
Connect with our team and explore solutions tailored to your needs.
Security considerations
MCP reduces integration complexity, but it also centralises risk. If your MCP gateway is compromised or misconfigured, every connected system is exposed. The key security principles to apply:
- Least privilege — each MCP server should only expose the operations the agent actually needs. A support agent's CRM server should expose read and search, not update or delete.
- Scoped credentials — do not use shared admin credentials. Each MCP server should authenticate with scoped, role-appropriate credentials.
- Read/write separation — expose read tools freely, require approval workflows before any write or execute tool is called.
- Input validation — validate all arguments before passing them to the underlying system. Claude's tool call inputs should be treated as untrusted until validated.
- Prompt injection awareness — retrieved content from MCP servers (documents, tickets, emails) can contain injected instructions. Treat all retrieved content as untrusted data, never as additional instructions.
- Audit everything — every MCP tool call should produce a log entry: timestamp, agent identity, tool name, arguments, result, and downstream action taken.
Example MCP tool definitions
Here is what a small set of enterprise MCP tools looks like in practice.
[
{
"name": "crm.get_account",
"description": "Retrieve account details by account ID. Read-only. Use for support and sales workflows.",
"input_schema": {
"type": "object",
"properties": { "account_id": { "type": "string" } },
"required": ["account_id"]
}
},
{
"name": "erp.get_invoice",
"description": "Retrieve invoice details by invoice number. Read-only. Use for finance reconciliation workflows.",
"input_schema": {
"type": "object",
"properties": { "invoice_number": { "type": "string" } },
"required": ["invoice_number"]
}
},
{
"name": "servicenow.create_ticket",
"description": "Create a new IT service ticket. Requires manager approval before execution.",
"input_schema": {
"type": "object",
"properties": {
"title": { "type": "string" },
"description": { "type": "string" },
"priority": { "type": "string", "enum": ["low", "medium", "high"] },
"requester_id": { "type": "string" }
},
"required": ["title", "description", "priority", "requester_id"]
}
}
]Common mistakes when implementing MCP
- Exposing too many tools — giving agents access to every available MCP server regardless of the workflow. Keep tool sets narrow and task-specific.
- Skipping the gateway — connecting agents directly to MCP servers without a centralised control layer. This makes auditing, permissions, and incident response nearly impossible.
- Using admin credentials — authenticating MCP servers with broad service accounts. Use scoped, minimal credentials.
- No approval layer on write operations — allowing agents to execute write, update, or delete operations without a human approval step.
- Treating MCP as a silver bullet — MCP standardises the connection layer, but it does not replace governance, evaluation, or business process design. Those still need to be built.
Is MCP only for Claude?
No. MCP is an open protocol and is being adopted across the AI ecosystem. Building your enterprise integration layer on MCP means your connectors will work with other MCP-compatible models and tools, not just Claude. This is an important consideration for enterprise architecture teams who want to avoid being locked into a single AI vendor. Your MCP servers are reusable infrastructure, not Claude-specific glue code.
Where MCP fits in the broader enterprise AI stack
MCP sits in the tool layer of your enterprise AI architecture. It is not a replacement for your orchestration platform, your governance framework, or your evaluation suite — it is the connector standard that makes all of those work together more reliably. For enterprises running multiple agents across multiple systems, MCP is the layer that turns a collection of one-off integrations into a governed, reusable, auditable infrastructure. Combined with an automation orchestration platform, it becomes the foundation for scaling AI agents beyond individual pilots into production workflows that the business can actually rely on.
Frequently asked questions
What is Model Context Protocol?
Model Context Protocol (MCP) is an open standard that defines how AI systems connect to external tools and data sources. It replaces one-off API integrations with a consistent protocol, making it easier to build, reuse, and govern AI agent integrations at enterprise scale.
Is MCP open source?
Yes. The MCP specification is community-maintained and open. It is not exclusive to Anthropic or Claude, and multiple AI systems are adopting it.
How is MCP different from LangChain tools?
LangChain tools are framework-specific abstractions built in Python. MCP is a protocol-level standard independent of any framework or language. MCP servers can be consumed by any MCP-compatible client, not just applications built with LangChain.
Do I need to build MCP servers from scratch?
Not always. A growing library of pre-built MCP servers exists for common enterprise systems. You will typically configure and secure an existing server rather than building one from scratch.
Is MCP safe to use in a regulated enterprise environment?
MCP itself is a protocol, not a security product. Safety in regulated environments depends on how you implement it — specifically whether you apply a gateway layer, scoped credentials, audit logging, and approval workflows on write operations.
