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

With no annotations, the description carries full behavioral burden and does so richly: it discloses 202 + job id, required polling via getApiJob, credits charged on success, 400 on text over 200 chars, 429 at 50 queued jobs, request_id deduplication, and the shape of the final result (URL). However, it contains an internal contradiction: 'there is no separate polling step' followed by 'poll getApiJob (pass wait: 30) until status is succeeded.' This prevents a perfect score.

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?

The description is information-dense but longer than necessary and slightly disorganized: purpose, result shape, credits, alternatives, request_id, auth, polling, and limits are interleaved across many sentences. The contradictory phrase 'no separate polling step' adds confusion rather than value. Every sentence mostly earns its place, but the ordering and the contradiction keep it from being concise.

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 complex async generation tool with no output schema or annotations, the description supplies everything needed to call and consume it: required params, error codes, polling flow, final result location, rate limits, credit cost, and sibling differentiation. Even though it says there is no output schema, it specifies the result field is exactly the documented response and that the audio result contains a URL. Nothing essential is missing.

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 100%, so the schema already describes all parameters. The description adds meaningful beyond-schema semantics: text limit of 200 chars triggers HTTP 400, type selects 'human' or 'non-human', and request_id can be used later via GET /assets/audio/results. It does not cover augment_prompt, but the schema already explains it, so a 4 reflects the added value.

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?

States a specific verb and resource: 'Design a new voice from a character description' and 'have it speak a short line of text, returning a sample.' It clearly distinguishes itself from siblings by naming createSpeech and createSpeechPreset and describing they clone or use presets rather than inventing from description. The purpose is unambiguous even before reading the schema.

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?

Provides explicit routing guidance: 'Use this to invent and audition a voice from a description; use createSpeech for text-to-speech that clones a specific voice from an audio sample, and createSpeechPreset for text-to-speech using a named preset voice.' It also gives operational conditions: requires API key, async polling via getApiJob, rate limit behavior, and when 429 appears. There is no ambiguity about when this tool should be selected.

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