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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds genuinely new context: it requires an account key and caps the range at 366 days, which an agent needs to know before calling. It stops short of describing response shape or whether empty ranges error.

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 access mode first, then the operation, scope, and constraint. Nothing extraneous and nothing buried.

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 should say more about what 'delivery and engagement counts' include (e.g. sent, opened, clicked) and whether results are zero-filled. The auth note and 366-day limit help, but the return contract remains vague.

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 67%; the two date parameters are documented in the schema, but subaccount_id has no description. The description only hints that a single sub-account id is needed and that the range must be within 366 days, which is modest added meaning rather than full compensation for the undocumented id parameter.

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 operation (aggregate delivery and engagement counts) on a specific resource (one sub-account) over a date range. The word 'aggregate' implicitly distinguishes it from the sibling sendpost_list_subaccount_stats, though that contrast is never made explicit.

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?

Usage is implied by 'one sub-account over a date range' and 'aggregate', which suggests totals rather than per-row listings, but the description never says when to prefer it over sendpost_get_account_stats or sendpost_list_subaccount_stats. No exclusions or prerequisites beyond the date-range cap.

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