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

Annotations declare non-readOnly, non-destructive, non-idempotent and open-world, but the description adds real substance: the preconditions on reply_state, the fact that approval must precede sending, and that the call executes immediately without a confirmation_token. The one gap is that it never says whether the generated draft is persisted or how repeated calls (non-idempotent per annotations) relate to each other.

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?

Front-loaded with the action and its scope, then preconditions, then the send handoff, then MCP mechanics – a logical order with no filler paragraphs. Only minor redundancy in 'It runs right away and returns the result', which restates the immediately preceding instruction.

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?

There is no output schema, and the description correctly covers the return ('a single message body'), the non-sending boundary, the approval loop that triggers send_message, and the hard precondition on lead state. An agent has everything needed to call it correctly and to know what happens next.

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%, so tone, lead_id and reference are already documented with formats and an enum, which sets the baseline at 3. The description adds modest value by describing the profile fields it reads and framing reference as an 'optional specific hook', but clarifies nothing about tone or lead_id sourcing beyond the schema.

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 with explicit scope: 'Generate a personalised draft for one lead' and 'returns a single message body'. It also carves itself apart from the send path by stating 'Does NOT send', which distinguishes it from send_message and prepare_conversation_reply among the siblings.

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?

Gives explicit sequencing (call get_lead first, then draft, then user approval, then send_message), an explicit exclusion ('refuse to draft for opted-out / replied / rejected leads'), and MCP-specific invocation guidance (call once, without confirmation_token). When-to-use, when-not-to-use, and the alternative tool are all named.

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