What MCP Servers Can and Cannot Do for Enterprise AI

Integration complexity, not model quality, is why most enterprise AI pilots never make it to production. MCP (Model Context Protocol) fixes the connection problem: instead of building a custom integration for every AI tool paired with every backend system, teams write one connector per system and one client per AI application. That part works, and it works well. But MCP stops at the wire. Everything that happens after the connection, who's allowed to call what, what gets logged, how permissions carry over, gets left for the enterprise to build on its own. Most teams are treating a wire protocol like a governance platform, and that mistake is going to show up in a compliance audit or a breach report before it shows up anywhere else.

What MCP actually is and how it works at the protocol layer

MCP is an open-source standard for connecting AI applications to outside tools and data. Anthropic released it in November 2024, and it's now overseen by the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, OpenAI, and Block. Major technology companies including Google, Microsoft, AWS, Cloudflare, and Bloomberg joined as platinum members, which tells you something about how fast this went from a single company's idea to shared infrastructure.

Under the hood, MCP runs on JSON-RPC 2.0, a plain messaging format, and supports two ways of connecting: stdio for local setups, and Streamable HTTP for remote ones. Every MCP server can expose three kinds of things: tools (functions the AI can call, like create_issue or query_database), resources (data the AI can read, such as files or API responses), and prompts (ready-made templates for common tasks).

The architecture keeps things separate on purpose. An MCP Host, the AI application itself, runs an MCP Client that connects one-to-one with an MCP Server, which exposes the tools and data. Agent logic lives on one side, integration logic on the other, and the two never have to know much about each other. People often compare it to USB-C: plug any compliant device into any compliant port, no custom wiring required.

Worth separating MCP from function calling, since the two get confused often. Function calling ties an AI app to one model provider's specific API. MCP doesn't care which model you're running, so a server built once can serve Claude, ChatGPT, or Gemini without rework. And MCP isn't a replacement for retrieval-augmented generation (RAG); the two work together. MCP handles governed access to the data, RAG handles picking out the most relevant pieces of it at the moment of a query.

Thoughtworks placed MCP in the "Trial" ring of its Technology Radar: proven enough to test in real projects, but still short of "safe to adopt everywhere." That's the correct ranking, and anyone treating MCP as production-ready out of the box is ahead of where the technology actually is.

How fast MCP has spread and what that adoption actually reflects

The growth curve alone tells a story. SDK downloads went from roughly 100,000 in November 2024 to over 8 million by April 2025. By March 2026, monthly downloads hit 97 million, a nearly thousandfold jump in a year and a half. The public server registry grew from about 1,200 servers in early 2025 to more than 10,000 by March 2026.

Production use hasn't kept pace, and that gap is the whole story here. Stacklok's State of MCP in Software 2026 report put the share of surveyed organizations running MCP in production somewhere around 41 to 45%. A widely circulated 78% figure has since been debunked, and it still shows up in conversation. That alone says something about how eager people are to believe this moved faster than it did.

Every major AI vendor has fallen in line. OpenAI adopted MCP in March 2025. Google DeepMind's Demis Hassabis signaled support that April, with an official announcement following in December 2025. At this point, Claude Desktop, Claude Code, Cursor, ChatGPT, Codex, Gemini and Goose all support the protocol.

Block and Apollo integrated MCP from the start. Bloomberg scaled its internal GenAI platform across more than 9,500 engineers using MCP-standardized infrastructure, probably the clearest enterprise proof point available right now. Gartner expects roughly a third of enterprise software to include agentic AI by 2028, up from under 1% in 2024. That's a lot of agents that will need somewhere to plug in, and someone watching what they plug into.

Read the download curve as hype, and the production number as the real signal. Adoption at this pace doesn't leave much runway for figuring out governance after the fact, and the gap between download numbers and production deployments suggests governance is often an afterthought.

What MCP reliably delivers at the protocol layer

Give MCP credit where it's due: standardized discovery works. An AI client can find and call a tool without a developer writing custom glue code for that specific pairing. That's the core promise, and it holds up.

Model-agnosticism is the other real win. Build a server once, and Claude, ChatGPT, Gemini, Cursor, and Copilot can all use it. Bloomberg's setup is the clearest illustration on record. Engineers applied dependency inversion, meaning agents, tools, and language models all conform to standardized, swappable interfaces, so no single component locks the system in place. Prompts and toolchains got treated as configuration rather than code. Bloomberg built remote, multi-tenant MCP servers with identity awareness baked in, and kept agent logic cleanly separated from application logic. The payoff: tool reuse across departments, serving over 9,500 engineers without each team reinventing its own connectors.

That reuse compounds. With the right automation in place, teams have gotten new AI use cases into production in hours instead of weeks, since the connector work is already done and only the AI logic itself needs building.

What MCP stays quiet on matters just as much. It doesn't dictate which model to run, and it doesn't force a rebuild when a team switches providers. That neutrality is a genuine feature, not a gap.

Still, the honest way to describe MCP's job: it opens the connection and moves the data. What happens to that data once it arrives, who checked it, who logged it, who's allowed to see it, sits entirely outside the protocol's job description. Treating it as more than that is where the trouble starts.

Where the protocol boundary ends and enterprise risk begins

MCP doesn't define permissions. It standardizes the channel a request travels through, not who's allowed to send that request or what they're entitled to get back. Access control has to be bolted on separately, by someone, on every deployment.

There's no built-in audit trail either. Nothing in the protocol logs which tool got called, by which agent, with what arguments, returning what result. For a bank or a hospital system, that's a significant omission. That's the difference between passing a compliance review and failing one.

Data governance runs into the same wall. Without extra controls sitting in front of it, an agent calling an MCP server can pull anything that server exposes. There's no automatic scoping down to what the specific requesting user should actually be allowed to see.

Authentication is still catching up too. Authentication in most MCP deployments today lacks the dynamic, centrally managed credential systems that enterprise security teams expect. More robust authentication mechanisms remain a work in progress rather than a current protocol feature.

The local server problem deserves the most worry. STDIO-based MCP servers running on individual developer machines create serious visibility problems: there is no centralized log, no enforced access control, and no straightforward way to revoke a credential when someone leaves the company. Each developer sets up servers on their own, which breeds configuration drift and secrets scattered across machines. A compromised laptop with local MCP access to a production database becomes a direct path to credential theft.

None of this is an oversight waiting to be patched. MCP was built for simplicity and interoperability first. Authentication and encryption sit outside the protocol's current scope, a consequence of the design priority placed on simplicity and interoperability.

Security vulnerabilities that appear specifically because of MCP's design

The numbers here demand sitting with. Research from Deepak Gupta found that 43% of MCP servers carry command injection flaws, and once a system has 10 plugins loaded, the odds of a successful exploit run above 92%. That's close to a coin flip turning into a near-certainty as complexity grows, and it happens fast, not gradually.

Secrets sprawl compounds it. Research into public repositories has found significant numbers of secrets exposed in MCP-related configuration files, a meaningful share of which remained valid and usable at the time of discovery.

A handful of attack patterns have shown up repeatedly enough to get names. Tool poisoning happens when a malicious description gets embedded inside a tool definition and quietly changes how the agent behaves, one of several attack patterns that have emerged as MCP adoption has grown. Silent or mutated tool definitions describe a tool that behaves one way when trust is established, then shifts later. Cross-server tool shadowing is when a malicious server intercepts a call meant for a trusted one. Data returned through the MCP channel can itself carry attacker-controlled content that manipulates agent behavior, requiring no direct access to the agent or model.

Thoughtworks points to "toxic flow analysis" as an emerging response: mapping how data actually moves through an agentic system to find the weak points before an attacker does. Tools like MCP-scan are starting to build this kind of checking in.

Context matters here too. A K2View survey found 76% of organizations rank guardrails as their top overall concern with generative AI, and 62% cite enterprise data readiness as a data-related issue slowing GenAI progress. MCP's security gaps land directly on top of governance capacity that was already stretched thin before MCP entered the picture. The same openness that makes the protocol easy to adopt is exactly what makes it easy to exploit, absent something sitting in front of it to catch the bad calls.

What a governed MCP registry does that a public server directory cannot

The official MCP Registry launched in preview on September 8, 2025, as an open catalog of publicly available servers. Fine for discovery. Not built for enterprise governance, and it shows the moment you try to use it that way.

Generic public registries fall short of enterprise governance needs in predictable ways. There is no server-level access restriction, so any agent can connect to any listed server. There is no audit trail recording which agent touched which tool, when, or with what input. There is no access governance at the registry level, no user, group, or agent-based permission system. And hosted registries route tool calls through external network infrastructure, creating real exposure under frameworks like SOC 2 or GDPR.

GitGuardian's recommended fix looks a lot like standard identity and access management, just applied to MCP. Every connection request should specify the agent, the target tool, the permissions needed, and how long the credential should live, reviewed with the same rigor as an IAM role grant. Organizations need a central registry recording every connection: which agent talks to which server, what permissions ride along, who owns the connection, when the credential was last rotated. Periodic reviews, a business justification attached to every connection, and revocation for anything sitting unused.

JFrog's enterprise approach adds a few more pieces: tool permissions scoped down to specific authorized teams and projects, policy enforcement applied at the moment of request based on license type, known vulnerability severity, or operational risk, and a single control plane that treats MCP servers as software artifacts, tracked and versioned the same way any other piece of the supply chain would be.

The registry is mandatory infrastructure that must be added from the start. It's the piece that turns MCP from something a developer installs on a laptop into something an enterprise can actually govern, and skipping it is how a working pilot turns into an unmanageable sprawl of servers nobody can account for.

Permissions and context management require infrastructure MCP does not include

Permission inheritance doesn't happen automatically. When an agent calls an MCP server, it doesn't get automatically limited to whatever the requesting human user is allowed to see. Somebody has to build that scoping in separately, every time, and MCP itself offers no mechanism for it.

Pulling data from multiple systems runs into a similar wall. A single customer record might live partly in SAP, partly in Salesforce, partly in Workday, and partly in a support ticketing system. Without added architecture, that means a separate MCP server per system, and the job of stitching those pieces into one coherent picture falls on the agent itself. That's a fragile place to put it. Without metadata enrichment, entity resolution, and a shared semantic layer connecting the pieces, agents tend to produce answers that sound plausible but are wrong, built from partial or contradictory inputs.

Freshness is a live problem too. Stale data returned through an MCP server leads directly to bad suggestions, and conversational AI needs answers close to real time. Add up latency across several source systems, and the lag compounds fast.

K2View's survey found 45% of organizations are now aiming for production-scale generative AI deployment. Data problems are still what slows that down: guardrails at 76%, enterprise data readiness at 62%, and quality, fragmentation, and privacy concerns rounding out the list.

Session-scoped authorization is a better fix than the one most teams reach for first. Rather than handing an agent a long-lived OAuth token it can use indefinitely, access gets tied to the length of one specific task. When the task ends, the access ends with it, and the agent needs explicit human sign-off to get it back. The underlying point holds regardless of which fix gets used: MCP connects an agent to a system, but it does nothing to make that system's data actually ready for AI to use. Quality, semantic structure, and access scoping are all prerequisites the protocol quietly assumes somebody else has already handled.

How enterprises can deploy MCP at scale without rebuilding governance for every team

Bloomberg, JFrog, and GitGuardian all point toward the same underlying pattern: treat MCP servers as managed software artifacts, not something a developer spins up on their own machine when they need it. Any enterprise still letting individual teams stand up their own local servers is building the same problem five times over instead of solving it once, and that's the wrong call every time it gets made.

The architecture choice matters more than it looks. Remote, multi-tenant MCP servers with identity awareness, Bloomberg's approach, make governance possible from the start. Local STDIO servers scattered across individual laptops make it close to impossible after the fact.

Scoping by department helps too. Revenue operations, engineering, support, and sales can each get access to the tools and data relevant to their own work, with permissions inherited from the source systems rather than redefined from scratch for every new agent.

One governed server, deployed once, can serve every AI surface an organization uses: Claude, ChatGPT, Cursor, Gemini, Copilot, all pulling from the same permission model and the same context. That consistency is worth more than it sounds. It means a single access policy actually holds across every tool employees touch, instead of five different policies drifting apart over time.

A shared registry is what makes that possible at scale. Version control on every server definition, ownership and access scope recorded per connection, an approval workflow with the same rigor IAM teams already use, and rotation and deprecation policies enforced centrally rather than left to whoever set up the server originally.

Skip the shared registry, and teams end up rebuilding the same server configurations independently, department by department. That's the exact integration problem MCP was supposed to solve, resurfacing one layer up, inside the walls of a single company. Model-agnosticism should live in that governance layer, not get tied to whichever model happens to be popular this quarter. Context, permissions, and guardrails that travel with the organization, rather than with whatever model is running underneath, are what actually last.

What to evaluate before treating MCP as an enterprise-ready solution

Before rolling MCP out past a pilot, a few questions deserve straight answers, and the honest ones will make plenty of teams uncomfortable. Who owns the registry, and does that owner have the authority to revoke a connection without asking five other teams first? Is there an audit log covering every tool call, every agent, every result, or does "we'll add logging later" mean logging never actually gets added? Does authentication rely on static secrets sitting in a config file somewhere, or is there a real path toward OAuth 2.1 and proper identity federation?

Permission inheritance deserves its own hard look. Does access scope down automatically to what the requesting user is entitled to see, or does every new agent need its scoping rebuilt from scratch? And on data readiness: is the underlying data clean and current enough for an agent to act on, or is the plan to bolt an AI layer onto systems that were never built to support one?

MCP earns its reputation. It took an integration problem that used to scale by multiplication and turned it into one that scales by addition, and that alone is worth the industry's attention. But the protocol was never built to solve governance, permissions, or auditability, and it was never meant to. Those pieces are the enterprise's job, not the protocol's. Pretending otherwise is how a pilot that looked promising in a demo turns into a production incident six months later, and by then the fix costs a lot more than it would have upfront.