Loading ToolBench
A tool for formatting audio with an agent in the loop. Exposes speech-mine capabilities as tools for Claude Code including transcript search, statistics, reading, formatting, audio extraction, and chunking.
speech-mine exposes 6 tools with reasonable naming (verb-first), detailed parameter descriptions, and comprehensive input validation. However, output schemas are not documented in code, error handling is JSON-based but lacks recovery guidance in most cases, and several tools lack clarity around expected return structures. The implementation uses a solid _safe_tool decorator for error handling, but responses are generic JSON strings rather than structured MCP output objects. Average tool score: 62.
Split a WAV into timed segments.
Transcribe audio (spawns subprocess).
Convert CSV to readable script format.
Return statistics about a speech-mine CSV transcript.
Export transcript data in various formats (CSV, JSON, plaintext).
Fuzzy-search a speech-mine CSV transcript for a word, phrase, or sentence.
Output schemas are not documented in code. Tools return JSON strings, but the structure of those strings (fields, types, nesting) is inferred from docstrings or implementation, not formally declared. LLMs cannot reliably extract fields or plan downstream tool calls.
Several tool descriptions are under 50 characters and lack WHEN/WHY context. get_transcript_stats (56 chars), format_transcript (39 chars), extract_audio (39 chars), chunk_audio (41 chars) do not explain prerequisites, expected outputs, or differentiation from related tools. LLMs cannot select between similar tools based on these descriptions alone.
read_transcript and format_transcript both export/transform transcripts. Their names and descriptions do not make the distinction clear. Does 'read' mean load-and-return-raw, while 'format' means convert-to-script? LLMs will conflate them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
extract_audio spawns a subprocess and is marked WRITE (state-modifying). Description does not mention idempotency, timeout behavior, recovery strategy, or output file location. Agents calling this tool twice may create duplicate transcripts or fail silently if the subprocess hangs.
Parameters for read_transcript and format_transcript are not visible in the provided code snippet. If they exist but are not formally registered with descriptions and types, or if they are inferred, those tools' schema scores are capped at 50 per the hard scoring rule.
Error responses are JSON objects with 'error' and optional 'details' fields, but they do not include recovery guidance. For example, 'no words found in transcript' tells the LLM the search failed, but not what to do next (retry with a different query? provide a different CSV? extract the audio first?). Per pattern:recovery-guide, errors should be actionable.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). While risk categories (READ_ONLY, WRITE) are documented in the evaluation metadata, they are not exposed in the MCP tool definition itself, limiting the LLM's ability to reason about side effects and retry safety.