Loading ToolBench
Local-first LLM router: keep sensitive data and bulk text labor on your own models, call the cloud only for the hard part. Privacy-routing (fail-closed) + manager-worker delegation + allowlist guard, MCP-native.
Four tools with clear, domain-specific purposes and reasonable descriptions (avg 156 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are not documented in the visible code, parameter descriptions lack format/constraint details, and error handling guidance is absent. Tool naming is strong (verb-noun pattern), but descriptions could be more LLM-optimized per the 50-200 char baseline. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles.
Run a completion through the local-first router and return its text. Sensitive calls are pinned to the local model (fail-closed); bulk/auto calls prefer local and fall back to the cloud only when local is down.
Offload heavy text work to the fast local worker — summarizing, drafting, translating, reformatting, extracting, classifying — anything token-heavy over text you already have. Keep decisions/planning/tool-calls for yourself.
Decide where a prompt would run (local vs cloud) without calling an LLM. Returns the routing decision: which allowlisted model and target were chosen, the human-readable reason, and whether it fell back off the preferred target.
Report this session's token use and estimated cloud spend. Lets a cloud director see what it has already spent delegating to the local worker versus the cloud. Counts are for this server process only.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns the routing decision: which allowlisted model and target were chosen...') but the actual response structure (field names, types, nesting) is not visible in the provided code. LLMs cannot plan downstream tool calls or extract fields without knowing the response schema.
Parameter descriptions lack format/constraint details. 'kind' is described as 'The nature of the work (bulk, reason, or auto)' but does not state whether it is an enum, what the default is, or what happens if an invalid value is passed. 'prompt' lacks length limits or format guidance.
No error handling guidance. Tool descriptions do not explain what errors can occur, how to recover, or what the LLM should do next. E.g., 'complete' may fail if local model is down or cloud is unreachable, but no recovery path is documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Tool annotations missing. 'route' and 'usage' are read-only; 'complete' and 'delegate_to_worker' are destructive/stateful. The MCP spec supports readOnlyHint and destructiveHint annotations to signal this to clients, but none are present in the visible schema.
'delegate_to_worker' naming is vague. 'delegate' is not a standard action verb (get, create, send, etc.). Consider 'offload_text_task' or 'process_text_locally' to clarify intent and distinguish from other delegation patterns.