The Model Context Protocol is an open standard that defines how AI agents connect to external tools, data sources, and systems. It gives any MCP-compatible client — Claude, ChatGPT, Copilot, Cursor — a standard way to discover and call tools without writing a custom connector for each one.
Anthropic released the first version in November 2024. OpenAI adopted it in March 2025. Google DeepMind signaled support. Toolmakers built it in. The Linux Foundation now hosts it as an open standard. In under six months, MCP went from a niche developer spec to the default way organizations connect AI agents to their stacks.
That velocity reflects genuine demand. Developers were tired of writing bespoke integrations for every system. The N×M problem — where N agents each need custom connections to M systems — was getting expensive and unmanageable. MCP proposes to solve it with a standard interface.
The USB-C analogy. USB-C standardized the connector, not what flows through it. MCP standardizes the interface, not the security, governance, or reliability of what runs on top of it. That distinction matters enormously for enterprise deployment.
How MCP works
MCP has three core primitives:
Tools
Functions an agent calls to take action — querying a database, creating a ticket, sending a message.
Resources
Data exposed for reading — files, documents, and structured records from connected systems.
Prompts
Reusable templates that shape how the model approaches a task or series of tasks.
The architecture is client-server. An AI application acts as the MCP client. MCP servers sit alongside the tools and data sources you want to expose. When the client needs to act on an external system, it asks the server, which handles the interaction using a standard interface both sides understand.
Any MCP-compatible client can work with any MCP-compatible server without custom integration work. That is genuinely useful for prototyping. A developer building an agent in Cursor can connect to Slack, GitHub, and a database by pointing at three MCP servers, without writing custom API connectors for each.
Where MCP falls short for enterprise production
If you’re running experiments in a local development environment, MCP works well today. If you’re deploying agents that touch production systems at enterprise scale, you’ll hit real gaps quickly.
MCP servers tested had critical vulnerabilities
Queen's University, 1,000 serversexploit success rate using just 10 unmanaged MCP servers together
Enkrypt.ai researchof enterprise MCP deployments will face cybersecurity incidents by 2027
GartnerAuthentication and access control were an afterthought
MCP’s early design was influenced by the Language Server Protocol, a local-first pattern built for IDE plugins running on a single developer’s machine. When you’re connecting an agent to a local filesystem, that’s fine. When you’re connecting it to Salesforce, ServiceNow, or a financial database on behalf of hundreds of users, you need identity, RBAC, and credential management that MCP’s spec doesn’t natively provide.
A newer authorization model has been added to the spec. But client and server support for it is still uneven, and the implementation is changing quickly. Enterprises that need stability cannot build on a foundation that is still being figured out.
Security vulnerabilities are documented and compounding
The three conditions that compound risk are access to PII, exposure to untrusted content, and external communication capability. When all three are present in the same MCP deployment, the risk profile changes significantly. Most organizations do not realize how many of their MCP servers already meet all three conditions.
We've covered how those conditions interact — and what to do about them — in detail in Defusing the MCP ticking time bomb.
Governance is absent from the spec
MCP describes how clients and servers exchange resources and tools. It does not define who gets to act, when they can act, or under what conditions. For IT teams, that’s a non-starter as soon as agents start touching systems of record. There is no standard way to monitor activity, enforce access policies, or see who is using what. Audit trails, if they exist at all, depend entirely on whatever the server implementation decides to record.
Server quality varies dramatically
The MCP ecosystem has grown fast. Thousands of servers now exist. Some are well-built, maintained, and reliable. Others are hobby projects with no SLAs, no support, and no clear ownership. For a proof of concept, that is fine. For production automation touching your CRM or ERP, it is not.
Token costs scale invisibly
Every tool definition loaded into an agent’s context window consumes tokens before the model has started working. The GitHub MCP server exposes 93 tools and consumes approximately 55,000 tokens just to be registered. Notion’s MCP server runs to around 8,000 tokens. Filesystem MCP adds another 4,000. At an average of 500 tokens per tool definition, running 10 MCP servers with 15 tools each consumes 75,000 tokens before a single business task begins.
Loading too many tools also degrades model performance. An LLM presented with hundreds of tool options has more to reason over, which increases latency and the probability of selecting the wrong tool.
Enterprise readiness at a glance
| Requirement | MCP today | What enterprises need |
|---|---|---|
| Authentication | Auth model exists but unevenly supported | RBAC, SSO, corporate identity enforcement |
| Audit trails | Not mandated — server-dependent | Full logs: caller, tool, input, outcome |
| Access policy | Not in spec | Per-agent, per-tool permission boundaries |
| Observability | None built in | Dashboards, alerting, error detection |
| Spec stability | Evolving rapidly | Versioned, stable contracts for production |
| Token management | No native scope control | Composite tools, deliberate scope limits |
What enterprise MCP deployment actually requires
The gap between “MCP works” and “MCP is production-ready at enterprise scale” mirrors the gap REST faced when enterprises needed API management. The interface was useful. But large organizations still needed a layer for identity, policy, visibility, and security.
Five properties separate MCP deployments built to last from those that are not:
Security you can verify, not assume
Scoped access over inherited permissions. An approved tool registry rather than open server proliferation. Centralized visibility into every tool call, by whom, with what inputs, and what happened.
Predictable execution, not best-effort inference
Raw MCP tools expose individual API operations and leave the agent to figure out the right sequence. Composite tools encode business logic directly, so the model decides what to do and the tool handles how to do it reliably.
Token costs that stay predictable as you scale
Deliberate scope control, composite tool design, and monitoring of token consumption per tool and agent. Gartner recommends starting with 5–15 focused tools for single-domain servers.
Auditability that satisfies more than your own curiosity
A complete audit trail captures the identity that initiated the request, the original prompt, a session ID, the tool name and version, all parameters passed, the outcome returned, and timestamps precise enough for incident reconstruction.
A governance model that IT can actually maintain
A governed registry for discovery of approved servers. A gateway architecture that centralizes authentication, authorization, policy enforcement, and observability. Without that layer, you are not managing a tool catalog — you are managing MCP sprawl.
What good looks like in practice
J.W. Pepper, the music publisher, went through this journey and built a template other enterprise teams can follow.
MCP adoption at J.W. Pepper started the way it starts at most organizations: teams outside IT were moving faster than IT was, experimenting with agents and MCP tools before formal guardrails were in place. That pattern has a name, and a familiar trajectory. Marcus Dubreuil, Director of Systems Architecture, described the access control problem clearly:
“One of the challenges with how MCP works that I learned really quickly is that it effectively forwards any access control that the user has to the AI agent. You’re effectively saying, ‘you’re me now.’”
— Marcus Dubreuil, Director of Systems Architecture, J.W. Pepper
Rather than exposing hundreds of raw tools to agents, the team shifted to purpose-built workflows representing specific business actions — looking up an order, updating a ticket, sending a notification. They centralized MCP servers and tools using Tray Agent Gateway, giving IT control over which tools were available, how they were exposed, and under what conditions they could be used.
“Instead of us trying to build this whole robust all-in-one iPaaS solution, we’re just adding these little drops of determinism into what the agent can do.”
— Marcus Dubreuil, Director of Systems Architecture, J.W. Pepper
IT’s role shifted in the process. “We’re becoming more of a service org again,” Dubreuil said, “helping people empower their use of AI instead of being fearful of it.”
What to do now
-
Use MCP where it adds value. For internal tools, development environments, and proof-of-concept agents, MCP delivers real value today. Move fast. Learn what agents can do.
-
Do not deploy MCP servers to production without a governance layer. Production agents touching systems of record need identity tied to corporate directory, RBAC that is auditable, credential management, and logging that meets your audit requirements. Add that layer before agents go anywhere near production.
-
Inventory what you have. Most organizations with active developer teams already have MCP servers running. Know what is deployed, what it can access, and who owns it.
-
Treat tool definitions like schemas. They require review, versioning, and maintenance as they evolve. The teams that manage this deliberately end up with more reliable agents and lower token costs.
FAQ
What is the Model Context Protocol (MCP)? A communication protocol that allows AI agents and LLM-based applications to discover and interact with external tools and services in a standardized way.
Is MCP ready for enterprise use? MCP is ready for development environments and proofs of concept. For production deployments touching systems of record, it requires a governance layer — centralized authentication, RBAC, audit trails, and tool registries — that the protocol itself does not provide.
What are the biggest security risks with MCP? The three conditions that compound risk most are: access to PII, exposure to untrusted content (enabling prompt injection), and external communication capability. When all three are present, the risk profile changes significantly. A Queen’s University study of 1,000 MCP servers found 33% had critical vulnerabilities.
How does Tray.ai help with MCP governance? Agent Gateway for MCP provides a centralized control layer for organizations deploying MCP at scale — handling authentication, access policy, observability, and tool registry management so IT teams can govern what agents can do without slowing down the teams building with them.
What integration platforms support MCP for AI agents? Enterprise integration platforms are beginning to add MCP support, but most provide raw protocol connectivity without governance controls. Tray.ai’s Agent Gateway for MCP adds the authentication, RBAC, and audit layer that enterprises require before connecting AI agents to systems of record via MCP.
How do I connect AI models to enterprise systems using MCP? Connecting AI models to enterprise systems via MCP requires three layers: an MCP server that exposes your tools and data, a client in your AI agent that calls those tools, and a governance layer that controls authentication and access. For production use, platforms like Tray.ai’s Agent Gateway manage the governance layer so AI agents can interact with CRMs, ERPs, and other systems of record without exposing them directly.
More in this series:
- Defusing the MCP ticking time bomb — The compounding risk conditions already building in enterprise MCP deployments, and the three actions to take now.
- Shadow MCP is the new shadow IT — How ungoverned MCP servers create the same risks enterprises spent a decade eliminating.
- Why MCP execution fails — and how to fix it — The determinism problem, and why composite workflow tools are the architectural response.
Go deeper
Getting MCP Right: The Five Properties Every Enterprise Deployment Needs
The framework for evaluating where your current MCP deployment stands — and where the gaps are. Security, execution, token costs, auditability, and governance.
Read the ebook →