Generate speech

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

Annotations only flag readOnlyHint=false and destructiveHint=true; the description adds the important behavior that a file is written to disk and that inline base64 payloads can exceed MCP client result-size limits. It does not cover API key/auth requirements or file cleanup, but the side-effect of disk writing is disclosed, consistent with destructiveHint=true rather than contradicting it.

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?

Two sentences, no padding, and the default-return-behavior fact is placed first because it is what an agent most needs to know before parsing a result. Every clause carries information.

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?

With no output schema, the description usefully explains what comes back (a file path by default, inline audio otherwise), which is the critical missing piece. It could say more about cost/latency or that the saved file persists, but for an 8-param tool with full schema coverage this is largely 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?

Schema description coverage is 100%, so all eight parameters are already documented in detail, including voice enumeration, speed range, format enum, and the outputPath/returnAs interaction. The description only restates the returnAs semantics, adding no syntax or constraints beyond the schema, so baseline 3 applies.

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 states a specific verb and resource ('Convert text to spoken audio') plus the backing engine (OpenAI TTS model). This is unmistakable against siblings like generate_text, transcribe_audio, or generate_image, none of which produce synthesized speech.

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?

It gives an explicit rule for the returnAs decision (default path, use base64 for inline), which is genuinely useful. But it offers no guidance on model selection, voice choice, or when to prefer this over sibling tools such as transcribe_audio in a round-trip workflow. Usage is implied rather than fully framed.

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