Loading ToolBench
MCP server for agentbudget: token + dollar budget caps for AI agents. Track usage across calls and refuse work that would push past the ceiling.
Three tools with complete input schemas and descriptions. Naming follows verb_noun pattern (configure_, record_, budget_). Descriptions are clear and action-oriented (avg ~150 chars). However, output schemas are undocumented, LLMs cannot infer response structure. Error handling is minimal; no guidance on recovery paths. Parameters lack constraints (enums, ranges, patterns). Missing idempotency guidance for record_llm_usage, which has side effects.
Return the current totals + per-cap remaining for the active budget. Useful for letting an agent decide whether to schedule more work.
Set the active token + dollar caps for this session. Calling this replaces any existing budget; totals reset to zero. All caps are optional — pass only the ones you want enforced.
Tally one LLM call against the active budget. Call after the response — by the time you have token counts, the call already cost money. Returns the updated totals on success, or { status: "exceeded", cap, limit, attempted } when a cap was hit. The exceeded payload still reflects the call (totals are updated even when a cap trips, mirroring real provider behavior).
Output schemas undocumented. LLMs cannot infer response structure for any tool. configure_budget returns {ok, caps, pricing_keys, allow_unknown_pricing}; record_llm_usage returns {status, cap, limit, attempted} on exceed or totals on success; budget_status returns current totals. None of these are documented in tool definitions.
record_llm_usage lacks idempotency guidance. Tool modifies state (increments totals) but does not document whether repeated calls with identical input are safe or will double-count. Agents retry on ambiguous failures, non-idempotent tools risk duplicate charges.
Error handling provides no recovery guidance. record_llm_usage returns {status: 'exceeded', cap, limit, attempted} on cap breach, but does not tell the LLM what to do next: should it retry? Ask the user? Abort the plan? No actionable error messages.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
pricing parameter lacks validation constraints. Accepts arbitrary object with inputPer1k/outputPer1k but no min/max bounds, no format validation. LLMs could pass negative prices or absurd values (1e10 per 1k tokens). No enum or pattern constraint.
Numeric parameters lack range constraints. max_input_tokens, max_output_tokens, max_total_tokens, max_cost_usd have no minimum/maximum bounds. LLMs could pass negative values or 1e15, causing silent failures or unexpected behavior.