Get Push Campaign Stats

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it warns that totals lag (recounted periodically), that a just-sent campaign can legitimately read 0, that `delivered` means the push service accepted rather than device arrival, and that rates are 0–1 fractions that are null when undefined. These are exactly the traps that would cause an agent to misreport data.

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 outcome, then semantics, then the staleness caveat — good ordering with no filler sentences. It is dense but slightly overpacked in one block, and the parenthetical '(every 15 minutes for email)' introduces cross-channel detail that is mildly confusing on a push tool.

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 carries the full burden of explaining return values, and it does: metric list, delivered-vs-confirmed distinction, rate units and null behavior, lifetime aggregation, and refresh lag. An agent could interpret the response correctly without further documentation.

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 100% for the single `id` parameter, so the schema already fully documents it (uuid, format, description). The description only adds that the id identifies 'one push campaign' and that stats cover 'the whole life of the campaign' — nothing about id sourcing or lookup behavior, so baseline 3 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?

States a specific verb and resource ('Get how one push campaign performed') and then enumerates the exact metrics returned: recipients and devices, delivered, displayed, opened, clicked, dismissed, failures, conversions, revenue. The channel-specific name plus this enumeration lets an agent distinguish it from get-email-campaign-stats / get-in-app-campaign-stats and from the config-oriented get-push-campaign.

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?

There is no explicit routing guidance: it never says when to use this vs get-push-campaign (configuration) or the other channel stats tools, nor any prerequisites (does the campaign need to be sent first?). The only usage-adjacent guidance is interpretive — re-check a fresh campaign rather than concluding nothing was delivered — which is about reading results, not tool selection.

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