MCP server · stdio
Let an agent look up its own spend
Ask your coding agent what this session has cost so far and it will make something up, because it has no way to know. Connect it to tokenstat and it does know. It can check its own spend before it starts a big refactor, tell you which model it should be using for the job, file the work it could not finish, and kick off the jobs you would otherwise queue by hand.
Setup
One line, and it is done
In Claude Code, register it with the CLI:
$ claude mcp add tokenstat -- tokenstat mcp
Any other MCP client takes the same command and arguments in its own config:
{
"mcpServers": {
"tokenstat": { "command": "tokenstat", "args": ["mcp"] }
}
}It reads the archive, so run tokenstat scan once first (or let the hourly schedule the installer set up do it).
What it can do once connected
Four things it could not do before
Answer for itself
“How much have I spent on this project this week?” stops being a question you have to leave the conversation to answer. It reads the real archive, so the number is the same one your own reports show.
- totals
- models
- daily
- weekly
- projects
- budget_status
- doctor
- scan
Put down what it cannot finish
Work that falls out of a long session usually falls on the floor. An agent that can file it, pick it back up next time, or hand it to another agent loses less of it.
- task_list
- task_create
- task_update
- task_remove
- task_delegate
Set the repetitive work running
The jobs you would otherwise start by hand every morning, scheduled from inside the conversation that decided they were needed, each with a budget it stops at rather than one it reports afterwards.
- automation_list
- automation_create
- automation_update
- automation_enable
- automation_run
- automation_runs
- automation_queue
- automation_set_queue
Build a bigger job out of small ones
Chain agents, shell steps, and a point where a person has to say yes. Asking for one produces a draft you read before anything runs, never a job that started itself.
- workflow_list
- workflow_get
- workflow_create
- workflow_update
- workflow_remove
- workflow_run
- workflow_runs
- workflow_continue
- workflow_kill
- workflow_transcript
- workflow_design
What it cannot do
Nothing here leaves the machine
Handing an agent your usage history is a fair thing to be careful about. This one never goes anywhere: the server has no network access, cannot sync, and cannot publish. What it hands back is exactly what tokenstat summary prints in your own terminal, real project names and all, because that is the useful version and it stays on your machine.
Nothing on a timer writes to git. An automation may run an agent, and that agent may ask a person, but a schedule on its own never commits.