await_print_completion

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

With no annotations provided, the description fully bears the burden of behavioral disclosure. It details the polling behavior, terminal states, timeout, and return structure (outcome, final state, elapsed time, completion history, optional design_goal block). It also notes best-effort for brief_id. This is comprehensive.

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?

The description is well-structured with a purpose statement, behavior paragraph, and parameter docstring. It is relatively concise given the amount of information, though slightly longer than minimal. Every sentence adds value, but could be tightened slightly.

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?

Given the complexity of a polling tool with optional parameters and no output schema, the description covers the return value format thoroughly. It addresses the main use case, optional features, and edge cases like timeout. It is complete for an agent to understand and use correctly.

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 0%, so the description must compensate. It explains each parameter's purpose and effect: job_id (track specific job vs. monitor printer), timeout (max wait), poll_interval (status check frequency), and brief_id (adds design_goal if resolves). This adds significant meaning beyond the schema's type and default values.

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 clearly states the tool's purpose: 'Wait for the current print to finish and return the final status.' It uses specific verbs ('await', 'polls') and resource ('print completion'), and distinguishes from sibling tools by focusing on blocking wait versus fire-and-forget, which differentiates it from monitoring or cancellation tools.

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 description provides clear context for when to use the tool (fire-and-forget, avoid manual polling) and explains the optional job_id and brief_id parameters. However, it does not explicitly state when NOT to use it or compare with alternatives like monitor_print, so it lacks explicit exclusion guidance.

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