Loading ToolBench
Two tools with complete schemas and proper type definitions. Both have descriptions (10-word minimum met) and tool annotations. However, descriptions are minimal (under 100 chars) and lack actionable context for LLM selection. Parameter descriptions are absent, 'message' in echo has only a length constraint, no semantic guidance. Output schemas are documented in code but not exposed in tool registration (outputSchema fields present but not integrated into LLM-facing metadata). No error handling guidance, no recovery paths, no examples of when to use each tool vs alternatives.
Return validated text and its Unicode character count.
Return server name, version, and local process status.
Parameter descriptions missing. 'message' parameter in echo tool has no description field, only a constraint (1-500 chars). LLMs cannot infer semantic meaning from names alone.
Tool descriptions are minimal (10-20 words) and lack actionable context. 'Return validated text and its Unicode character count' does not explain WHEN to use echo vs alternatives, or what 'validated' means. Baseline for A+ tools is 50-200 chars with clear intent.
server_status tool name is vague. 'server_status' does not start with a clear action verb (get_, describe_, check_). LLMs may conflate it with other status tools. Recommend 'get_server_status' or 'describe_server_health'.
No error handling guidance. Tools do not document what happens on invalid input (e.g. message > 500 chars, malformed JSON). LLMs receive no recovery path, only a validation error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2025-06-18+ | v2 |
Output schemas defined in code but not exposed to LLM. outputSchema fields in registerTool are Zod objects, not JSON Schema. LLMs cannot parse Zod syntax, they need plain JSON Schema or clear text descriptions of return fields.