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

Annotations already declare this is a mutating, non-idempotent, non-destructive operation. The description adds behavioral context beyond that: the permanent effect ('They can no longer call or message this account') and the output behavior ('Reports who was blocked — their number, the name this account's address book has for them, and the country the number belongs to'). This gives the agent useful information about consequences and return value.

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 two sentences with zero wasted words. The primary action is front-loaded ('Block a contact on one of your WhatsApp accounts'), followed by the effect and then the output details. Every sentence earns its place, and the structure is clean and scannable.

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 simple two-parameter tool, the description is complete. It states the purpose, the effect, and what the response contains. Annotations cover the mutation flags, the output schema describes the return structure, and the schema covers parameters. There is nothing missing that an agent needs to call this tool correctly — the description effectively conveys the action and its consequences.

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% — both parameters (jid and account_id) are explained in the schema. The description does not add any parameter-specific meaning beyond what the schema already provides. It mentions output details (number, name, country) but that relates to the response, not input parameters. Per the baseline rule, a 3 is appropriate when the schema covers parameters and the description adds no further parameter guidance.

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 action — 'Block a contact on one of your WhatsApp accounts' — with a clear verb and resource. It distinguishes itself from siblings like wa_unblock_contact (which undoes the block) and wa_list_blocked (which lists blocked contacts). The effect is also described: 'They can no longer call or message this account.'

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 implies when to use it: when you want to prevent a contact from calling or messaging. However, it does not explicitly mention alternatives or when-not-to-use. For example, it doesn't say 'use wa_unblock_contact to reverse' or 'use wa_list_blocked to view blocked contacts.' The context is clear but no explicit routing to alternatives is provided.

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