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.
Looking for Tray’s MCP products? Agent Gateway governs the MCP servers and tools your agents call. Tray Headless MCP exposes the Tray platform to any MCP-compatible AI IDE. Tray is also listed in the Claude Connectors Directory.
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.
The 2026-07-28 spec hardened authorization and made the protocol core stateless. Those features only work where both the client and the server have upgraded. Tens of thousands of MCP servers still run older versions, so what you can rely on across your estate is whatever your least-updated server supports.
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. Start with 5 to 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? Yes, with a governance layer in front of it. The protocol standardizes how agents discover and call tools. It does not enforce who can act, which systems they can reach, or what gets logged. Production deployments that touch systems of record need centralized authentication, scoped access, audit trails, and an approved tool registry.
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:
- Security risks: Defusing the MCP ticking time bomb
- User identity: Your MCP service works. But can you answer this question?
- Shadow MCP: Shadow MCP is the new shadow IT
- Predictable execution: Drops of determinism: the fix for MCP agents that keep getting it wrong
- Token costs: MCP is making your AI bill unpredictable. Here’s why.
- Observability and audit: Flying blind: Why MCP needs its API management moment
- Governance: MCP governance in the enterprise
- The 2026-07-28 spec: The biggest MCP upgrade yet makes MCP harder to depend on
- IT checklist: Back from Gartner App Summit. Here’s your MCP checklist.
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 →