Loading ToolBench
Single tool 'say' has a detailed, well-structured description (340+ chars) with clear WHEN/HOW/TIPS sections matching LLM-optimized patterns. Input schema is complete with typed parameters (text: string, state: enum). However, the tool lacks output schema documentation, error handling guidance, and recovery patterns. The description is excellent for user-facing context but does not document what the tool returns or how to handle failures. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Overall definition quality is above average but incomplete for production use.
WHEN TO USE: Use this tool when having voice communication with human. It's useful for reporting important events, announcing task completion, expressing emotions, or even for casual conversation and telling jokes. HOW TO USE: The "text" argument specifies the message you want to say, and the "state" argument specifies your state that best fits the message. TIPS: - The "text" argument should be carefully designed to prevent misinterpretation by the text-to-speech engine. For example, kanji characters with multiple pronunciations should be converted to katakana. - Difficult-to-understand strings of characters, such as URLs and UUIDs, should be replaced with short, abstract nouns that explain them. For example, "https://google.com/" should be replaced with "Google". - The "text" argument should be concise and not too long. It should be no more than 200 characters.
Missing output schema documentation. Tool description does not specify what 'say' returns (success/failure, response structure, error codes). LLMs cannot plan downstream actions or handle failures without knowing the response shape.
No error handling or recovery guidance. Description lacks actionable error messages (e.g., 'If text-to-speech fails, try shortening the message or removing special characters'). Agents cannot self-correct on failure.
Missing tool annotations. No readOnlyHint, destructiveHint, or idempotentHint declared. The 'say' tool is read-only (does not modify state), but this is not explicitly signaled to the MCP client.
Parameter 'state' enum values lack descriptions. The enum ['waiting', 'neutral', 'happy', 'crying', 'worried', 'troubled'] is self-documenting but would benefit from brief descriptions of when each state is appropriate (e.g., 'happy: use when reporting successful task completion').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Text parameter constraint (max 200 chars) is documented in description but not enforced in schema. JSON Schema should include 'maxLength: 200' for machine-parseable validation.