MCP in the Enterprise: Cost, Security, and Workload Routing

TL;DR:

• MCP solved a real integration problem: instead of every AI tool needing its own custom connection to every internal system, each system exposes one standardized endpoint that any AI tool can use. The hidden cost is schema discovery, which scales linearly with adoption. A 500-person organization with three connected servers and modest usage can run above $500K/year in tool-schema tokens alone.
• Route deliberately. Local workloads belong in CLI (32x cheaper). Remote analytical queries belong in a governed semantic layer. Event-driven workloads belong on webhooks or Kafka, not polling agents. Batch belongs in orchestration tools like Airflow or Dagster. MCP earns its keep on remote SaaS integrations where no CLI exists.
• Security falls short of what regulated industries need. About 53% of community servers use static API keys, MCP has no native audit logging, and shadow adoption is already happening at most enterprises. Three-step minimum: audit existing connections, establish an approved-server catalog with OAuth 2.1, and put a gateway in front of anything touching sensitive data.

Anthropic’s Model Context Protocol (MCP) crossed 97 million monthly SDK downloads in March 2026, up from roughly 2 million when it launched in November 2024. OpenAI, Google, and Microsoft all offer MCP-compatible tooling. What is not settled is how enterprises should use it, how much it costs at scale, and where the security model falls short. James Winegar and I dug into the enterprise implications on a recent episode of Eventual Consistency, and we have written separately about why agents need governed data infrastructure to produce reliable answers. The operational side is what most MCP coverage skips: the token economics that determine your spend, the routing decisions that determine which workloads belong in MCP at all, and the security gaps that have already been exploited in production.

The Integration Economics

Before MCP, connecting AI agents to enterprise systems was an N×M problem. Ten AI applications talking to a hundred internal tools could require up to a thousand custom integrations, each carrying its own auth, schema mapping, error handling, and maintenance. MCP collapses this to N+M: 110 standardized endpoints instead of 1,000. Build cost per integration drops from 40 to 80 engineering hours to roughly 4 to 8 hours wrapping an existing API in an MCP server, and when you update that server, every consuming client inherits the fix. If your team has a six-month backlog of “connect AI to X” requests, this is the compression that makes the queue move.

The integration savings mask a cost that scales in the opposite direction: token consumption.

MCP tool schemas describe every parameter, type, and annotation in JSON so language models can discover and use tools at runtime. Apideck reported three MCP servers consuming 143,000 of a 200,000-token context window (72%) before a single user query was processed. Scalekit ran the same GitHub task through MCP and CLI and measured 44,026 tokens versus 1,365 on the simplest case. That is a 32x cost multiplier on identical work.

The cost compounds because LLM API calls are stateless: every conversational turn resends the full context window, including all tool schemas, as input tokens. A session with five back-and-forth turns bills those schema tokens five times, not once. Prompt caching reduces the per-turn cost when the prefix is reused, but the schema is still anchoring most of the bill. Three variables determine your schema overhead: how many MCP servers are connected per session, how many turns each session runs, and how many sessions your organization runs per day.

The table below shows how these interact. Assumptions: 48,000 tokens per MCP server schema (derived from the Apideck benchmark of 143,000 tokens across three servers), $3 per million input tokens (Claude Sonnet pricing as of April 2026), 260 working days per year, and uncached input. These figures are schema overhead only, the cost of tool discovery before any productive work occurs. Actual token spend includes the user’s query, retrieved context, and model reasoning on top.

For a 500-person organization, the relevant question is what percentage of the workforce runs agent sessions daily. If 40% of knowledge workers use AI agents with five sessions per user per day, that is 1,000 daily sessions, which with three connected MCP servers and five turns per session puts annual schema overhead above $500,000. Even conservative assumptions (20% adoption, three sessions per day) produce six-figure annual spend that does not appear in any AI licensing invoice. This is the carrying cost of tool discovery, and it scales linearly with agent adoption.

Token overhead also costs quality. When 72% of the context window is schemas, the model has less room for reasoning, conversation history, and retrieved documents. You pay more and get worse answers, because the model is reasoning in a compressed space. Routing is what closes that gap: not every workload should flow through MCP, and deciding which ones should is the most consequential call in an MCP rollout.

Routing: When MCP Is the Right Tool and When It Is Not

The cost table makes the first routing decision obvious: any workload that can run through CLI should. For anything local (file manipulation, shell commands, git workflows, builds, tests), language models were trained on millions of CLI examples, the cost per task is two orders of magnitude lower, and reliability approaches 100%.

MCP earns the overhead for remote integrations where CLI either does not exist or cannot fit into an agent’s context. Slack, Salesforce, Notion, Jira, MotherDuck, Snowflake: these are systems where MCP provides the only standardized agent interface. James pointed out during our recording that the Databricks CLI exposes roughly 1,000 tools, and Google Cloud’s is even larger. Neither fits in a context window. MCP’s constrained tool surface is a feature in these cases, not a limitation, because it forces a manageable scope.

Choosing between CLI and MCP is only the beginning. Whether an agent should use a governed semantic layer, a document search index, an event stream, or an orchestration pipeline depends on the type of operation, the sensitivity of the data, and how frequently the interaction occurs. Getting this wrong creates governance gaps, brittle pipelines, and agents that produce unreliable answers. Neither protocol addresses governance on its own: authentication, authorization, audit logging, and data classification require purpose-built infrastructure regardless of which access method you choose.

The decision tree below captures how these routing choices compose.

1. Where does the data live? Local workloads (file manipulation, shell commands, git, builds) route to CLI. The model already knows how to use a terminal, so there is no reason to pay for schema discovery. Remote workloads continue down the tree.

2. Does an API or direct connection exist? If yes, you have options. If no, the fallback depends on whether you need read-only or read/write access. Read-only extraction (scraping a legacy UI, pulling data from PDFs or screenshots) can work through multimodal language models. Read/write operations with no API push you toward RPA or screen automation, which should be treated as a last resort because it is brittle and breaks when the UI changes.

3. What type of operation? This is where routing gets specific.

   • Document search. An agent helping a support engineer find relevant troubleshooting runbooks, or a compliance team searching contract archives for specific liability clauses. Metadata queries, semantic search, or hybrid approaches sit upstream of the access protocol: you find the relevant documents first, then retrieve them via MCP, API, or CLI depending on where they live.
   • Analytical queries. An agent answering “what was our customer acquisition cost by channel last quarter” or “which product lines have declining margins.” These should flow through a governed semantic layer, because that is where metric definitions and business logic live. If no semantic layer exists, the right move is to build one before exposing the data to agents (we cover this in depth in “Skip the Data Stack”).
   • Event-driven. A PII detection stream that flags new incidents as they occur, or a webhook that triggers a review workflow when a contract is signed in DocuSign. These scenarios are better served by event infrastructure (webhooks, Kafka, EventBridge) than by an agent polling via MCP on a schedule. Polling means paying the full schema cost on every check, most of which return nothing new. Event-driven architecture invokes the agent only when there is something to act on.
   • Batch. Nightly reconciliation of inventory across warehouses, weekly aggregation of usage metrics for billing, or bulk enrichment of CRM records against a third-party data provider. These belong in orchestration tools like Airflow, Dagster, or Prefect, which coordinate the compute that does the work: Spark jobs, Cloud Functions, Dataflow pipelines, containerized processing, whatever fits the workload. Agent interactions are designed for conversational, iterative work, and trying to push batch volume through them produces brittle pipelines.
   • Live operations. An agent checking a Jira ticket status during a standup, updating a CRM record after a sales call, or pulling current inventory from an ERP to answer a customer question. These continue to the sensitivity and frequency checks below.

4. How sensitive is the operation? Standard operations continue to the frequency check below. Regulated or high-risk operations need governed access, and there are three ways to get there:

   • MCP behind a gateway. When you need centralized governance across multiple services: a single audit log, unified policy enforcement, IAM and SIEM integration.
   • Direct API with user-scoped OAuth 2.1. When the service provides adequate native controls. Salesforce, Workday, and ServiceNow all have mature audit trails and field-level security built in.
   • Human-in-the-loop. For high-risk write operations where automated controls are not sufficient. The agent prepares the action and a human authorizes execution.

5. How frequent is the interaction? High-volume interactions should use direct API or CLI to minimize overhead. Standard-frequency operations are where MCP earns its keep: the schema cost is justified by the standardized interface and the reduced integration maintenance.

The point of the framework is that MCP is one of at least seven integration patterns an agent might use. Defaulting everything to MCP because it is the most talked-about option is how you end up with six-figure token bills and governance gaps that show up in your next audit.

The Security Surface

MCP adoption is outrunning the protocol’s security model, and the two gaps that matter most to regulated enterprises are structural, not incidental.

The first is audit logging. As of April 2026, MCP has no native specification for recording what agents accessed, when, or on whose behalf. Most server implementations authenticate as a single service account rather than propagating individual user permissions. As James put it on our podcast: if you would not give a human employee a super-privileged service account with blanket access to all customer records, you should not give one to an AI agent. The same AAA framework (authentication, authorization, accountability) that governs employee access needs to extend to every agent connection. In HIPAA, SOC 2, or SEC environments, user-level audit trails are not optional. Their absence blocks compliant deployment.

The second is the community ecosystem itself. About 53% of community MCP servers still use static API keys or access tokens rather than OAuth 2.1 with short-lived, user-scoped tokens. Static keys cannot expire automatically, cannot be scoped to an individual user, and when compromised provide persistent access until someone manually revokes them. Beyond credential hygiene, the ecosystem has already produced real incidents: a CVSS 9.6 vulnerability in mcp-remote (CVE-2025-6514) that compromised API keys across an npm package with more than 437,000 downloads; an Asana MCP bug that exposed one tenant’s data to another; a Smithery registry breach that compromised credentials across more than 3,000 hosted MCP servers; and slopsquatting campaigns where attackers register malicious packages under names that language models hallucinate, with one npm campaign contaminating 126 packages and accumulating more than 86,000 installs.

For security teams evaluating the technical attack surface in more detail: Invariant Labs demonstrated that malicious instructions can be embedded in MCP tool descriptions in ways invisible to users but interpreted by the model, and MCP’s dynamic tool definitions can be modified between sessions without notification, meaning a server that behaves correctly today can be rerouted tomorrow. The defenses are an allowlist of approved servers (not open-registry installs), pinned tool definitions, and OAuth 2.1 for anything touching production data. These are operational controls that organizations must implement themselves. The protocol does not enforce them.

Shadow Adoption Is the Reason This Is Urgent

These security gaps would be concerning in a controlled rollout. The reality at most enterprises is less controlled than that.

Individual developers and analysts are already using MCP through Claude Desktop, Cursor, and Windsurf. They have connected personal access tokens to company GitHub repos, wired Claude to production data warehouses for faster ad hoc queries, and hooked up Slack MCPs to catch up on channels. Each of these is a reasonable decision by a competent person trying to move faster. None of them went through security review, and none of them appear in any audit log. The Vercel breach disclosed in April 2026 is what this pattern looks like when it goes wrong: a single employee granted OAuth permissions to a third-party AI tool using their enterprise Google Workspace account, and attackers used that access to pivot into Vercel’s systems and customer credentials. The tool was not vetted. The permissions were not scoped.

The speed at which AI coding tools have proliferated means MCP connections are accumulating faster than governance teams can track them. The pattern is familiar to anyone who lived through early SaaS adoption or the first wave of cloud migration: by the time leadership notices the footprint, it is already significant and messy to clean up.

Getting to a managed state takes policy decisions backed by tooling choices, and the first three moves are the same regardless of industry or stack.

1. Audit what is already connected. Survey your engineering and analytics teams for MCP servers they have installed locally. Check for personal access tokens issued to AI tooling. The results tend to reveal more connections than anyone expected, and that inventory is the baseline for everything else.

2. Establish an approved server catalog with centralized authentication. Decide which MCP servers are sanctioned for use against which systems, require OAuth 2.1 instead of static keys, and make the approved list easy enough to use that people prefer it to installing community servers on their own. The catalog does not need to be exhaustive on day one. It just needs to exist.

3. Deploy an MCP gateway for anything touching sensitive or regulated data. The gateway provides the audit logging, user-level access control, and SIEM integration that the protocol lacks natively. This is where you close the compliance gap.

The longer the distance between shadow adoption and governance, the larger the eventual remediation. Most organizations can complete the first two steps in weeks.

What Comes Next

MCP is going to be the default integration layer for AI agents. Anthropic donated the spec to the Linux Foundation’s Agentic AI Foundation in 2026, with AWS, Google, Microsoft, OpenAI, Cloudflare, Bloomberg, and Block as founding members. Gartner projects that by 2026, 75% of API gateway vendors and 50% of iPaaS vendors will add MCP features. Your organization will use MCP. The question is whether you will use it deliberately or discover you already are when something breaks.

The companies that treat MCP as an infrastructure decision (routing workloads intentionally, managing token economics, closing the governance gaps before regulators or attackers find them) will build agents that are reliable and defensible. The companies that let adoption happen organically will spend the next two years cleaning up the mess, the same way they spent 2015 to 2020 cleaning up shadow SaaS and ungoverned cloud accounts.

The three steps in the previous section are the minimum. The longer you wait, the more connections accumulate without oversight, the more tokens burn without tracking, and the harder the remediation becomes.

If your team is working through MCP routing, gateway design, or AI strategy more broadly, we should talk.

Sources

• Alan West, “MCP Hit 97 Million Installs: The Protocol War Is Over”: MCP monthly SDK download growth from roughly 2 million in November 2024 to 97 million in March 2026.
• Apideck, “MCP Servers Are Eating Your Context Window”: three MCP servers consuming 143,000 of 200,000 tokens (72%) before any user query.
• Scalekit, “MCP vs CLI”: 32x token cost ratio between MCP (44,026 tokens) and CLI (1,365 tokens) on identical GitHub task using Claude Sonnet 4.
• Astrix Security, “State of MCP Server Security 2025”: roughly 53% of community MCP servers using static API keys or access tokens, with 79% of API keys passed via plain environment variables.
• The Hacker News, “Critical mcp-remote Vulnerability”: mcp-remote CVE-2025-6514 with CVSS 9.6, affecting an npm package downloaded more than 437,000 times.
• UpGuard, “Asana Discloses Data Exposure Bug in MCP Server”: cross-tenant data exposure via Asana’s MCP server.
• GitGuardian, “Breaking MCP Server Hosting”: Smithery registry breach exposing credentials across more than 3,000 hosted MCP servers.
• Socket, “Slopsquatting: How AI Hallucinations Are Fueling a New Class of Supply Chain Attacks”: the slopsquatting concept and AI package hallucination rates.
• CSO Online, “Malicious Packages in npm Evade Dependency Detection”: 126 contaminated npm packages with more than 86,000 installs (PhantomRaven campaign).
• Invariant Labs, “MCP Security Notification: Tool Poisoning Attacks”: tool poisoning and shadowing attacks against MCP servers.
• The Hacker News, “Vercel Breach Tied to Context AI Hack”: Vercel OAuth breach pivoting through a third-party AI tool.
• Linux Foundation press release: Agentic AI Foundation governance of MCP, with AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI as Platinum members.
• K2view, summarizing Gartner research: Gartner projection that by 2026, 75% of API gateway vendors and 50% of iPaaS vendors will have MCP features.

For more on this topic, listen to What MCP Means for Enterprise Data Strategy and read Skip the Data Stack, Get the Wrong Answer Faster.