Venice ASR (Speech-to-Text)

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does disclose key behaviors: server-side URL fetching, multipart file forwarding, default model selection, x402 wallet support (no Venice account needed), and API key option. This is good transparency about how the tool operates under the hood. Minor gaps: no mention of mutation/side effects (unlikely for this type) or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core purpose ('Transcribe audio.') followed by operational details. No wasted words. Sentence order is logical: purpose → transport mechanism → auth/defaults. Efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-required-param tool with no output schema, the description covers the core function well. However, the 'response_format' enum (srt, vtt, verbose_json) implies meaningful output variations that the description doesn't explain, and supported input audio formats/lengths are not mentioned. Adequate for a basic transcription call but leaves the agent guessing on format semantics and input constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% at the schema level, and the description adds virtually no parameter-level detail. It mentions the default model ('openai/whisper-large-v3') which helps contextualize the 'model' param, but provides no guidance on 'language', 'response_format' (despite an enum offering srt/vtt/verbose_json options), or 'audio_url' format expectations. With 4 params and 0% schema coverage, the description should compensate but doesn't significantly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Transcribe audio.' Specific and distinguishes from siblings like venice_tts (speech synthesis) and venice_video_transcriptions. Mentions the default model and key transport behavior (URL fetched server-side, forwarded as multipart). Purpose is clear, though it doesn't strongly contrast against venice_video_transcriptions which appears to be a related transcription tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States it fetches URLs server-side (implicit hint about how to supply audio). Mentions operator default model and auth options (x402 wallet, API key). However, no explicit guidance on when to use this vs venice_video_transcriptions, or any prerequisites/limitations such as file size or supported audio formats. Usage context is implied but not explicitly scoped.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.