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

Annotations already declare read-only/idempotent behavior. The description adds valuable behavioral context beyond annotations: polling interval, status handling ('done'/'error'), and the role of retry_after_seconds/next_action. It doesn't fully describe error edge cases or rate limits, but it exceeds the baseline with meaningful operational detail.

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 dense, information-rich sentences with a helpful example. Every sentence earns its place, front-loads purpose, and then gives usage behavior. No fluff.

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?

Despite having an output schema (which handles return value specifics), the description covers the full usage cycle: how to poll, what to look for, how to handle wait vs. completion, and where to find the job_id. For a polling tool with one parameter, this is complete and self-sufficient.

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 input schema already provides 100% coverage with a clear description of job_id ('returned when the task was started'). The description reinforces this by mentioning 'id-from-a-job-tool', but adds little semantic value beyond the schema. 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 states a specific verb ('Get the status or result') and a clear resource ('a job started by deep_research, translate_pdf, or make_slides'). It distinguishes from sibling tools by naming the job-starting tools and clarifies it is for polling. The example URL adds specificity.

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?

Explicit guidance is provided: poll every 15-30 seconds, follow retry_after_seconds and next_action while pending, and prefer structured_result when complete. This tells the agent exactly when and how to use the tool versus alternatives, even including a URL example.

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