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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description still adds real behavior beyond that: create returns the token and url only once, revoke answers a preview plus a confirmToken before acting, and renew moves expiry forward from now rather than extending the original window. What it does not add is any note that idempotentHint=false is mitigated by the idempotencyKey parameter, or what list/get actually return.

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 scope, then a tight parenthetical action-by-action breakdown, then an edge-case note, then sibling routing — a logical ordering with essentially no filler. It is dense and long, but every clause delivers either an action definition or a routing decision; the only mild cost is that the single-paragraph action list requires careful reading.

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 an 18-parameter, multi-action, destructive tool with no output schema, the description covers the essential decision surface: what each action does, the one-time secret returned by create, and the two-step revoke. The remaining gap is return-shape disclosure — with no output schema, an agent cannot tell what list, get, or chat actually yield beyond 'the links' or 'the answers'.

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 100%, so the baseline is 3, but the description meaningfully disambiguates the dominant 'action' parameter — the schema only says 'What to do', while the description defines each of the six actions and their side effects. It also clarifies cross-cutting semantics such as 'one link per chat' and the state vocabulary used by list. It stops short of explaining how the date filters, pagination, or variables interact with specific actions, which the schema carries alone.

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 opens with a precise scope statement ('one link per chat, bound to the published version of a form') and then enumerates all six actions (create, list, get, revoke, renew, chat) with a short gloss for each. It also explicitly names what this tool is NOT — send_whatsapp_web_form for sending and send_whatsapp_flow / list_whatsapp_flows for native WhatsApp Flows — so an agent can separate it from the closest siblings without opening any schema.

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 routing rules are given: 'To send a form as a message, use send_whatsapp_web_form' and 'For WhatsApp Forms (Meta WhatsApp Flows...) use send_whatsapp_flow and list_whatsapp_flows instead.' It also states the one non-obvious exclusion inside the tool itself — create makes a link 'without sending it' — which prevents the most likely misuse.

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