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

Annotations declare read-only and non-destructive behavior, while the description adds significant state-machine context: polling until final, timeout semantics ('Action Gate timeout is stop'), and the write-gate forwarding condition. It does not specify polling cadence or return shape, but relative to annotation coverage this is rich behavioral disclosure.

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, front-loaded sentences: the core action comes first, followed by source tools, continuation rules, and gate-specific forwarding behavior. Every sentence carries operational information without repetition.

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?

Covers the critical cross-tool workflow: where approval_id comes from, polling until final, timeout behavior, and write-gate re-invocation. Missing return-value shape or polling cadence, but with no output schema and annotations covering safety, it is nearly complete for correct invocation.

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 adds provenance beyond the schema's check_transfer-only note by listing check_action and Write Gate as additional sources, and it explains the re-call-with-approval_id requirement, though it still does not describe format or validation details.

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 'Poll a held check' as a specific verb+resource and identifies the producing tools (check_transfer, check_action, Write Gate). It distinguishes itself from siblings by naming where approval_id comes from, though 'held check' remains jargon and the return decisions are only implied by parentheticals and the title.

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?

Explicitly tells when to call (after a held check), what to pass (approval_id from named tools), and to repeat until the decision is final. It adds conditional routing rules: Action Gate timeout is stop, and Write Gate forwards only after re-calling email.send, slack.post, or crm.write with the approval_id when the decision is go.

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