The MCP Bloat Tax: How 72% Context Burn and Cross-Vendor Data Egress Are Breaking Enterprise Agent Economics

At Atlassian’s Team 2026 conference this week, the company announced that new MCP tools for its Teamwork Graph produce 44% more accurate results and reduce token costs by up to 48%. The headline reads as a product update. What it actually is: a public admission that the standard MCP data access pattern has been burning enterprise tokens at a rate Atlassian couldn’t defend anymore.

Read that number again. Forty-eight percent. Nearly half of the tokens enterprises were spending on MCP-based agent queries were unnecessary — noise generated by the architecture itself, not the work being done. And Atlassian’s situation is not unique. Across the enterprise AI ecosystem right now, the same pattern is playing out: teams deploy agents that use MCP to access platform data, those agents pull everything they can into context, and the bill arrives before any meaningful work is confirmed.

ServiceNow announced something structurally similar at its Knowledge conference this week. Its new Access Fabric (also called Action Fabric depending on which press release you’re reading) separates lightweight AI agent data requests from the per-gigabyte egress charges applied when users move large volumes of data off the platform. The framing was about openness and interoperability. The subtext was about metering: agents that want to talk to ServiceNow’s data graph are now going through a billing layer whether they realize it or not.

SAP and Workday have moved in the same direction. The enterprise software stack that agents need to traverse to do real work is now a tollway — and nobody told the teams that were architecting their agentic workflows last year.

Why MCP Bloat Is an Architectural Problem, Not a Configuration Mistake

The Model Context Protocol was designed to make it easy for AI agents to access tools and data from external systems. It succeeded at that goal spectacularly — SDK downloads grew from roughly 100,000 to 97 million per month in eighteen months. Enterprise MCP adoption is now north of 78% among production AI teams. The protocol works. The economics of deploying it at scale, however, were not fully visible until teams started running real workloads.

The core problem: standard MCP implementations don’t differentiate between what an agent needs and what an agent can access. When an agent connects to an MCP server, it typically loads all available tool definitions into its context. That’s schema definitions, descriptions, parameter structures, response formats — for every tool the server exposes, regardless of whether the agent will touch 90% of them. Research measuring real production MCP deployments has found that this startup cost consumes an average of 72% of the agent’s context window before any actual work begins.

That context burn has a second-order effect that’s harder to see in cost dashboards but shows up in quality metrics. When tool sets get large — as they inevitably do in enterprise platforms that expose dozens or hundreds of capabilities — model accuracy on tool selection collapses. Studies on RAG-MCP systems measured the degradation directly: tool selection accuracy dropped from 43% correct to under 14% as tool catalog size increased. The agent isn’t just burning tokens. It’s burning tokens to make worse decisions with the context it has left.

Atlassian’s fix was architectural. Instead of exposing raw tool endpoints that agents query by stuffing context, the new Teamwork Graph MCP tools let agents query the graph with structure — understanding the relationships between data objects, not just the raw attributes. An agent can now ask for exactly the context it needs and navigate relationships explicitly rather than pulling everything into the window and hoping the model sorts it out. The result is 48% fewer tokens and substantially better result quality.

Cloudflare published a related pattern in April: Code Mode for their MCP server exposes only two tools — search() and execute() — backed by a type-aware SDK that generates JavaScript for execution inside a V8 isolate. Compared to loading full endpoint definitions into context, they measured up to 99.9% token reduction. That number seems absurd until you understand the baseline: they’re comparing against the standard approach of loading every API signature into the context window.

The Cross-Vendor Data Tax Nobody Calculated

Even if you solve context bloat on individual platforms, the multi-vendor reality of enterprise agent orchestration adds a compounding cost that architecture alone can’t fully fix.

The concern that Forrester analyst Charles Betz raised publicly this week is one that enterprise architects are increasingly hearing from their own teams: when you add an evaluator agent on top of a primary agent to improve output quality — which you often have to do to hit production reliability targets — you’ve doubled your token spend. That evaluation pattern, agent reviewing agent, is one of the more effective quality levers teams have found. It’s also significantly more expensive than the original task.

Add data egress charges on top of that. ServiceNow, Atlassian, Workday, SAP — each of these platforms has terms and conditions around data movement. Forrester has been advising clients on this directly: organizations that bring in third-party agents wanting to access the full ServiceNow or Atlassian data graph are going to face a hard conversation about what that access costs. A startup agent that wants to “download the whole graph” to provide better enterprise context isn’t a theoretical risk scenario. It’s the architecture that many productivity-focused AI products are built on.

Rebecca Wettemann, CEO of research firm Valoir, put it plainly: the fear isn’t that an agent causes damage. The fear is waking up to find it burned $4 million in tokens overnight without producing measurable outcomes. That number sounds like hyperbole. It isn’t. At scale enterprise token rates, a poorly scoped agent running evaluation loops across cross-domain tool sets can generate costs that don’t show up as a line item until someone audits the API bill.

The pricing models themselves are adding pressure from above. Consumption-based token pricing — what almost every AI vendor charges today — doesn’t tie to outcomes. AheadCRM’s Thomas Wieberneit said exactly what enterprise AI architects have been quietly saying internally: consumption pricing is a crutch for vendors. It transfers implementation risk to buyers and gives vendors clean hands when ROI doesn’t materialize. The whole industry needs pricing models that tie agent usage to verified outcomes. None of the major vendors are there yet.

The SuperML Take

The Atlassian announcement is significant not because of the 48% number — impressive as it is — but because of what it confirms. MCP’s default “give agents everything and let the model figure it out” pattern was never designed for enterprise deployment at scale. It was designed for rapid adoption. The adoption happened. Now the reckoning is arriving, and the teams experiencing it earliest are those who moved the fastest.

The press-release version of this story is: Atlassian improved its MCP integration and agents will perform better. The production version is: a major enterprise software vendor just validated that the architectural pattern most teams adopted for MCP-based agent orchestration is generating waste budgets that now need architectural fixes, not just configuration tuning.

ServiceNow’s Access Fabric launch at the same moment is not coincidence. The enterprise platforms that house the data agents need to be useful — ITSM records, project graphs, work items, code metadata — are all moving to metered agent access simultaneously. They’ve watched how quickly MCP adoption accelerated, they’ve seen the data egress implications of agents with broad access permissions, and they’re drawing the line now, before the cross-platform agentic wave fully arrives. The architecture decisions enterprises are making today will determine whether their agent ROI calculus survives contact with the billing department.

For production AI teams, the practical implication is that the “connect everything with MCP and iterate” approach has a ceiling. It worked at pilot scale. At production scale — thousands of agent invocations per day, multi-platform data access, evaluator agents running in parallel — the economics break in ways that don’t show up in evaluation metrics. They show up on invoices.

What this means for the next 12 months: expect the enterprise MCP gateway market to consolidate fast. Today’s tooling — LiteLLM, Portkey, Bifrost, Kong’s AI Gateway — all address pieces of the problem. What enterprises actually need is token-aware routing with structured query patterns, tool catalog management with dynamic schema loading, and cross-vendor egress awareness built into the governance layer. That product does not fully exist yet. The teams building it are in a race with the enterprise platforms themselves, which have every incentive to be the preferred gateway for agents accessing their data.

Architecture Impact

What changes in system design? MCP deployments need to shift from eager tool loading to lazy, structured query patterns. Agents should not receive full tool schemas at session start; instead, tool discovery should be dynamic and demand-driven. For cross-platform orchestration, token budgets must be factored into the agent’s routing logic before invocations are made — not after the context window is already consumed.

What new failure mode appears? Cross-domain token explosion: an orchestration workflow that chains agents across ServiceNow, Atlassian, Salesforce, and a proprietary data source can silently accumulate context costs at every hop. The failure is not a crash or timeout — it’s a degraded agent that’s used 70%+ of its context on tool definitions, leaving insufficient window for actual reasoning, then silently selects incorrect tools and produces confident-sounding wrong outputs. This failure mode doesn’t surface in standard accuracy evals run against single-platform test suites.

What enterprise teams should evaluate:

• Platform engineering teams: Audit every MCP server connection and count the tools exposed at session initialization. Any server exposing more than 15–20 tools at load time is a token cost risk. Evaluate schema streaming or dynamic tool registration patterns.
• FinOps / AI cost governance teams: Map token spend by agent type and orchestration depth. Agent-evaluates-agent patterns are typically 1.8–2.5x the base token cost of the primary agent alone. Build alerting on per-workflow token consumption, not just monthly aggregates.
• Enterprise architects: Review contracts with ServiceNow, Atlassian, Workday, and Salesforce specifically for agent data access terms. Egress charges that were written for batch ETL jobs may be triggered by agentic traffic in ways the procurement team didn’t model.
• ML infrastructure teams: Evaluate MCP gateway tooling with structured query support — Cloudflare’s reference architecture and Bifrost’s token-aware routing are good starting points. Tool catalog management with dynamic loading should be on the 2026 roadmap.

Cost / latency / governance / reliability implications: At production scale (10,000+ agent invocations per day), the difference between eager and lazy MCP tool loading can represent $15,000–$80,000 per month in token costs depending on model and platform. Latency is also affected: context assembly before work begins adds 200–800ms of overhead per invocation in typical enterprise MCP implementations. On governance: cross-vendor agent data access is now a contractual and audit concern, not just a technical one — AI governance teams need visibility into which agents are crossing platform boundaries and what data they’re pulling, with the same rigor applied to API egress as to human data access.

What to Watch

The MCP Dev Summit North America (April 2026) put structured tool access on the roadmap explicitly. Watch for updates to the MCP spec around lazy tool loading and schema streaming — these are the architectural fixes that the core protocol needs to address, not just individual vendor workarounds. Atlassian’s Teamwork Graph approach and Cloudflare’s Code Mode are both production-validated examples of what structured MCP should look like; expect Anthropic and the broader MCP community to formalize similar patterns in protocol guidance.

ServiceNow’s Access Fabric pricing details — which the company conspicuously has not disclosed — will be a signal for the whole enterprise software market. If the pricing is friendly to lightweight agent queries, it suggests platform vendors are prioritizing ecosystem adoption. If it’s structured to incentivize staying within the platform’s own agent tooling, the cross-vendor orchestration scenario gets significantly more expensive. Watch the Q2 earnings calls and enterprise customer case studies from both Atlassian and ServiceNow for data points.

The competitive pressure will also come from the hyperscalers. AWS, Azure, and Google all have incentives to be the managed layer through which enterprise agents access cross-platform data — and to apply their existing enterprise egress relationships and committed spend discounts to the agentic access problem in ways that pure-play platforms cannot.

Sources

• Atlassian MCP updates take aim at AI token usage — TechTarget / Beth Pariseau
• ServiceNow reintroduces itself as an AI ‘security company’ — TechTarget
• ServiceNow AI pricing change takes on enterprise ROI struggles — TechTarget
• 10 strategies to reduce MCP token bloat — The New Stack
• MCP Token Optimization: 4 Approaches Compared — StackOne
• Cloudflare Launches Code Mode MCP Server to Optimize Token Usage — InfoQ
• Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP — Cloudflare Blog
• MCP’s biggest growing pains for production use will soon be solved — The New Stack
• ServiceNow, SAP and Workday Make AI Agents Pay to Play — PYMNTS
• Best MCP Gateway in 2026: How Bifrost Cuts Token Usage by 50% — getmaxim.ai