The openclaw-cost-tracker-mcp server provides AI agent token-cost telemetry, attribution, anomaly detection, and quota management to prevent surprise bills and optimize LLM spend.
Cost Overview (cost_overview): Total spend, request counts, per-provider breakdowns, top agents/models, and anomaly counts for a configurable time window.
Per-Agent Attribution (costs_by_agent): Break down costs by agent with average cost-per-request and share of total spend.
Per-Provider Breakdown (costs_by_provider): Spend, request counts, token counts, and share per provider (Anthropic, OpenAI, Gemini, Ollama, AWS Bedrock).
Anomaly Detection (find_cost_anomalies): Flag requests exceeding N× an agent's median cost — catches runaway loops, accidental huge context pastes, and silent billing re-routes.
Top Cost Drivers (top_cost_drivers): Flat list of highest-spending agents and models for quick 'where is our money going?' digests.
Routing Recommendations (model_routing_recommendations): Suggest cheaper providers/models for specific agents based on actual usage, with concrete 30-day savings estimates.
Monthly Forecast (forecast_monthly_cost): Project total and per-provider spend for the next 30 days based on observed run rate.
Quota-Window Awareness (current_quota_usage, predict_429_in_window, recommend_throttle_target): Monitor current quota utilization, predict when you'll hit a 429 rate limit (by tokens, requests, etc.), and get recommended throttle targets to avoid rate limiting.
Data is read from standard JSONL logs and is designed to surface failure modes missed by vendor dashboards, such as multi-day reporting lag and lack of per-agent attribution.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@openclaw-cost-tracker-mcp show me my top cost drivers this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for AI agent token-cost telemetry — built for the operator who woke up to a surprise bill. Catches the failure modes vendor dashboards miss: silent re-routing to API billing (HERMES.md bug, 1,464 upvotes), unattended
/loopovernight burns ($6k in 26 hours, real story), per-agent attribution buried behind aggregate provider totals, multi-day dashboard lag that surfaces the spike after the money is gone. Cross-provider: Anthropic, OpenAI, Gemini, Ollama, AWS Bedrock. Per-agent + per-provider attribution, spend-spike anomaly detection (per-agent median × threshold), cheaper-routing recommendations with 30-day savings estimates, monthly forecast. Reads any cost-log JSONL with the standard{request_id, timestamp, provider, model, agent_id, prompt_tokens, completion_tokens, cost_usd}schema. OpenClaw operators get native~/.openclaw/cost-logs/parsing; other deployments wrap their provider calls with the included logging shim or commission a Custom MCP Build adapter. Keywords: Claude API cost surprise, /loop overnight burn, HERMES.md billing routing, dashboard lag, AI agent FinOps, LLM cost attribution, token spend monitoring.
Production AI deployments are leaking money in ways the vendor dashboards don't surface in time. Real stories from the last 30 days on r/ClaudeAI:
A developer woke up to a $6,000 overnight burn from a single /loop command running 26 hours unattended on Claude Opus 4.7 (1,175 upvotes, 314 comments, May 1 2026). The Anthropic dashboard lagged by days; the spike was invisible until the limit email landed. Verbatim from the OP: "By the time it shows a spike, the money is already spent."
Another lost $200 because a string in a git commit silently routed Claude Code billing from Max subscription to API tier — the HERMES.md bug (1,464 upvotes, 202 comments). VENDOR-ACKNOWLEDGED: Om Patel @om_patel5 thread on X (1.4M views, 4.6K likes) elicited an Anthropic-side reply confirming "this was a bug with the 3rd party harness detection [and how we pull git status into the system prompt]" — i.e., it's a real bug in how Anthropic detects 3rd-party harnesses + ingests git context, not an isolated user error. Cost-tracker is the defense layer regardless of patch timing.
A third left a test loop running and woke up to a surprise $80 Claude bill. Verbatim: "No alerts. No cap. No warning. Just a bill."
A fourth got $1,800 in API charges in two days after the built-in claude-code-guide agent recommended a command that bypasses Max-plan billing.
In every case the dashboard lagged, the per-agent attribution was invisible, and Anthropic's own hard-cap mechanism either failed or arrived too late. This MCP server surfaces per-agent + per-provider cost attribution live, queryable from inside Claude or any MCP-aware client, before the bill arrives:
> claude: where did our LLM spend go this week?
[MCP tools: cost_overview + top_cost_drivers]
Total spend last 7 days: $42.18
By provider:
Anthropic $30.40 (72%) — claude-sonnet-4 dominates
OpenAI $9.20 (22%) — chat-bot agent
Gemini $1.86 (4%) — cron-summarizer (cheap-route working)
Ollama $0.00 (local, free)
Top 3 cost drivers:
data-extraction-agent $28.50 (68%)
chat-bot $9.20 (22%)
cron-summarizer $1.86 (4%)
1 anomaly flagged — see find_cost_anomalies for details.> claude: any cheaper-routing opportunities?
[MCP tool: model_routing_recommendations]
Recommendation: data-extraction-agent currently runs claude-sonnet-4
with avg 400-token completions — extraction-style work that
gemini-2.5-flash usually handles at ~95% quality for ~5% the cost.
Estimated savings: $27.10/30d if migrated. Test on a 10% slice first.v1.1 — quota-window awareness. The cost tracker now also answers "will my agent hit a 429 before the window resets?" before it actually does. This is the HERMES.md / overnight-burn detector — projecting per-dimension exhaustion ETA from your active burn rate vs the rate-limit headers your provider already returns:
> claude: am I about to 429?
[MCP tool: predict_429_in_window]
severity: CRITICAL
provider: anthropic
burn_rate_tokens_per_min: 8000
dimension_predictions:
tokens : will 429 in ~6.5 min (resets in 22 min) ⚠
output_tokens : will 429 in ~11.7 min (resets in 22 min) ⚠
input_tokens : safe through reset (headroom 70k at reset)
requests : safe through reset (headroom 858 at reset)
summary: tokens projected to 429 in ~6.5 min at current burn (8000/min).
Window resets in 22 min — throttle now.> claude: what burn rate keeps me safe?
[MCP tool: recommend_throttle_target target_buffer_pct=10]
target_buffer_pct: 10
targets:
tokens : current 8000/min, max safe 545/min — must throttle
output_tokens : current 3000/min, max safe 1136/min — must throttle
input_tokens : current 5000/min, max safe 6818/min — safe
requests : current 1/min, max safe 35/min — safe
summary: throttle required on tokens, output_tokens to keep 10% buffer at reset.Related MCP server: nikhilnt
openclaw-cost-tracker-mcpFour things existing tools (provider billing dashboards, generic FinOps tools, custom scripts, even paid SaaS like Lava or AgentShield) don't do well together:
Per-agent attribution, not just per-provider totals. Provider dashboards show "$X spent on Anthropic" — they can't tell you which of your six agents drove 78% of that. Cost tracker reads per-request cost-log JSONL and aggregates with the agent_id intact.
Cost-spike anomaly detection per agent. A single 120k-token paste into chat — or an unattended /loop running overnight — costs more than a week of normal traffic. The default 3x-median-per-agent threshold flags those before they show up in the month-end bill. Catches the same shape as the $6k overnight thread and the silent re-routing patterns that vendor dashboards miss.
Routing recommendations grounded in actual usage. Generic "use cheaper models" advice is useless. This server identifies specific agents whose volume + completion-length pattern suggests a cheaper provider would deliver the same outcome, with concrete 30-day savings estimates.
Local-only, MCP-native, no traffic interception. Lava + similar paid gateways sit between your app and the provider — your traffic routes through them. AgentShield is a callback for LangChain/CrewAI/OpenAI SDK, not MCP. Cost-tracker is read-only: it parses your existing cost logs and surfaces them via MCP tools your Claude conversation can query directly. No proxy, no traffic routing, no subscription, no vendor lock-in.
Built for the production-AI operator running real workloads with real spend that matters — whether on OpenClaw, Claude Code with claude -p, raw Anthropic API, OpenAI Assistants, or any combination.
Tool | What it returns |
| Total spend + by-provider + top agents + top models + anomaly count for a window |
| Per-agent breakdown with avg-cost-per-request + share of total |
| Per-provider breakdown with token counts |
| Requests flagged as 3x+ above their agent's median cost |
| Top N spending agents + models, no other noise |
| Specific cheaper-model suggestions with 30d savings estimates |
| Projects 30-day total + per-provider with confidence note |
| Per-dimension rate-limit utilization + most-pressured-dimension headline |
| Projects per-dimension 429 ETA from recent burn rate. CRITICAL/WARNING/INFO severity |
| Max safe burn rate per dimension to land at |
Resources:
cost://overview — 7-day snapshot
cost://forecast — 30-day projection
cost://anomalies — recent flagged anomalies
cost://quota (v1.1) — current quota-state snapshot
Prompts:
diagnose-cost-spike — walk a recent spike to its root cause + corrective action
weekly-cost-digest — 200-word weekly cost digest
diagnose-quota-pressure (v1.1) — walk current quota + burn rate, recommend a specific throttle action
pip install openclaw-cost-tracker-mcpAfter install, run the bundled demo to see the four representative cost analyses fire against the mock backend:
openclaw-cost-tracker-mcp-demoYou'll see: total spend $3 across 4 providers (anthropic / openai / gemini / ollama), one critical 24.6× spend anomaly on chat-bot, two cheaper-routing recommendations ($2.61/30d savings), and an Anthropic quota snapshot showing tokens at 87% with 22 minutes until reset. No external I/O, no API keys — safe to run anywhere. Useful first-30-seconds check before pointing at your real cost-log JSONL.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"openclaw-cost": {
"command": "python",
"args": ["-m", "openclaw_cost_tracker_mcp"],
"env": {
"OPENCLAW_COST_BACKEND": "mock"
}
}
}
}Backend | Status | Description |
| ✅ v1.0 | Sample data with deliberate anomalies + routing opportunities for protocol verification. v1.1: includes near-exhausted token-quota snapshot + recent loop-burst entries so |
| ✅ v1.0 | Parses OpenClaw's native cost-log JSONL files (default |
| ⏳ v1.2 | Reads Anthropic + OpenAI billing APIs directly (no log shim required) |
Each line is one JSON record:
{"request_id":"req-abc123","timestamp":"2026-05-04T12:34:56Z","provider":"anthropic","model":"claude-sonnet-4","agent_id":"data-extraction-agent","skill_id":"extract-structured-data","prompt_tokens":8500,"completion_tokens":600,"total_tokens":9100,"cost_usd":0.0345,"duration_ms":4823}If your OpenClaw deployment doesn't emit this format, wrap your provider calls with a small logging shim — sample shim in examples/.
Version | Scope | Status |
v1.0 | mock + openclaw-jsonl backends, 7 tools / 3 resources / 2 prompts, anomaly detection + routing + forecast, GitHub Actions CI matrix, PyPI Trusted Publishing | ✅ |
v1.1 | Quota-window awareness — | ✅ |
v1.2 |
| ⏳ |
v1.x | Per-channel cost attribution; webhook emitter for budget + quota alerts | ⏳ |
If your AI deployment doesn't use OpenClaw's cost-log format — different agent harness, custom logging, AWS Bedrock metering, vendor billing API — and you want the same attribution + anomaly + routing visibility, that's a Custom MCP Build engagement.
Tier | Scope | Investment | Timeline |
Simple | Single backend adapter for your existing cost-data source | $8,000–$10,000 | 1–2 weeks |
Standard | Custom backend + custom anomaly rules + integration with your alerting | $15,000–$20,000 | 2–4 weeks |
Complex | Multi-backend federation + budget enforcement + custom routing logic | $25,000–$35,000 | 4–8 weeks |
To engage:
Email hello@temhan.dev with subject Custom MCP Build inquiry
Include: a 1-paragraph description of your stack + which tier you're considering
Reply within 2 business days with a 30-min discovery call slot
This server is part of a production-AI infrastructure MCP suite — companion to silentwatch-mcp (cron silent-failure detection) and openclaw-health-mcp (deployment health). Install all three for full operational visibility.
If you're running production AI and want an outside practitioner to score readiness, find the failure patterns already present (cost overruns being one of the most common), and write the corrective-action plan:
Tier | Scope | Investment | Timeline |
Audit Lite | One system, top-5 findings, written report | $1,500 | 1 week |
Audit Standard | Full audit, all 14 patterns, 5 Cs findings, 90-day follow-up | $3,000 | 2–3 weeks |
Audit + Workshop | Standard audit + 2-day team workshop + first monthly audit included | $7,500 | 3–4 weeks |
Same email channel: hello@temhan.dev with subject AI audit inquiry.
PRs welcome. Backends are pluggable — see src/openclaw_cost_tracker_mcp/backends/ for the contract.
To add a new backend:
Subclass CostBackend in backends/<your_backend>.py
Implement get_entries() (cost telemetry); optionally override get_latest_quota_state() if your data source carries rate-limit headers (default returns None for graceful degrade)
Register in backends/__init__.py
Add tests in tests/test_backend_<your_backend>.py
Bug reports + feature requests: open a GitHub issue.
MIT — see LICENSE.
Production-AI MCP Suite (Gumroad bundle) — this server plus 4 others in one curated bundle with a decision tree, day-one drill, and Custom MCP Build CTA. $29.
silentwatch-mcp — cron silent-failure detection
openclaw-health-mcp — deployment health
openclaw-skill-vetter-mcp — ClawHub skill security vetting
openclaw-upgrade-orchestrator-mcp — read-only upgrade advisor + provider-side regression detection (v1.2)
openclaw-output-vetter-mcp — agent claim verification (inline grounding-check + swallowed-exception scanner + multi-turn transcript review)
AI Production Discipline Framework — Notion template, $19 — the methodology these MCP tools implement (cost overruns are pattern P3.x in the catalog)
SPEC.md — full server design
Built by Temur Khan — production AI engineer. Contact: hello@temhan.dev
Top-level cost summary for a window — total spend, request count, by-provider breakdown, top agents, top models, anomaly count. Use this first for a single-pane view.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Lookback window in hours (default 168 = 7 days, max 720 = 30 days) | |
| top_n | No | How many top agents + models to include (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Description implies read-only behavior (cost summary), but does not explicitly state non-destructiveness, rate limits, or other traits.
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?
Two sentences with zero waste. Front-loaded with output items. Every sentence earns its place.
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?
No output schema, but description lists all expected return components (total spend, request count, breakdowns, top agents/models, anomalies). Adequate for a top-level summary tool.
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 coverage is 100% (both parameters described). Description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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?
Description clearly states verb (summary) and specific resource (top-level cost for a window). It lists the exact components returned and distinguishes from siblings via 'use this first for a single-pane view'.
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?
Explicitly says 'Use this first for a single-pane view', implying it's the entry point. No explicit when-not or alternatives, but the sibling list provides context for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-agent cost breakdown — total spend + request count + avg cost-per-request + primary provider/model + share of total spend, sorted by cost descending.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No |
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 does not disclose whether the tool is read-only, destructive, or has auth/rate limits. Since it likely just queries data, a note about idempotency would be beneficial.
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 that efficiently lists all output fields and the sort order. No unnecessary words.
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 explains the output well but omits the single input parameter entirely. Given no output schema, this is a notable gap for input comprehension.
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 has one optional parameter (window_hours) with 0% schema description coverage. The description does not mention this parameter at all, failing to explain its meaning or effect on results. The description adds no value beyond the schema.
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 provides a per-agent cost breakdown with specific metrics (total spend, request count, avg cost-per-request, primary provider/model, share of total spend, sorted by cost descending). This distinguishes it from sibling tools like cost_overview (likely overall) or costs_by_provider.
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 usage is implied from the purpose (use when you need per-agent costs), but there is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no mention of 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.
Per-provider cost breakdown — total spend + request count + token counts + share of total, sorted by cost descending.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is responsible for behavioral disclosure. It mentions output metrics and sorting but omits key details such as that it is a read-only operation, how the time window (window_hours) affects results, or any limits/pagination.
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 front-loads the key information (what the tool returns and how it is sorted), with no superfluous content.
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 has one optional parameter, no output schema, and several siblings, the description fails to explain the parameter or provide usage guidance, making it incomplete despite adequately covering purpose and basic output.
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 has one parameter (window_hours) with 0% description coverage in the schema. The description does not mention window_hours at all, leaving the agent unaware of how to specify the time range for the breakdown.
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 provides a per-provider cost breakdown with specific metrics (total spend, request count, token counts, share of total) sorted by cost descending, which distinguishes it from siblings like costs_by_agent and cost_overview.
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 the tool is for per-provider breakdowns but does not explicitly state when to use it over alternatives like costs_by_agent or cost_overview, nor does it provide exclusions or context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requests whose cost is threshold_multiplierx or more above their agent's median request cost. Default 3.0x. Surfaces giant-context-paste accidents, runaway loops, model regressions, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | ||
| threshold_multiplier | No | Multiplier above agent median to flag (default 3.0, min 1.5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool flags requests exceeding a threshold, but does not disclose if it modifies data, requires permissions, or the format of returned anomalies. This is adequate but leaves gaps.
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?
Two sentences suffice to convey purpose, examples, and default values. Information is front-loaded and no unnecessary words are present.
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 no output schema, the description could elaborate on the output format. However, the context of sibling cost tools and the clear examples provide sufficient completeness for a diagnostic tool.
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 coverage is 50% with only threshold_multiplier having a description. The tool description adds meaning by explaining the purpose of threshold_multiplier (default 3.0x, min 1.5) and implies window_hours as a time window. This provides useful context beyond the schema.
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 uses a specific verb 'find' and resource 'cost anomalies', clearly distinguishes from sibling tools like cost_overview or top_cost_drivers, and provides concrete use cases (giant-context-paste accidents, runaway loops).
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 for detecting anomalous cost spikes with examples, but does not explicitly state when not to use it or compare to alternatives. However, the context of sibling tools makes its purpose distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Projects 30-day total spend from the observed window's run rate. Returns per-provider 30d projection + confidence note. Re-run with longer window for stability.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Hours of observed data to project from (default 168 = 7 days) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a per-provider projection and confidence note and suggests re-running for stability, but does not explicitly state whether the operation is read-only or discuss any side effects or permissions 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 three short, front-loaded sentences with no filler. Each sentence adds value: purpose, return structure, and usage advice. It is efficient and well-structured.
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 tool with one optional parameter and no output schema, the description adequately covers what it does and returns (per-provider projection, confidence note). It is mostly complete, though it could specify the format of the projection or confidence level more precisely.
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 provides 100% coverage (window_hours with description and default). The description adds no new parameter meaning beyond the schema, only context about stability. Baseline 3 is appropriate as the description does not detract but adds minimal extra value.
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 projects 30-day total spend from observed run rate, with a specific verb ('projects') and resource ('30-day total spend'). It distinguishes from sibling tools like cost_overview or costs_by_provider by focusing on forecasting rather than current 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?
The description advises re-running with a longer window for stability, implying when to adjust the parameter, but it does not explicitly state when to use this tool versus alternatives like find_cost_anomalies or top_cost_drivers. No when-not or comparator guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggestions to route some volume to cheaper providers/models — e.g., claude-sonnet-4 → gemini-2.5-flash for extraction-style work, gpt-4o → gpt-4o-mini for short chats. Each rec includes 30d estimated savings.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Window over which to find candidates (default 720 = 30 days) |
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 lacks details on side effects (e.g., does it modify anything?), permissions, limitations, or how suggestions are generated. The description only states output (suggestions with savings) but not behavior beyond that.
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 main purpose, and uses concrete examples to clarify. Every sentence adds value without redundancy.
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 is adequate for a recommendation tool but lacks details on output format, number of suggestions, or prerequisites (e.g., required cost data). Without output schema, more behavioral context would be helpful for an agent to use it correctly.
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 single parameter 'window_hours' is fully described in the schema (coverage 100%). The description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.
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 provides suggestions to route volume to cheaper providers/models, with specific examples and mention of 30d estimated savings. It is easily distinguishable from sibling tools which focus on cost analysis rather than recommendations.
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 does not explicitly state when to use this tool versus alternatives. While the sibling tool names give implicit context, there is no guidance on when to recommend routing vs. other cost actions, or exclusions for certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Highest-spend agents + models in the window — flat list, no per-provider or anomaly noise. Useful for 'where's our money going' digest format.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | ||
| top_n | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are a flat list without per-provider or anomaly noise, which is sufficient for a simple query tool. Lacks mention of data freshness or side effects, but none expected.
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?
One concise sentence plus a usage suggestion; no filler words. Front-loaded with key 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 low complexity (2 optional params, no output schema), description adequately covers purpose, format, and use case. Could add details on output fields or ordering, but not critical for a digest.
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 coverage is 0%, so description must compensate. It does not explicitly explain window_hours or top_n parameters, only implying a time window and top N via context. Defaults are in schema but not described.
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?
Description explicitly states it identifies 'highest-spend agents + models' and contrasts with siblings by saying 'flat list, no per-provider or anomaly noise,' making purpose and differentiation 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?
Explicitly suggests use case: 'where's our money going' digest format, and implicitly advises against using when per-provider breakdowns or anomalies are needed, referencing sibling tools.
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.0cost_overviewcosts_by_agentcosts_by_providerfind_cost_anomaliesforecast_monthly_costmodel_routing_recommendationstop_cost_driversEach tool targets a distinct cost analysis aspect: overview, agent/provider breakdown, anomalies, forecasting, recommendations, and top drivers. No overlap in functionality.
All tool names use consistent lowercase underscore pattern, clearly indicating their purpose (e.g., cost_overview, find_cost_anomalies). Pattern is predictable and readable.
Seven tools is ideal for a focused cost tracker; each tool covers a specific need without redundancy or bloat.
Covers core cost analysis needs (overview, breakdowns, anomalies, forecasting, optimization). Minor gaps like filtering or export are acceptable given the scope.
Analytics for MCP servers. Query your tool calls, first-call success, retries and schema cost.
Agent Cost Allocator MCP — multi-tenant LLM cost attribution for chargeback billing. Companion to
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
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/temurkhan13/openclaw-cost-tracker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
