Loading ToolBench
Local MCP server that surfaces real-time Claude.ai subscription usage (5h/7d), forecasts burn rate, and gates expensive operations before they run.
mcp-token-saver provides 5 well-named, focused tools with detailed descriptions and explicit input schemas. However, schema completeness varies significantly: some tools use bare zod schemas without validation constraints, parameter descriptions are present but inconsistent in depth, and output schemas are only partially documented in code. Tool names follow the verb_noun convention well (usage_status, usage_forecast, should_proceed, usage_delta, cache_stats). Descriptions are detailed (100-150 chars average) and explain WHAT, WHEN, and prerequisites clearly. The main weakness is incomplete parameter validation (no explicit min/max constraints in schemas for numeric fields) and undocumented output structures that would force LLMs to infer response shapes.
Compute Anthropic prompt cache hit rate from the latest Claude Code session log. Low hit rate signals wasted tokens — usually caused by reordering tools or system prompt mid-session.
Decide whether to proceed with a task given current usage. Returns proceed/downgrade/abort. Call BEFORE producing large responses, doing huge file reads, or starting expensive operations.
Track real cost of a single task. action='mark' saves baseline, action='measure' returns delta in % of session/weekly used. Replaces theoretical cost estimates with real ones.
Compute burn rate and ETA to 100% based on logged usage history. Tells you whether you'll hit the limit before the next reset.
Fetch real-time Claude.ai subscription usage (5h session and 7d weekly utilization, reset times, extra credits) from the same endpoint Claude Code's IDE bar uses. Reads OAuth token from ~/.claude/.credentials.json. Auto-logs to history.
Input schemas lack validation constraints. cacheStats.last_n declares .positive().max(200) in code but the exported schema object shows only raw zod descriptors without constraint enforcement visible to the protocol layer. Numeric parameters (last_n: positive, max 200) have constraints defined in code but not reflected in formal JSON Schema output that LLMs would parse. This forces LLMs to rely on description text rather than machine-readable constraints.
Output schemas are undocumented in tool definitions. While cacheStats.ts shows partial return structure in the source (tokens object with cache_read, cache_creation, fresh_input, output; session_log, messages_analyzed, cache_hit_rate_pct), the MCP tool definition in server.ts registers no schema for the return type. LLMs cannot infer what fields to expect, risking parsing errors and forcing them to extract data via trial-and-error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Missing error handling guidance in descriptions. Tools like usage_status ('Reads OAuth token from ~/.claude/.credentials.json') and cache_stats ('No Claude Code project logs found') indicate error cases that might occur, but error descriptions do not tell the LLM what to do next (e.g., 'If no logs found, ask the user to open a Claude Code project first'). Error responses in code (errorPayload calls) exist but are not documented in tool descriptions.
Inferred tool behavior rather than explicit schema registration for some return types. While tool handlers are explicitly registered in server.ts with descriptions and input schemas, the output/return schemas are not declared in the protocol registration. The server.tool() calls show description and inputSchema but no outputSchema parameter, leaving return structure implicit.
Parameter descriptions could be more explicit about constraints. cache_stats.project_dir is described as 'Project working directory. Defaults to process.cwd() of the MCP server.' but does not clarify format (absolute path required? relative OK?) or error behavior if invalid. last_n description says 'Default 20' but does not restate the constraint 'positive, max 200' in the description text for LLM discoverability.