See where your AI tokens go — and how to spend less of them.
TokenBurnRate is an MCP server + CLI that logs every Claude / GPT / Gemini API call locally, shows you a cost dashboard in your terminal, and tells you exactly how to reduce that cost.
⬡ token-tracker LAST 7 DAYS
────────────────────────────────────────────────────────────────────────
Overview
Total cost $18.7421 (~$80.59/month est.)
API calls 347
Input tokens 4.82M
Cache reads 620K (11.4% hit rate)
Daily Cost
Mon Jun 02 ████████████░░░░░░░░░░░░ $2.14
Tue Jun 03 ████████████████████░░░░ $3.82
Thu Jun 05 ████████████████████████ $4.51
💡 Optimization Hints saves $31.20/mo
● CRIT Prompt cache barely used
Cache hit rate: 11.4% — target is 30–60%
Action: Move static content to top of messages
Est. saving: $12.40/month
● HIGH Expensive model doing test generation
104 test-gen calls on Sonnet costing $2.25/week
Action: Route to claude-haiku-4-5, saves 80%
Est. saving: $7.80/monthnpm install -g token-tracker-mcpOr run without installing:
npx token-tracker-mcp reportRelated MCP server: Tessera MCP Server
node scripts/setup.jsOr add manually to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"token-tracker": {
"command": "token-tracker",
"args": ["serve"]
}
}
}Restart Claude Desktop. Done.
Command | Description |
| Full 7-day dashboard |
| Monthly report |
| Today only |
| Optimization hints ranked by $ saving |
| Deep-dive on one hint |
| One-line: cost · cache % · top hint |
| Budget gauges |
| Pricing table for all models |
| Raw CSV export |
Tool | Description |
| Log an API call — auto-calculates cost |
| Summary for today / week / month / all |
| Ranked optimization hints with $ savings |
| Deep-dive on a specific hint |
| Set a daily / weekly / monthly spend limit |
| Sessions ranked by cost |
| Pricing table |
| CSV dump |
8 deterministic rules — no LLM calls, runs instantly on your local data:
Hint | Triggers when |
| Cache hit rate < 30% |
| Test gen running on Sonnet / Opus |
| Debugging on Opus |
| Output / input ratio > 0.35 |
| Any session costs 3× your average |
| Avg tokens / call > 8K |
| Sessions with 30+ high-token calls |
| 100% traffic on one expensive model |
Each hint includes severity · evidence · recommended action · estimated monthly saving.
All data stored at ~/.token-tracker/usage.db (SQLite).
Nothing leaves your machine. No telemetry, no account required.
git clone https://github.com/nikhilnt1234/TokenBurnRate.git
cd TokenBurnRate
npm install --ignore-scripts
npx tsup
npm testTeam / Supabase backend (multi-user shared dashboard)
Weekly email digest
Slack / webhook alerts
macOS menubar app
MIT © 2026 Nikhil T
Export usage data as CSV text.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'export' but does not disclose whether data is read-only, any limits, or side effects. Minimal transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (5 words) and front-loaded with the main action. However, it is under-specified for the task, so conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 optional parameter and no output schema, the description should explain what 'usage data' includes and how the period parameter works. It does neither, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage on the single parameter 'period'. The description does not explain the parameter or its enum values, nor mention that it controls the time range. Fails to compensate for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'export' and resource 'usage data' with format 'CSV text'. It distinguishes from sibling tools like get_hints or get_summary which are retrieval tools, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_summary or log_usage. The description lacks context for choosing export_csv over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a deep-dive on a specific optimisation hint by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| hint_id | Yes | Hint ID from get_hints, e.g. 'cache-utilization' | |
| period | No | week |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic action. For a read operation, it lacks details on side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose but omits details on period usage and return value, which would be beneficial given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes hint_id with an example, but period is only listed with enum/default, lacking explanation. The tool description does not compensate for the missing period semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'optimisation hint' with the action 'deep-dive', which distinguishes it from sibling tools like get_hints that list hints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific hint ID is known but does not explicitly state when to use or when not to use, nor does it reference alternatives from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse your token usage and return ranked optimisation hints with estimated monthly savings. Call this any time you want actionable advice on reducing your AI spend.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | week | |
| min_saving | No | Only return hints with estimated monthly saving above this USD threshold |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It doesn't disclose potential side effects, prerequisites, or whether the tool is read-only. The behavior is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and purpose, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple analysis tool with no output schema, the description covers purpose and usage. It could mention output format or data recency, but overall it is sufficient alongside sibling names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only 'min_saving' has a description. The tool description adds no further context for parameters, leaving the agent to infer from enum values and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyse your token usage and return ranked optimisation hints with estimated monthly savings.' It uses specific verbs and resources, and distinguishes from siblings like get_hint_detail and get_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this any time you want actionable advice on reducing your AI spend.' This provides clear when-to-use guidance, though it does not list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get token usage and cost summary for a time period.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | week | |
| project | No | ||
| model | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It implies a read operation but does not explicitly state read-only behavior, authentication needs, or any side effects. More behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it very concise and easy to scan. However, the extreme brevity sacrifices necessary detail, and the structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with no schema descriptions, no annotations, and no output schema, the description is woefully incomplete. It fails to explain the summary content, how to filter by project/model, default behavior, or return format. A much richer description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain all parameters. It only alludes to the 'period' parameter via 'for a time period,' but does not mention 'project' or 'model' parameters. These remain undefined, reducing clarity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a token usage and cost summary for a time period. It distinguishes itself from sibling tools like export_csv (exports data) and get_hint_detail (per-hint details). However, it does not specify what exactly the summary contains (e.g., totals, breakdowns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_hint_detail for per-hint costs or export_csv for raw data. The agent must infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show known models with their pricing per 1M tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation (showing models), but fails to mention whether authentication is required, if the list is exhaustive or curated, or if pricing information is live or cached. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's core function. Every word earns its place, and there is no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It could mention whether the list includes all models or only those available to the user, but overall it provides sufficient context for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. The description does not need to add parameter information. The baseline score of 4 applies because no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: showing known models with their pricing per 1M tokens. It uses a specific verb 'show' and resource 'known models', and the mention of pricing distinguishes it from sibling tools like list_sessions or get_hints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention that this tool lists all available models without filtering, or that sibling tools like get_hints handle different data. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent sessions with their cost and token totals.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'recent' without defining the timeframe (e.g., last hour, last 24 hours). It doesn't mention ordering, pagination, error conditions, or whether any state is mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise but lacks substance. It is front-loaded with the verb 'List', but omits important details. While it avoids verbosity, it could be longer to include parameter and usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain the return format beyond 'cost and token totals'. It does not mention whether results are sorted, if sessions include metadata like IDs or timestamps, or how 'recent' is determined. For a listing tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. It adds no value beyond what the schema itself provides (type, default, min/max). The description should explain how 'limit' affects the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('recent sessions'), and mentions the output includes cost and token totals. Among sibling tools (export_csv, get_hint_detail, etc.), 'list_sessions' is uniquely about sessions, so it is distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not provide context such as prerequisites, typical use cases, or when not to use it. For example, it doesn't clarify if this is for auditing, monitoring, or debugging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a single LLM API call with token counts. Call this after every Claude/GPT/Gemini response.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID, e.g. claude-sonnet-4-6 | |
| input_tokens | Yes | ||
| output_tokens | Yes | ||
| session_id | No | default | |
| provider | No | anthropic | |
| cache_read_tokens | No | ||
| cache_write_tokens | No | ||
| task_type | No | e.g. coding, debugging, writing | |
| project | No | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions logging but does not state whether the operation is idempotent, how duplicates are handled, or if there are side effects like rate limits. Lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence that is front-loaded with the core purpose. Efficient and direct, though it could benefit from brief elaboration on optional fields. Waste is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, very low schema description coverage (20%), no output schema, and no annotations, the description is far from complete. It omits behavioral expectations, return values, and explanations for most parameters, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (2 of 10 parameters described). The tool description adds no parameter details beyond the schema, leaving most parameters (session_id, provider, cache tokens, etc.) unexplained. Fails to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool logs a single LLM API call with token counts, and distinguishes it from sibling tools that export, hint, or summarize. The verb 'log' and resource 'LLM API call' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use instruction: 'Call this after every Claude/GPT/Gemini response.' While no explicit when-not-to or alternatives are given, the context from sibling tools makes misuse unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a spending budget with alert threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Name for this budget, e.g. 'dev-work' | |
| period | Yes | ||
| limit_usd | Yes | USD limit for the period | |
| alert_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a write/mutation operation ('Set'), but without annotations, it fails to disclose important behavioral traits such as whether it overwrites existing budgets, requires authentication, or has side effects. The description does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is too brief to cover essential aspects like behavioral details or usage guidance. Conciseness is positive but not at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what happens upon execution (e.g., success, error conditions, or whether budgets can overlap). The tool is under-documented for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes 3 parameters with descriptions or constraints (label, limit_usd, alert_pct with default). The description adds 'alert threshold' which corresponds to alert_pct, but overall does not significantly enhance understanding beyond the schema. With 50% schema coverage, the description provides marginal added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and what is being set ('a spending budget with alert threshold'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools, but the sibling list contains no other budget-related tools, so purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, restrictions, or conditions under which this tool should be preferred or avoided. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0export_csvget_hint_detailget_hintsget_summarylist_modelslist_sessionslog_usageset_budgetAll eight tools have clearly distinct purposes: logging, summarizing, hinting, listing models/sessions, setting budgets, and exporting. No two tools overlap in functionality, ensuring unambiguous selection.
Tool names follow a consistent verb_noun pattern with lowercase underscores (e.g., list_models, set_budget, export_csv). No mixing of conventions or verb styles.
With eight tools, the server covers a focused domain (AI usage tracking and optimization) without being too sparse or overwhelming. Each tool serves a distinct and necessary function.
The tool surface covers core workflows: logging, viewing summaries, getting optimization hints, listing models/sessions, setting budgets, and exporting. Minor gap: no tool to delete or reset data, but the domain is primarily read-heavy and logging.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Agent Cost Allocator MCP — multi-tenant LLM cost attribution for chargeback billing. Companion to
Exact Claude API cost calc with real cache economics, plus a tiktoken-misuse scanner.
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nikhilnt1234/TokenBurnRate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
