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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint. The description adds behavior beyond them: cursor chaining semantics, the 24-hour default window when no cursor is supplied, and the authorization/plan requirement ('Needs read; every plan') — useful operational context that annotations do not carry.

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?

Four compact sentences, front-loaded with the purpose and scope before the cursor mechanics. Every clause carries information; slight density of 'Needs read; every plan' and 'Reports coverage per account' reads as terse notes rather than flowing prose, but nothing is wasted.

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?

An output schema exists, so return values need no explanation, and the description covers the remaining gaps an agent needs: scope, cursor lifecycle, default window, per-account coverage reporting, and auth requirements. Nothing required to invoke or chain the tool is missing.

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%, so the baseline is 3; the description earns an extra point by explaining cursor pass-back behavior and the no-cursor fallback ('without one it covers 24 hours'), which clarifies the cursor parameter beyond 'From the previous digest; or an ISO date-time'. It adds nothing for limit/folder/account, which the schema already documents.

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 gives a specific verb+resource ('Read-only summary for scheduled runs') and enumerates the exact buckets it covers (reply candidates, calendar, lists, automated mail, threads waiting on others, follow-ups, snoozes). It does not explicitly position itself against overlapping siblings such as awaiting_replies or list_followups, which cover some of the same ground, so an agent must infer the distinction.

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?

It states the usage context clearly ('for scheduled runs') and gives operational guidance on the cursor: pass the returned cursor back next time, otherwise it covers 24 hours. It also states the access requirement ('Needs read; every plan'). No explicit when-not-to-use or sibling alternative is named, so it falls short of a 5.

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