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

Annotations only declare readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false; the description adds the material context the agent actually needs — EXPERIMENTAL status, the desktop-Chrome/extension requirement, the environment exclusions, that it returns a link and no QR, and the roughly two-minute user-side duration. The safety profile is consistent with the annotations: nothing is destroyed, but it is not a pure read.

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 EXPERIMENTAL warning and the call condition are front-loaded, and each subsequent sentence carries distinct operational content: prerequisites, environment exclusions, return shape, user instructions, expected duration, follow-up tool, and concurrent-call prohibitions. No sentence is redundant with another or with the annotations.

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 zero-parameter, no-output-schema orchestration tool, the definition covers everything an agent needs: when it is valid, what it returns, what to tell the user to do on the page, how long to expect, which tool to call afterward, and which tools to avoid meanwhile. Nothing required for a correct invocation is missing.

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?

The tool takes zero parameters, so the baseline is 4 and no per-parameter explanation is required. The description correctly spends none of its words on arguments and instead documents the input the tool does require — a prior passkey-required result — which is the relevant 'input' for this call.

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 outcome: finishes WhatsApp's passkey confirmation when linking got stuck on it. It also scopes itself away from the general linking flow by naming get_pairing_qr and request_pairing_code as the tools that come first, so an agent can distinguish it from 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?

Gives an explicit trigger condition (only after a prior call returned passkeyRequired or the passkey notice), explicit prerequisites (desktop Google Chrome plus the linked extension, not phone/cloud/VM), explicit next step (get_session_status once the user reports done), and explicit exclusions (do not call get_pairing_qr, request_pairing_code, or restart_session while the user is on that page).

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