synthesize_speech

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

With no annotations present, the description carries the burden of behavioral disclosure. It adds one key fact beyond the schema: the output is Base64-encoded audio. However, it does not mention whether the call is synchronous, whether any authentication is needed, whether there are side effects, or the processing interface details. The basic output contract is present, but more depth would be expected for full transparency.

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?

A single sentence that immediately states the primary behavior and output. It is brief and front-loaded with 'Text-to-speech via SaluteSpeech' before touching the operation. There is no superfluous structure or repetition, though it leaves some behavioral detail out.

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 3-parameter tool with a fully documented input schema and no output schema, this description provides the key missing piece: the return envelope is Base64-encoded audio. It gives enough to make a correct call and understand the result, though it could mention potential limitations like the audio duration or output size. The sibling `get_task_status` raises a possible async concern, but the description's statement that it 'returns Base64-encoded audio' resolves that by implying a direct response.

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?

The input schema covers all 3 parameters with detailed descriptions (text length, voice id syntax, format options). The description adds no additional parameter-specific meaning beyond the schema, such as the decision between opus and wav16 or when to set the telephony rate. Since schema coverage is 100%, the description's lack of parameter commentary is acceptable, but it doesn't exceed the baseline.

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: 'Text-to-speech via SaluteSpeech'. It also clearly distinguishes the tool from the recognition siblings (recognize_speech, recognize_file) by specifying the direction of the operation (text-to-speech) and the output (Base64-encoded audio). An agent can immediately tell this is the generation-side protocol, not recognition.

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?

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'Text-to-speech' implies the scenario of converting text into audio, but the description never references the sibling tools or says when to choose this over recognition. The agent would have to infer the usage context from the message only, with no stated exclusions or alternative recommendations.

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