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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious semantics: the call is free, pending does not mean ready nor necessarily unpaid, and it is safe/useful to re-read after a lost reply. It does not describe response shape or whether pending resolves on its own, which keeps it below 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?

Four short sentences, front-loaded with what is read and how to identify it, followed by cost and the two operational cautions. No filler and the caution is placed where it will be read before acting.

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?

No output schema exists, and the description compensates by naming the returned components (state, previews, transcript, charge receipt). For a single-parameter read with full annotations, the only residual gap is that the lifecycle meaning of 'pending' versus terminal states is only gestured at.

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 0% and the single parameter has only a UUID pattern, so the schema alone does not say what the value is. The description does clarify it must be the 'original ID' of the earlier design, which is real added meaning, but it gives no guidance on where that ID comes from or format expectations.

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?

Specific verb ('Read') plus an explicit enumeration of what is returned (state, previews, transcript, charge receipt) scoped to a prior soclo_hosted_voices_design lookup by ID. The naming of the sibling it follows from distinguishes it cleanly from soclo_hosted_voices_design and soclo_hosted_voices_preview.

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?

Explicit when-to-use ('after a lost reply or restart') and an explicit prohibition plus alternative ('Never start a replacement design after an uncertain result'), which routes the agent to polling instead of re-creating. Both conditions and the excluded action are stated.

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