Send a drafted WhatsApp message

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context beyond annotations: it clarifies the idempotency as 'once per draft,' specifies handling for stale/missing drafts, and warns 'never redo it unasked.' It also states that this is the only sending call, which is not present in annotations. No contradictions with annotations.

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 compact and front-loaded: the first sentence states the core action and its exclusive nature, followed by three terse edge-case rules. Every sentence earns its place, with no filler or repetition. The structure is scannable and highly efficient.

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?

The tool has no output schema, so the description must cover behavior. It addresses the main action, when not to use, and fallback actions for exceptional cases. It does not state what the tool returns on success (e.g., a message ID), but that is often implied and not critical for correct invocation. Given the edge-case richness, the description is nearly complete for an agent to decide and call it appropriately.

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%: draft_id is described as 'From send_message' and account_id as 'Account id.' The description itself does not add further parameter details, but it does imply the draft carries text and recipient, which relates to draft_id. With full schema coverage, a baseline of 3 is appropriate; the description doesn't need to compensate.

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 states a specific verb and resource: 'Send a draft the user approved' with the exact scope 'this text, this recipient.' It explicitly distinguishes from siblings by calling itself 'the only call that sends, once per draft,' which separates it from send_message and other drafting tools. The purpose is unambiguous.

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?

The description gives clear when-to-use guidance: only for an approved draft, and provides explicit when-not-to-use conditions: 'A yes about something else' or 'Expired, missing or stale' should trigger preview re-shows instead of sending. It also names a fallback for unknown outcomes ('read_messages'). While it doesn't enumerate all sibling tools, it gives concrete decision rules that route the agent correctly.

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