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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: the group list is materialized at connection time, groups joined since are captured from the join event without requiring messages, and left groups are otherwise hidden. It does not discuss pagination cost or ordering, which keeps it from a 5.

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 purpose, then the freshness semantics, then parameter notes; every paragraph is short and scannable. The middle paragraph on join-time capture is slightly verbose for what it conveys but still earns its place as non-obvious behavior.

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 paginated read tool with a full output schema, the description covers the important caller-relevant behavior (freshness of the list, default exclusion of left groups) and all five optional parameters are documented via the schema. It omits nothing critical, though it could note that pagination cursors must pair with the same filters (the schema covers this).

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 the baseline is 3. The description's notes on `name` and `include_left=true` largely restate what the schema already says ('Off by default, so a plain listing shows only groups the number is currently in'), and it says nothing about `limit`, `cursor`, or `number_alias`, which the schema documents instead.

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?

Opens with a specific verb and resource, 'List the WhatsApp groups this number is a member of', and scopes it to a particular number. An agent can immediately distinguish it from get_group (singular fetch) and from list_numbers without reading either 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?

The description explains the meaning of two parameters (name, include_left) but gives no explicit when-to-use guidance or named alternative such as get_group for a single group. Usage is implied rather than stated: the agent infers this is the enumeration tool, but nothing says when to prefer it over other listing tools.

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