Loading ToolBench
Offload grunt work from your subscription LLM to cheap models via MCP — auto-routing, a savings ledger, and billing isolation.
Cheaplane has 2 tools with clear, detailed descriptions that explain WHEN to use them and what they do. The `delegate` tool has a comprehensive description (280+ chars) with explicit guidance on what NOT to delegate (judgment work). The `savings` tool is simpler but adequate. Both tools have input schemas with type definitions. However, parameter descriptions lack depth, the `model` parameter description is long but reads more like implementation docs than LLM-facing guidance. The `task` parameter description is good (self-contained instruction), but `max_tokens` lacks context on why 4000 is the default or when to override it. Output schemas are not documented, LLMs cannot see what `delegate` returns or what `savings` returns. Error handling is absent from descriptions; no guidance on what happens if the proxy is unreachable or a model fails. The tool composition is sound (two separate concerns), but the interface could be more LLM-friendly by documenting return structures.
Offload a self-contained subtask to a cheaper model and return its output. WHEN TO USE: hand off *replaceable grunt work* to save your premium tokens — boilerplate code, small bug fixes, formatting, translation, reading/summarizing long documents, drafting routine copy. Do NOT delegate judgment work (planning, architecture, final review, talking to the user) — keep that for yourself. The delegated model sees ONLY the `task` string and has NO access to this conversation. So make `task` fully self-contained (include all needed context).
Show what delegating has kept off your premium quota (estimates, list prices).
Output schemas not documented. LLMs cannot see what `delegate` returns (text? structured object? error details?) or what `savings` returns (list of transactions? summary object?). This forces LLMs to guess and risks misuse of returned data.
Parameter descriptions lack LLM-facing guidance. The `model` parameter description is 200+ chars of implementation detail (auto-routing heuristics, aliases, env vars) rather than actionable guidance for when to use 'auto' vs explicit model names. Simplify to: 'Model to use. "auto" (default) picks the best cheap model for the task; or force an alias (deepseek/mimo/flash/kimi/qwen) or raw model name.'
No error handling guidance in descriptions. If the proxy is unreachable, a model fails, or the task is malformed, what should the LLM do? Add: 'If delegation fails, the error message will indicate whether to retry, simplify the task, or check the proxy configuration.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
The `max_tokens` parameter lacks context. Why is 4000 the default? When should an LLM increase it? Add: 'Output token limit (default 4000). Increase for long documents or reasoning models; decrease to save cost on short tasks.'
The `savings` tool has no input parameters documented, and its output is not described. What does it return? A list of delegated calls? A cost summary? A ledger file path? Document the return structure so LLMs know how to use the data.