Cost Attribution and Chargeback for Enterprise MCP Usage

Standard IT chargeback was built for a predictable world. A user logs in, clicks a button, consumes a resource. Agentic workflows break both assumptions simultaneously: the initiator is autonomous, and the consumption is neither predictable nor visible in real time.

The scale gap is jarring once you see it. Agentic tasks consume orders of magnitude more tokens than a code chat session, with the same task varying wildly in total token use across runs. Enterprise AI inference now dominates total AI budgets, and agentic workflows burn far more tokens per task than a standard chatbot query. Finance typically discovers this when the invoice arrives, because no human was watching when the agent was running. That is not a workflow problem. That is an architectural one.

Multi-tenant attribution compounds everything. One shared model pod serving multiple teams appears as a single infrastructure line item. The five-figure monthly bill lands on the team that provisioned the resource, regardless of who actually consumed it. Token-based, inference-request, and GPU-utilization pricing models simply do not map onto billing frameworks built for compute hours or SaaS seats.

Three MCP-specific cost drivers make the problem substantially worse.

Schema bloat is the one people underestimate first. A single well-documented tool consumes 200 to 500 tokens. Load 50 tools and you are spending 10,000 to 25,000 tokens on definitions before any tool has been called. GitHub's official MCP server consumes roughly 17,600 tokens of tool definitions per request; connect multiple servers and you can easily cross 30,000 tokens of metadata before the agent does meaningful work. One developer found MCP tool definitions accounted for more than 16% of a 200,000-token context window before any substantive conversation began. That overhead appears on every single request, without exception.

Response bloat is often the larger driver. A single HRIS API call returns raw JSON that dwarfs schema bloat in token cost. It is less visible because it varies by query and almost never appears labeled in logs.

Context re-sending is the one that surprises people the most. In a stateless protocol, every conversation turn pays for tool definitions again. A 9,000-token tool definition billed across 30 conversation turns is an invisible, compounding tax running silently beneath every active workflow. The cost is not anomalous; it is baked into the architecture. Some analyses indicate re-sent context accounts for the majority of total agent inference bills.

Attribution cannot be solved at the invoice layer. By the time the invoice arrives, the money is already gone.

What Real Budget Blowouts Look Like When MCP Costs Go Unattributed

The cases are documented, named, and consistent in what caused them.

Uber's Claude Code adoption jumped from 32% to 84% of its 5,000-engineer organization between December 2025 and March 2026. By April, the entire annual AI budget was exhausted, with monthly API costs per engineer reportedly running between $500 and $2,000. Forrester's July analysis identifies several additional named examples alongside Uber: Microsoft ended Claude Code licenses after exhausting its yearly AI allocation; Tesla capped AI spending at $200 per week per user; Priceline faced unexpected surges in AI development renewal costs.

What unites these cases is not negligence. Spend was invisible because there was no layer between the agent and the API capable of showing which team, workflow, or tool was responsible for which portion of the bill. The accountability vacuum was architectural, not managerial.

One documented production case reduced individual tool token usage from tens of thousands of dollars per month to hundreds of dollars per month once observability was actually applied. The waste had existed the entire time, undetected.

An MCP cost overrun discovered after the invoice is a postmortem, not a control. The attribution gap existed the moment the server went ungoverned. The invoice is just when it became undeniable.

Why the MCP Gateway Is the Natural Enforcement Point for Cost Attribution

Without a gateway, there is no aggregated view of what any agent is doing. Debugging a multi-step workflow means stitching logs from multiple servers, with no unified execution timeline, no trace correlation, no cost attribution, and no anomaly baseline.

API gateways fixed the distributed-services visibility problem by creating one enforcement point where everything had to pass through. MCP gateways do the same thing for agentic workflows. Gartner projects 75% of API gateway vendors will have MCP features by 2026, which indicates this layer is becoming standard infrastructure rather than a specialist choice.

What a gateway makes possible that direct-to-server connections cannot: per-agent, per-tool, per-session resource tracking with a consistent audit log across every call; per-user attribution even when the upstream sees a single service account, by passing the user's identity provider token through to keep individual identity in the trail; rate limiting on multiple dimensions simultaneously; integration with observability stacks like Prometheus, Grafana, and OpenTelemetry for real-time dashboards rather than after-the-fact logs.

Virtual server segmentation creates natural cost-center boundaries. Sales teams and HR teams accessing different MCP servers through the same gateway produce separate, attributable traffic streams. The access policy and the billing boundary become the same configuration object.

The same layer that enforces who can call what is, without additional instrumentation, the layer that records who called what and at what cost. Governance and FinOps are the same infrastructure problem. They do not require separate tooling; they require the same tooling applied with both purposes in mind from the start.

MCP Manager, built by Usercentrics on enterprise data governance foundations, provides a gateway control layer covering registry, role-based access control, real-time observability, and audit logging, turning MCP traffic into attributable, auditable cost data.

Building the Attribution Taxonomy: Dimensions That Make MCP Costs Meaningful to Business Units

Cost attribution is only useful if the tags it produces map to decisions someone in the business can actually act on. Start with the organizational unit that owns accountability and build outward.

The gateway should instrument six primary dimensions. The business unit or cost center: the team or department that owns the agent or workflow, the chargeback recipient. Agent identity: which agent or agent cluster initiated the call, distinct from the human who deployed it. The MCP server called, which maps to a specific capability, vendor contract, or internal service. The tool invoked within that server, the most granular unit of cost and the one most likely to surface optimization opportunities. The workflow or session, grouping calls into the end-to-end task they belong to so you can calculate cost-per-outcome rather than just cost-per-call. And user identity where applicable, passed through the identity provider token for human-in-the-loop workflows.

Beyond basic accounting, three secondary dimensions drive optimization. Token breakdown by type matters because input tokens including schema and context re-send, output tokens, and cached tokens each carry a different price and a different lever you can pull. Call outcome matters because cost per successful task is a more meaningful unit than cost per call, and it surfaces runaway retry logic that inflates spend without producing anything. Frequency and time-of-day patterns help identify misconfigured retry logic and off-hours autonomous agent activity, two of the most common sources of unexpected spend.

The prerequisite for all of this is a central registry. Every MCP server that is not registered is an identity that cannot carry attribution tags. Ungoverned servers produce costs that can never be allocated.

Most enterprises should instrument the highest-volume agents and the servers with the largest tool schemas first, rather than attempting full coverage immediately. Comprehensive coverage is a goal, not a precondition.

Chargeback Model Options and What Each Requires from the Gateway Layer

Three models are in practice across enterprises today, each appropriate to a different organizational context.

Showback is reporting without billing transfer. It is the right starting point for organizations with no prior AI cost attribution, because it makes spend visible to business unit leaders without changing financial flows. What it requires from the gateway: per-agent, per-server cost reporting accessible to non-engineering stakeholders on a regular cadence. Visibility alone creates accountability.

Proportional chargeback transfers actual measured costs to the consuming business unit based on attributed usage. It requires reliable per-session or per-workflow cost data from the gateway, a mapping of agent identifiers to cost centers, and agreement with finance on how to handle shared infrastructure costs. The key decision is whether to charge at token cost as a pass-through or at a blended internal rate that absorbs infrastructure overhead. Shared infrastructure requires an explicit allocation rule; common approaches are proportional usage share or a flat per-seat fee combined with variable overage.

Budget-cap chargeback is the model that prevents Uber-scale blowouts. Business units receive a monthly MCP budget; the gateway enforces the cap in real time, before the budget is exhausted, not after. This requires gateway-level budget enforcement with configurable thresholds per cost center and alerting well before the cap is hit. The cap is a financial control, not a performance constraint, and its power comes entirely from being enforced at the gateway, in the same layer as the access policy.

Across all three models, the audit log is not optional. It is the evidence that makes any chargeback model defensible to the business unit receiving the allocation. Without it, disputes are unresolvable and the model loses credibility quickly. MCP Manager's governance layer keeps that audit trail persistent, accessible, and tied directly to the access controls that generated it.

How the July 2026 MCP Specification Changes Affect Attribution and Billing Flows

The July 28, 2026 MCP Release Candidate introduced MCP Apps, Tasks, an extensible protocol framework, and significant changes to authorization and transport. For anyone building attribution infrastructure, three changes matter immediately.

The stateless architecture shift is the most disruptive for existing implementations. The deprecation of the Sampling feature removes the server's callback path into the model; servers now call the model provider directly rather than through the client. If your cost attribution was built assuming the client was the billing origin, that flow changes. The billing origin is now the server, requiring attribution logic to be re-anchored at the gateway rather than the client. Organizations that built attribution against the previous stateful model will need to rework it, and the sooner they acknowledge that, the less painful the transition.

The new authorization framework is genuinely useful. The enterprise-managed authorization extension lets organizations control MCP server access centrally using OAuth 2.1, OpenID Connect, and the Identity Assertion JWT Authorization Grant. This produces a full audit trail of which agent called which tool on whose behalf, standardized at the protocol level. Identity now flows through the authorization layer in a standardized way, making gateway-level attribution more reliable and substantially less dependent on custom instrumentation.

Deterministic caching of tool and resource listings improves LLM prompt-cache hit rates, which directly reduces the token cost of schema bloat and context re-sending. It will not eliminate those costs, but it changes the math for organizations that have been absorbing full schema token costs on every request.

Treat the RC spec as the baseline for any attribution infrastructure built or updated in late 2026. Building against the previous model now means scheduled rework later.

A Practical Implementation Path for Organizations Starting from Zero Attribution

Most enterprises are starting with no registry, no gateway-level tagging, and no designated cost owner. The path forward has to be additive, not comprehensive from day one.

Inventory and register first. Identify every MCP server in use, including shadow deployments running outside IT's visibility. Add each to a central registry with an owner, a cost center, and a classification of what data it touches. Every subsequent step depends on having a complete and accurate registry. You cannot attribute costs to servers you do not know exist, and in most organizations, the shadow deployment count is higher than anyone expects.

Deploy the gateway and enable basic tagging. Route all MCP traffic through a gateway and enable per-agent and per-server tagging from day one, even if you are only producing showback reports initially. The gateway does not need to enforce anything yet; it needs to observe everything. Integrate with your existing observability stack so the data lands somewhere engineers and finance can both access it.

Identify your highest-cost workflows. Use the tagged data to surface the agents and servers driving the largest spend. Instrument those deeply: token breakdown by type, call outcome, frequency patterns. Look specifically for schema bloat, response bloat, and re-sending. In most environments, a small number of misconfigured or unoptimized workflows account for a disproportionate share of total spend.

Formalize showback and build organizational consensus. Publish regular cost reports to business unit leaders. Finance needs to understand what it is seeing; business unit leaders need to understand they are accountable for what their agents are doing. Voluntary optimization at this stage is common and often catches things the technical team missed entirely.

Implement proportional chargeback once the data is trusted and the organizational conversations have happened. Begin transferring actual costs to consuming business units and agree on allocation rules for shared infrastructure before you start, not during your first dispute.

Enforce budget caps at the gateway for high-spend or high-risk teams. Configure thresholds, alerting cadences, and graceful degradation behavior before the caps go live. The goal is to prevent blowouts, not to surprise teams with service interruptions.

MCP Manager provides the registry, access control, observability, and enforcement capabilities that make each stage tractable. The governance layer and the attribution project are the same project. Treating them as one from the beginning is the difference between organizations that stay ahead of their AI spend and those that discover the problem at invoice time.