Loading ToolBench
Single tool server with a clear, well-structured speak tool. Schema is properly defined with typed parameters and descriptions. However, the tool description is narrative and somewhat verbose (includes configuration output rather than being concise and action-oriented). Parameters have good descriptions but lack constraints (enums, ranges, or format specs). Error handling exists but is basic. No tool composition patterns required (single tool). Overall competent but with room for clarity improvements.
Speak text aloud using Rime's text-to-speech API. Should be used when user asks you to speak or to announce and explain when you finish a command User configuration: WHEN_TO_SPEAK: when asked to speak VOICE: cove
Tool description is verbose and includes configuration values (WHEN_TO_SPEAK, VOICE, GUIDANCE, WHO_TO_ADDRESS) that should not be in descriptions. Descriptions should be concise (10-200 chars) and action-oriented, not configuration dumps. Current description is ~350+ chars and reads like config output.
Parameter 'speaker' has no type constraints (enum or pattern). Valid speaker values are not documented. LLMs may hallucinate invalid speaker names. Should either document valid options or add an enum constraint.
Parameter 'speedAlpha' has no range constraints. Description says '(default: 1.0)' but does not specify valid range (e.g., 0.5 - 2.0). LLMs may pass out-of-bounds values.
Output schema is not documented in code or description. doSpeak() returns a JSON string with {success, text, speaker} but LLMs cannot predict this structure. Tool should include explicit outputSchema documenting return type.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Error handling returns McpError with message wrapping but does not categorize errors as retryable vs. fatal. If Rime API is down, should the agent retry? Current implementation provides no guidance.
RIME_API_KEY is stored as environment variable and checked at startup, which is correct (secret injection pattern). However, if key is missing, server exits with code 1 rather than returning a graceful error. Clients will see a closed connection instead of a diagnostic message.