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

Annotations already declare readOnly/non-destructive/non-open-world, yet the description still adds real value: it discloses that results are compact counts plus handoff status, that no raw logs are returned, and that the call does not incur a paid model call — a cost/side-effect fact the annotations cannot express. It further surfaces a downstream cost-and-consent obligation around disabled handoffs, including that consent must never be inferred from a test-run request.

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?

Roughly 70 words across five short sentences, with the purpose and the return shape front-loaded so the agent can act on the first two sentences. The consent-policy sentences are longer and more procedural than the rest but still carry invocation-relevant behavior rather than filler. Slight density penalty for mixing routing, return shape, and policy in one flat block without separation.

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 read-only status-poll tool with a fully documented three-parameter schema and no output schema, the description covers what an agent needs: input provenance, what comes back (counts, handoff status), what does not (logs, model calls), and the required follow-up when a failed run offers disabled handoffs. No meaningful gap remains that would cause a wrong 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 and the schema does the heavy lifting on the three parameters. The description nevertheless adds provenance the schema lacks by tying run_id to trigger_framework_run, resolving where the identifier comes from. It adds nothing about the context or project_id parameters, but that gap is minor given full schema documentation.

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 verb and resource ('Poll a framework run_id') and anchors it to the producing sibling ('returned by trigger_framework_run'), so the agent knows exactly which object it operates on. It also explicitly contrasts the return payload with raw logs and disqualifies a competing interpretation (a paid model call), separating it cleanly from trigger_framework_run and get_framework_handoff.

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?

The precondition is explicit: call this with a run_id produced by trigger_framework_run, and switch to get_framework_handoff when the full draft is needed. The consent workflow (present pricing, ask once, wait for explicit approval, respect a refusal) gives concrete when-do-what guidance. It stops short of explicit exclusions, notably polling frequency or backoff guidance, which for a poll-style tool would have made routing unambiguous.

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