Loading ToolBench
MCP server exposing VZT Flow voice dictation (listen, transcribe_file, dictation_history) to Claude Code.
vzt-flow-mcp exposes 4 tools for voice dictation and meeting transcript access. All tools have descriptions (10-300+ chars) and input schemas with typed parameters. However, several critical gaps prevent a higher score: (1) output schemas are not documented, callers cannot predict response structure; (2) error handling is minimal, no recovery guidance or categorization; (3) some parameter descriptions are generic or incomplete; (4) no idempotency guarantees stated; (5) tool composition relies on undocumented assumptions (e.g., that listen's output can be reused across contexts). The naming is clear and action-oriented (listen, transcribe_file, dictation_history, meeting_transcript), following verb_noun convention. Parameters are reasonably constrained (enums for mode, numeric bounds for max_seconds and n), but lack dependency documentation.
Show recent VZT Flow dictation history entries (timestamp, app, mode, and the pasted text).
Record the user's voice from the microphone and return the transcribed, cleaned text. Use when the user wants to dictate a prompt, answer, or any text by voice.
Return the text of a locally-recorded meeting transcript written by `flow meeting`. Select by index (0 = latest, 1 = next most recent, ...) or by filename. Long transcripts are truncated to a head + tail. Use to read, summarize, or extract action items from a call.
Transcribe an existing audio file (wav, or anything ffmpeg can read) through VZT Flow's dictionary correction pass and return the text.
No output schemas documented for any tool. LLMs cannot predict response structure or plan downstream operations. Pattern requires documenting return types for 100% of tools.
Error handling lacks recovery guidance and categorization. A daemon connection failure or invalid file path returns raw errors without suggesting next steps (e.g., 'Start the VZT Flow desktop app' or 'Check file path').
transcribe_file parameter 'path' lacks format/validation constraints in description. Description should state: 'Absolute filesystem path; must exist and be readable. Supported: WAV, MP3, FLAC, or any format ffmpeg can decode.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
meeting_transcript 'meeting' parameter uses union type [number, string] but lacks clear distinction in description. Should clarify: 'Numeric index (0=latest, 1=next-most-recent, ...) or exact transcript filename. Index takes precedence if both match.'
No idempotency guarantees stated. If an LLM retries listen() after a timeout, will it record twice? Transcribe_file's side effects (if any) are undocumented. Critical for agent safety.
dictation_history returns 'n' most-recent entries but no pagination cursor or total count. If the user has 1000+ entries, LLM cannot discover or paginate beyond the first n.
meeting_transcript description mentions 'Long transcripts are truncated to a head + tail' but does not specify the truncation point (e.g., 'first 5000 + last 5000 chars'). LLMs cannot reason about data loss.