What needs attention

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuine behavioral context beyond that: the result is ordered 'longest wait first', it distinguishes 'our own people' from external signers, it includes rejection reasons, and it spans three distinct categories of outstanding work. What it omits is whether the result is bounded, scoped to the caller's account, or truncated.

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 sentence with no filler, and the highest-value item (signers still to sign) is front-loaded. The parenthetical about 'our own people' is slightly awkward but packs real information. Nothing is redundant or restated from the title.

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 parameters, rich annotations, and an output schema to explain the return shape, the description carries little burden and meets it. It covers what the report contains and how it is ordered. The remaining gap is scope — whether it covers the whole account or just the caller — which an agent might need before trusting completeness of the list.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies a parameterless, account-wide snapshot with no filtering, which matches the empty input schema and sets no false expectations about narrowing the query.

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 names a specific aggregate resource — outstanding signing work — and enumerates its three constituents: pending signers ordered by wait time, rejected documents with reasons, and unsent drafts. That is far more concrete than the title 'What needs attention'. It loses a point only because it never names or contrasts with the sibling tools (find_documents, contact_documents), so the agent must infer the boundary from names alone.

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 when-to-use statement and no mention of alternatives or next steps. The workflow implication — that this is the triage entry point before send_reminder or send_draft — is left entirely to inference. The enumeration of item types hints at usage but does not guide tool selection among siblings.

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