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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the mutation profile is known. The description adds genuinely useful context beyond that: the return artifact is an MP3 link and the audio is persisted to the user's library, making the side effect explicit. It doesn't note that repeat calls yield new assets despite non-idempotency, which would have earned a 5.

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, zero filler: the first front-loads the triggering condition, the second the output and persistence behavior. Nothing redundant with the title, which it does not merely restate.

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 exists, so return-value detail is not required, and annotations cover the safety/mutation profile. The description completes the picture with triggering context and the library-save side effect. Only the undocumented 'title' parameter and any voice/language caveats remain unaddressed, a minor gap.

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 coverage is 75% (text, voice, language documented; title undocumented), and the description contributes no parameter meaning at all — no voice selection, language behavior, or title usage. With the schema doing most of the work, the 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 concrete verb+resource outcome ('text read aloud as an audio file', 'Returns an MP3 link'), which clearly distinguishes it from image/video/slides siblings. It stops short of naming or contrasting with the closest sibling, transcribe_audio (the inverse operation), so it doesn't reach the sibling-differentiation bar of a 5.

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?

'Use this when the user wants text read aloud as an audio file — a voiceover, narration or spoken message' gives an explicit, concrete triggering context with exemplar use cases. It offers no when-not guidance or named alternative (e.g. transcribe_audio for the reverse), so it is clear but not exhaustive.

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