Attributing cost across an MCP tool call and a multi-agent handoff

“My agent cost $180 yesterday. No idea which tool call drove it.” is the single most common complaint from teams running agent workflows in production. A total run cost is visible. What isn't visible, without purpose-built attribution, is which MCP tool server, which step in the plan, or which agent-to-agent handoff actually generated that number.

That gap matters because “the agent is expensive” isn't something you can act on. “The web-search tool call is 52% of the run's cost” is — it tells you exactly where to look for a fix, whether that's reducing search calls, caching results, or routing that specific tool call to a cheaper model.

Why feature-level attribution alone doesn't resolve this

Tagging every call in an agent workflow with X-Cost-Feature: research-agent answers which feature the spend belongs to — necessary, but coarse. An orchestrator that calls a web-search tool, a document-reader tool, and a code-execution tool, then hands off to a specialist sub-agent, produces one feature-level number that flattens all four of those very different cost sources into a single line. Two runs with identical total cost can have completely different internal cost structures, and feature-level tagging alone can't tell them apart.

The natural instinct — add application logging around each tool call and reconstruct the breakdown from logs after the fact — works until the workflow has more than a couple of steps or any concurrency. Logs from different tool invocations, potentially running in parallel, have to be manually stitched back into a single coherent tree per run, which is exactly the kind of reconstruction work attribution is supposed to eliminate, not require.

The three headers that build the workflow cost tree

These work alongside the standard attribution headers, not instead of them — X-Cost-Feature still names the workflow, X-Cost-Run-ID still groups the run. The MCP-specific headers add tool-level and handoff-level granularity within that existing structure. See the full MCP/A2A attribution reference for Python and TypeScript integration examples.

What the resulting view looks like

The Agent Workflows dashboard turns these headers into a workflow tree per run — each node showing the step, the MCP server involved, tokens used, cost, and latency, so a run that cost $0.83 total resolves into something like a supervisor call at $0.21, a web-search tool call at $0.42, and a document-reader call at $0.06, rather than one undifferentiated total. A cost-by-MCP-server bar chart rolls this up across every run, so the tool driving the most aggregate spend across your whole agent fleet is visible at a glance, not something you have to compute by hand from individual run trees.

Consider a hypothetical research agent that fans a query out across a web-search tool and a document-reader tool, then synthesizes a final answer. Tagging both tool calls with X-Cost-MCP-Server and the shared X-Cost-Parent-Run-Id produces a workflow tree showing the web-search step as the dominant cost driver for that run — the specific, actionable finding that a flat per-run total could never surface on its own. This is illustrative of how the workflow tree behaves, not a specific customer's reported outcome.

Attribution tells you where the cost went. It doesn't stop a concurrent fan-out of subagents from overspending in the first place — that requires a run-level budget ceiling enforced atomically across every subagent sharing the run ID. See how Cognocient stops a runaway multi-agent run before it finishes for how the two capabilities work together on the same run ID.