Loading ToolBench
Two simple, well-named tools with clear descriptions and complete input schemas. Naming follows verb_noun pattern (base64_encode, base64_decode). Descriptions are concise (80 - 120 chars) and explain what each tool does. Input schemas include type and description for all parameters. However, output schemas are not documented, LLMs cannot predict return structure. Parameter 'variant' lacks enum constraint, inviting hallucinated values. Error handling returns structured errors but lacks recovery guidance. No tool annotations (readOnlyHint, idempotentHint). Overall solid for a simple utility but missing production-grade polish.
Decode Base64 / Base64URL / Base32 / Hex back to UTF-8 text (keyless, offline). Set `variant` (default base64).
Encode UTF-8 text to Base64 / Base64URL / Base32 / Hex (keyless, offline). Set `variant` (default base64).
Output schema not documented. LLMs cannot predict return structure (input_bytes, variant, encoded/decoded fields). Agents must infer from examples.
'variant' parameter accepts free-form string instead of enum. LLMs may hallucinate invalid values like 'base64xml' or 'base64-url'. Should declare enum: ['base64', 'base64url', 'base32', 'hex'].
No tool annotations. Both tools are read-only and idempotent but lack readOnlyHint and idempotentHint. Agents cannot distinguish safe tools from destructive ones.
Error messages lack recovery guidance. 'Invalid base32 character' tells LLM nothing about next steps. Should suggest: 'Invalid base32 character. Use only A-Z and 2-7.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
No default value documented for 'variant' parameter. Code defaults to 'base64' but description does not state this explicitly. LLMs may assume variant is required.