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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is fully covered. The description adds the one genuinely extra behavioral fact — the result includes recipient counts broken down by status — but says nothing about behavior when identifiers are missing or invalid, or about pagination/limits on the counts.

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?

A single front-loaded sentence with the read tag first and the payload description attached; every clause carries information and there is no filler.

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?

With no output schema, the description usefully states what comes back (recipient counts by status) for a simple two-parameter lookup tool. The remaining gap is the unresolved either/or requirement and error behavior, which an agent would have to guess at.

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 0% and the schema marks both parameters optional, so the description's '(wp_campaign_id or wp_campaign_uuid)' is the only signal that one identifier is expected and that they are alternatives rather than cumulative filters — that is real added meaning. However, it does not say whether both may be supplied together, which wins if they conflict, or what identifier format is accepted.

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 (get/read) and resource (one WhatsApp campaign), and the singular framing plus the bracketed [read] tag distinguishes it from the sibling list_wp_campaigns. It does not name that sibling explicitly, so it falls just short of full differentiation.

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 lookup-by-identifier framing implies when to use it (fetch a single known campaign), but there is no explicit when-not guidance, no pointer to list_wp_campaigns for discovery, and no statement of what happens if neither identifier is supplied.

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