WhatsApp Business accounts and numbers

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

Goes far beyond the readOnlyHint and openWorldHint annotations. It discloses read-only and zero-credit behavior, explains that only brand-shared accounts are reachable, that failed reads are reported rather than dropped (which could cause misinterpretation of missing accounts), and warns about duplicate display names. This is rich behavioral context not in the 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?

Although the description is longer than typical, every sentence earns its place by conveying critical operational details. It is structured to front-load the core purpose, then sequentially covers caveats, configuration, and billing. No fluff or redundancy; each sentence adds unique information.

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?

Given there is no output schema, the description thoroughly explains what the tool returns (IDs, phone numbers, quality rating) and the implications of that data (send limits, needed by other tools). It also covers error behaviors, naming pitfalls, account selection rules, and credit billing. Everything an agent needs to correctly call and interpret this tool is present.

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?

There are zero parameters, so the description has no need to elaborate on them. The baseline is 4 for tools with no params. The description does not waste space repeating nonexistent parameters and instead focuses on output semantics, which is appropriate.

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 explicitly states the tool lists WhatsApp Business Accounts shared with the brand, including phone numbers, IDs, and quality ratings. It clearly distinguishes itself from other WhatsApp tools by naming them as consumers of these IDs, and it is unambiguous about the resource and verb.

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?

Provides explicit 'Start here' guidance, explains when to use it versus alternatives (e.g., WhatsApp Manager for number registration), and details the behavior when no accounts are ticked, including the way to configure via set_connector_accounts. It also covers the case of a single account making wabaId optional, giving clear actionable context.

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