Cost tracking for MCP servers and agents
Last verified
MCP servers cost tokens, not dollars directly. The server is a local process. What you pay for is the context: every tool definition sits in the model's context on every single request, and every tool result enters the conversation permanently.
Install eight MCP servers with a dozen tools each and you have added a fixed tax to every message you send, before the model does anything.
The three cost sources
1. Tool definitions. Names, descriptions and JSON schemas for every tool from every connected server, in context, on every request. This is the cost people don't see because it never appears in anything they wrote.
2. Tool results. Whatever a tool returns enters the conversation and stays there. An MCP server that reads a file and returns 40,000 tokens has permanently enlarged every subsequent request in that session.
3. Extra turns. Tool use is multi-turn by nature: the model calls, gets a result, reasons, maybe calls again. Each turn resends the accumulated conversation.
Practical consequences: install fewer servers, prefer servers with few, well-described tools over many granular ones, and prefer tools that return summaries rather than raw data. A server that returns a 200-token answer is worth more than one that returns 20,000 tokens for you to filter.
Letting an agent see its own spend
The more interesting direction: expose cost data _to_ the agent.
An agent that can call get_spend() can reason about it — decline an expensive path, pick a cheaper model, stop and ask, or refuse to continue past a threshold. That turns a budget from something you enforce from outside into something the agent participates in.
TKN ships an MCP server (tokn-mcp) that does exactly this:
// claude_desktop_config.json
{
"mcpServers": {
"tkn": { "command": "tokn-mcp" },
},
}It exposes four tools:
| Tool | Returns |
|---|---|
tkn_get_spend | Today's combined spend, tokens, and a per-model breakdown |
tkn_list_watchers | Active models with tokens in/out and cost |
tkn_list_rules | The armed spend rules and how often each has tripped |
tkn_revoke_keys | The kill switch — revoke stored keys |
The last one deserves a warning.
tkn_revoke_keys is destructive and irreversible. An agent that can revoke your keys can take down your production service. Reasonable configurations are: don't expose it, expose it only in a sandbox, or expose it and require human confirmation. "Autonomous agent with a kill switch" sounds elegant and is a genuinely risky default.
What this does not solve
It's still daily. The spend an agent reads comes from provider billing APIs, which report daily. An agent can't watch its own spend rise during a run — it can only check what yesterday and today have cost so far.
For within-run control you need hard guards in your loop: step caps, token budgets, repeated-state checks. Those are enforcement. The MCP tool is awareness, and awareness is not enforcement.
A model asked to be frugal will not reliably be frugal. Giving an agent visibility into cost makes better behaviour possible. It does not make it certain. Keep the hard limits.