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

Annotations already declare readOnly/idempotent/non-destructive, so the lower bar applies, yet the description still adds real behavioral context: the packet contains the full VOICE.md, a platform-fitted length target, and rules preserving the user's facts and identity. Most valuable is the disclosure that the packet 'opens with a line that replaces any earlier voice' — a conversational side effect an agent could not infer from readOnlyHint alone.

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?

Three sentences, front-loaded with the core action and the packet's contents, closing with the voice-switching affordance. Dense and largely waste-free, though 'with your own model' and the inventory phrasing lean slightly toward promotional rather than operational.

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 an output schema present, rich annotations, and full schema coverage, the description need only explain intent and behavior — and it does, including what the packet contains and the voice-replacement effect. The one gap is the unstated relationship to get_voice, leaving the agent to guess which of the two to call for a given need.

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% and five of six parameters are enums with documented values, so the schema carries the semantics. The description only restates the parameter names and adds one useful relational hint — that length is fitted to the platform's limit — which is a modest increment over the schema rather than a compensation for a gap.

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 gives a specific verb and resource — it returns writing instructions for one voice, parameterized by format, length, platform, intensity and edge — and enumerates the packet's contents (VOICE.md, length target, fact/identity rules). It never names the siblings get_voice or search_voices, so the agent must infer on its own why it would want a 'packet' rather than the voice itself.

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?

Usage is implied by the parameter list and by the closing note that 'switching voices mid-conversation is one call', which is a genuine use case. However, there is no explicit when-not guidance and no mention of when to call get_voice or search_voices instead, which matters given three sibling tools in this namespace.

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