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

Annotations already cover read-only/idempotent safety; the description adds behavioral detail about readiness and the returned payload: download link, filled-field count, and commit-specific receipt_url/package_url. It doesn't describe the not-ready state, but 'when ready' implies polling and the output schema covers the rest.

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 compact, front-loaded sentences with no filler. The job type scope appears first, followed by the actionable return details.

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 polling tool with an output schema and read-only/idempotent annotations, the description is nearly complete. The only notable gap is not explicitly stating that job_id should come from the response of the creating tool, though this is inferable from context.

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?

With 0% schema description coverage, the description must compensate. It implies job_id references one of the listed async job types, but it never explicitly says the ID is supplied by fill_form_from_context/prepare_form/commit_proposal or how to obtain it. Some meaning is added, but the parameter remains under-specified.

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?

Description uses a specific resource ('fill_form_from_context, prepare_form, or commit_proposal job') and a clear status-checking verb. It distinguishes get_job from sibling get_form/get_batch/get_fax/get_proposal by naming the exact job-producing operations.

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?

Clear context: use for checking jobs created by fill_form_from_context, prepare_form, or commit_proposal. It doesn't explicitly list sibling tools to avoid or state when not to use them, but the job-type scoping is enough to infer appropriate use.

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