Loading ToolBench

Reading the current corpus…

tokenbrake MCP server · C · ToolBench

tokenbrake

MCP server for TokenBrake — let an AI agent read its own API spend and check whether it is the one running away. Zero dependencies, no API keys, talks only to your own machine.

2026-07-28+STDIO3 tools

60/100

Definition Quality75

Protocol Readiness50

Supportability43

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

TokenBrake MCP defines 3 tools with clear, domain-specific descriptions (50-150 chars each) that explain WHAT and WHEN. Tool names follow verb_noun pattern (tokenbrake_spend, tokenbrake_breaker, tokenbrake_reset_breaker). However, all three tools have EMPTY input schemas (no parameters, additionalProperties: false), which is correct for their use case but limits composability. Descriptions are strong and actionable, but lack parameter-level guidance (N/A since no params). No output schemas documented, LLMs cannot predict response structure. Error handling not visible in source. Risk annotations present (READ_ONLY, WRITE) but not formalized as toolAnnotations in the MCP spec.

Tools (3)

tokenbrake_breakerread onlysource verified75/100

Check the runaway breaker: whether any agent is currently stuck in a loop, burning, error-storming or surging, how many calls have been refused, and what that avoided. Use it when calls start failing, to find out whether YOU are the runaway.

tokenbrake_reset_breakerwritesource verified75/100

Clear a tripped runaway breaker and let calls through again. Only do this once the cause of the loop is actually fixed — resetting a breaker over a live loop just restarts the bill.

tokenbrake_spendread onlysource verified75/100

Read what the AI calls through this machine's TokenBrake proxy have cost so far this month. Use it to answer 'what am I costing?' before running something expensive.

Issues (5)

HIGHtool ↗

No output schemas documented. LLMs cannot predict response structure (fields, types, pagination). Agents must infer from trial calls.

tokenbrake_spendtokenbrake_breakertokenbrake_reset_breaker

MEDIUMtool-annotations ↗

Tool annotations (readOnlyHint, destructiveHint) not formalized in MCP schema. Risk metadata (READ_ONLY, WRITE) present in comments but not machine-readable.

tokenbrake_spendtokenbrake_breakertokenbrake_reset_breaker

MEDIUMrecovery-guide ↗

No error handling guidance visible. If TokenBrake proxy is unreachable or breaker state is invalid, LLM receives no recovery hints.

tokenbrake_spendtokenbrake_breakertokenbrake_reset_breaker

HIGHconfirmation-request ↗

No confirmation/dry-run pattern for destructive operation (tokenbrake_reset_breaker). Agent can reset breaker without preview, risking unintended cost surge.

Recommendations

Document output schemas for all three tools. Example: tokenbrake_spend should return {spend_usd: number, calls: number, month: string}. tokenbrake_breaker should return {is_tripped: boolean, reason: string, calls_refused: number, cost_avoided_usd: number}.
Add tool annotations to the MCP schema: readOnlyHint: true for tokenbrake_spend and tokenbrake_breaker; destructiveHint: true for tokenbrake_reset_breaker. This makes risk metadata machine-readable.
Implement a dry-run or confirmation pattern for tokenbrake_reset_breaker. Return {would_reset: true, current_state: {...}} and require a second call with confirm: true to actually reset.
Add error handling examples in the server implementation. Return structured errors like {error: 'proxy_unreachable', message: 'TokenBrake proxy at http://localhost:8787 did not respond. Ensure it is running.', retry: true}.
Enhance descriptions with dependency hints: 'Call tokenbrake_breaker first if calls are failing to determine if YOU are the runaway. Then call tokenbrake_reset_breaker only after fixing the root cause.'

Score history

Overall score trend

First recorded score · v2 rubric

60/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	60	2026-07-28+	v2