whatsapp_campaigns_read

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds useful context beyond that: the payload includes sent/delivered/failed counts, and results are paginated. It does not describe the shape of the compact vs full response, but with annotations carrying the safety burden this is above baseline.

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?

Two sentences, zero filler, with the resource scope front-loaded and the sibling exclusion placed immediately after. The 'Actions: list' trailer is the only slightly tacked-on element but it costs little.

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?

There is no output schema, so the description correctly steps in to say what comes back (sent/delivered/failed counts) rather than leaving return values opaque. The main omission is any explanation of the compact/full mode choice, which affects how much data the agent actually receives.

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 only 40%: page, action and agentId have no field descriptions. The description partially compensates by implying agent-scoping and pagination, and the limit/mode semantics are documented in the schema itself. Mode's compact vs full trade-off is never touched in the description, leaving a real gap.

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 resource ('List WhatsApp broadcast campaigns of an agent'), clarifies what a campaign is (template messages sent to a lead group), and names the sibling campaigns_read as the home of outbound CALL campaigns. An agent can distinguish it from that sibling without opening 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?

Explicitly routes call-campaign queries to campaigns_read, which is a genuine exclusion rule, and notes the only supported action is 'list'. It stops short of saying when to prefer this over adjacent tools like whatsapp_templates_read or lead_groups_read.

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