Mcpspend
I built MCPSpend because Claude Desktop kept eating my money — here's what I learned An honest writeup of building the first cost-observability tool for the Model Context Protocol — what worked, what surprised me, and the numbers nobody talks about.
The problem nobody was solving It's late 2025. I'm running 4 agents in parallel — Claude Desktop, Cursor, Windsurf, plus a few custom MCP servers I wrote for client work. Bills from Anthropic and OpenAI keep climbing. I check the dashboards and see the totals, but I have zero idea which tool call, which server, which project is actually expensive.
Existing AI observability tools fall in two buckets:
LLM-layer: Helicone, Langfuse, Portkey. They see every chat completion. Brilliant. But invisible to the MCP tool layer — they only see "Claude answered the prompt", not "Claude called read_file 47 times to answer it". Generic analytics: PostHog, Mixpanel. Powerful, but you build the schema yourself. By the time you've instrumented every tools/call, you've shipped half of MCPSpend. I had two options: stitch something together in spreadsheets every month, or build it.
I built it. Here's what 3 weeks of nights-and-weekends produced.
How MCPSpend works (60 seconds)
npx @mcpspend/proxy add That's it. One command. The CLI auto-detects Claude Desktop, Cursor, Windsurf, VS Code, and Claude Code on your machine, finds every MCP server you've configured, and rewrites the config to wrap each one with a transparent proxy.
The proxy sits between your MCP client and your MCP server — same stdio protocol, same JSON-RPC messages going through unchanged. But on every tools/call, the proxy records:
Server name + tool name Latency Success / error Approximate payload size (bytes → tokens via per-model estimates) Then it streams that metadata to api.mcpspend.com/v1/ingest over HTTPS, authenticated with your API key.
What the proxy does not send: the actual tool arguments, the actual tool responses, your file contents, your prompts. Privacy-by-design, not as marketing copy.
The dashboard answers the questions I had "Which tool is eating my budget?" — top-N tools by cost, with gradient bars showing the relative ratios. The top 3 get amber dots so my eye goes there first.
"How much is each agent run actually costing?" — sessions view with drill-down. I can see one Claude Code session that spent 47 cents over 2 hours, mostly on Playwright browser_navigate.
"Will I hit my budget this month?" — linear projection from the daily average. With Slack alerts at 50/80/100% so I don't get surprised.
"Which customer / project drove this month's bill?" — projects assign each MCP server to a label. Per-project totals. Eventually CSV export for the CFO.
The 3 things that surprised me building this
- MCP tool calls happen ~30x more than LLM calls A single prompt to Claude Desktop with "find all the React components that import this hook" triggers maybe one LLM round-trip — but 50-80 MCP tool calls (filesystem reads, greps, etc.). Existing tools that count "requests" undercount AI agent activity by an order of magnitude.
This was the entire reason MCPSpend's free tier is 25,000 calls/month instead of 10K. The unit is fundamentally different.
- Closed IDEs are a moat, not a limitation Cursor and Claude Desktop don't expose hooks. You can't wrap the SDK. The only way to observe what they're doing is from outside — by intercepting the MCP protocol.
This is bad news for tools that work via SDK instrumentation (Helicone, Langfuse). It's great news for a transparent stdio proxy — the proxy doesn't care if the consumer is closed source. MCPSpend works in IDEs where every other observability tool is blind. I didn't fully appreciate this until 2 weeks in.
- Auto-detect saves the product The first version required users to manually edit JSON config files. Setup took 10 minutes per IDE. Drop-off was brutal.
V2 added add mode that auto-detects every MCP client on your machine, lists the servers it found, asks for confirmation, then rewrites the configs in-place (with .mcpspend.bak backups). Setup is now under 60 seconds. Conversion to "first tool call observed" went from ~30% to ~80%.
If your product depends on config-file editing, autodetect is not nice-to-have — it's the difference between shipping and not shipping.
Server Config
{
"mcpServers": {
"mcpspend": {
"command": "npx",
"args": [
"-y",
"@mcpspend/mcp-server@latest"
],
"env": {
"MCPSPEND_API_KEY": "<YOUR_MCPSPEND_API_KEY>"
}
}
}
}