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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that each entry carries a status, which is mildly useful context, but says nothing about result volume, ordering, or what happens when the contact matches nothing.

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 no filler. Slightly awkward phrasing ('a company in its title') mirrors the schema language but reads a bit cryptically on its own.

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 not be spelled out, and the sole parameter is fully documented at 100% coverage. For a one-parameter read tool, nothing an agent needs in order to call it correctly 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%, and the schema's 'who' description already gives the person/email/company-in-title meaning plus an example. The description restates the same accepted forms rather than adding new syntax or matching rules, so it meets the baseline without exceeding it.

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 the resource (documents) and the scope (everything a given person or company is part of), and adds that per-document status is returned. That is enough to distinguish it from get_document (single document), though it does not explicitly name find_documents as the alternative.

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 only implied: the caller should use this when they have a contact identity and want that contact's documents. There is no explicit when-to-use or when-not-to-use guidance, and no reference to the sibling tools that overlap (find_documents, get_document).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered elsewhere. The description adds the shape of the result set (status, send time, signer states, who still must sign), which is useful, but it says nothing about ordering, pagination, or result limits.

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 no filler or redundancy. It is efficient, though it spends its words on return contents rather than on the filtering capability that distinguishes the 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?

Output schema and annotations cover return values and safety, so the description needn't repeat them. The notable gap is that a tool named find_documents with a free-text query parameter never mentions searching or filtering, which an agent may miss when deciding whether to call it.

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 100% and both parameters carry their own descriptions plus an enum on status, so the schema does the heavy lifting. The description adds no meaning about the query parameter or how status interacts with it, which is the baseline 3 case rather than a failure.

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 and resource ("List documents") and enumerates what each entry carries: status, send date, per-signer status, and outstanding signers. The plural "List" implicitly separates it from the singular sibling get_document, but no sibling is named, so differentiation is inferred rather than stated.

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 guidance, no exclusions, and no mention of the obvious alternatives (needs_attention for pending items, contact_documents for per-contact lookups, get_document for a single record). The agent must infer from the name alone when this tool is the right entry point.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's contribution is the content profile — signer statuses including rejection reasons and audit-log history — which is useful for judging relevance, though an output schema exists that likely covers much of the same ground.

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 no filler; the return contents are listed compactly in parentheses. It reads as a fragment rather than a statement of action ("One document: ..."), which slightly weakens the opening, 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?

For a one-parameter read tool with full schema coverage, complete annotations, and an output schema, the description supplies enough to call it correctly and anticipate the response shape. Only the routing relationship to find_documents and contact_documents is left unstated.

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% and the single parameter document_id is documented with an example, so the schema carries the burden. The description adds no detail about the ID's origin (e.g., where to obtain it from find_documents), which is the one place extra meaning would have helped.

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?

"One document" plus the enumeration of what comes back (signers with signed/rejected/opened/not-opened states, plus audit-log history) makes the resource and payload unambiguous. The singular framing implicitly separates it from find_documents, but no sibling is named explicitly, so it stops 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?

Usage is only implied: "One document" signals a single-record lookup by ID, which the agent can infer is different from the search-oriented find_documents. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must reason about routing itself.

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

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.

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

The annotations only declare it is a non-read-only, non-idempotent, non-destructive open-world write; the description adds the critical non-obvious behavior that the first invocation sends nothing and returns a summary plus a code. It does not cover what happens if the code expires, whether the send is reversible, or who exactly receives it beyond "its signers".

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?

Two tight sentences with the action front-loaded and the two-phase confirmation behavior immediately after; nothing is redundant or padded.

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 an output schema present, the description need not explain the summary payload, and it covers the essential confirmation workflow for a mutation tool. The remaining gap is failure/expiry handling and the irreversibility of an actual send to real signers.

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 100%, and the schema already explains that confirmation should be left empty first and filled only after user consent. The description reinforces the sequencing but adds no new syntax, format, or constraint information beyond what document_id and confirmation already document.

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 states a specific verb and resource ("Send a draft to its signers") and names the recipients, so the agent immediately knows this is an outbound-signing action. It does not explicitly contrast with the sibling send_reminder, which is the nearest alternative, so it falls short of full sibling 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?

It gives clear procedural guidance for the two-step flow: the first call is effectively a preview, and the second call with the confirmation code performs the send only after the user has agreed. It stops short of stating when to prefer send_draft over send_reminder or what to do if the user declines.

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

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

Annotations only say this is not read-only and not idempotent; the description adds the critical fact that the first invocation is effectively a dry run that returns a summary and confirmation code rather than sending. That hidden two-phase semantics is exactly the behavior an agent cannot infer from the structured fields, and it prevents accidental premature sends.

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?

Two sentences, both earning their place: the action is stated first, then the non-obvious two-step safety protocol. Nothing is redundant or 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?

With annotations, a full output schema, and complete parameter coverage, the description's main obligation is the confirmation protocol, which it discharges well. It does not mention edge cases such as reminding a signer who already signed or permission requirements for an outward-facing email, leaving a minor gap.

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%, and the schema already documents the confirmation parameter's sequencing ('leave empty first; pass the code only after the user confirms') and the signer default. The description restates this flow but adds no new meaning about parameter formats or edge cases, so the 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?

The description opens with a specific verb+resource ('Email a reminder to sign'), which is unambiguous about the action. It does not explicitly distinguish itself from siblings like send_draft or contact_documents, so an agent must infer the boundary, but the core purpose is immediately clear.

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 gives explicit procedural guidance for the two-call protocol: the first call sends nothing, and only a second call with the confirmation code actually sends, after the user agrees. It stops short of naming alternatives (e.g., when to use send_draft instead), so it lacks exclusions, but the when-to-call-with-code condition is stated clearly.

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