9router STT

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

All four annotations are false, so they communicate no safety or side-effect profile and the description must carry the full behavioral burden. The description adds only the input encoding detail and says nothing about side effects, external API dependency, latency, quota consumption, or failure behavior—material for an operation that appears to hit an external 9router service (a nine_usage sibling exists). No contradiction exists, but behavioral disclosure beyond the schema is minimal.

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?

At six words, 'Speech-to-text from base64 audio' is maximally efficient, front-loads the action, and has no wasted content. For a tool with three parameters it is appropriately sized, though the brevity edges toward under-specification, preventing a perfect score.

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?

An output schema is present, so return values are covered, but operational context is missing: supported audio formats, model-selection behavior, whether calls consume usage or quota (relevant given sister nine_usage), and timeout semantics for a potentially slow external STT call. For an agent to invoke this reliably in varied scenarios, the definition falls short of complete.

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?

With 0% schema description coverage, the description must compensate, and it does clarify the one required parameter, audio_b64, by stating the input is base64 audio. However, model (no valid identifier format or default behavior) and timeout_seconds (no meaning of the 180-second default or timeout outcome) remain entirely opaque. The description partially compensates for the coverage gap but leaves most parameter semantics to the agent's speculation.

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?

The description 'Speech-to-text from base64 audio' states a clear verb and resource (converting speech to text from base64-encoded input), making the core function unambiguous. It implicitly distinguishes itself from the sibling nine_tts (text-to-speech) by polarity, but does not explicitly name alternatives or scope details such as languages or supported formats. This is a clear but not fully differentiating description.

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?

No guidance is given on when to choose this tool over its nine_* siblings (nine_chat, nine_image, nine_tts, nine_embedings, etc.). The description contains no use-case context, prerequisites, exclusions, or alternatives. An agent is left to infer all selection criteria from a single terse sentence.

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