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

Annotations flag this as destructive, and the description usefully narrows that meaning: 'Sends nothing' tells the agent the destructive hint refers to settings mutation, not outbound sending. It also discloses a behavioral rule absent from annotations — offer terms containing a dash or a disallowed word 'are refused' — which the agent needs to anticipate a failed call. It stops short of stating permission/auth requirements.

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?

Purpose and the 'Sends nothing' caveat are front-loaded and the field-by-field parentheticals are scannable despite being packed into one dense block. Every clause earns its place, though the paragraph could be broken into a list for faster reference.

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 7-parameter, no-output-schema mutation tool the description covers partial updates, field constraints, validation failures, and the fact that nothing is sent. What is left implicit is whether changes take effect immediately and whether any fields are mutually required.

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?

Although schema coverage is 100%, the description adds semantics the schema lacks: the 400-character cap on offerTerms, the 200-character cap on pricingDetails, the requirement that the offer be 'stated word for word', the meaning of each enum value ('exchange' = feature them too, 'mention' = brand mention only), and that pricing is 'the only figure the emails may quote'. This meaningfully raises the bar above the schema's terse glosses.

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 ('Change how first emails are framed') and enumerates the exact fields under its control: offer terms, first-touch placement, outreach goal, style, pricing, sender name. It is clearly distinguishable from sibling settings tools like set_run_settings, set_profile, set_sending and set_warmup.

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?

'Pass only the fields to change' explicitly documents partial-update usage, telling the agent it need not supply all six fields. It gives no explicit when-not or named alternative, but for an idempotent settings mutator the contextual guidance is clear and actionable.

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