Get Download Status

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does reveal the core trait — that this is a polling operation intended for non-blocking, repeated status checks rather than a blocking wait. However, it does not disclose terminal states (how the agent recognizes completion or failure), whether the result is consumed by polling, or error behavior for invalid/expired job_ids.

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?

Twelve words, front-loaded with the operative verb, and every phrase earns its place: 'Poll' states the mode, 'download progress' the resource, 'job_id returned by download_model' the parameter provenance. Zero filler or repetition of the title.

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 simple one-parameter polling tool the core usage is adequately covered, but with no output schema and no annotations the description should arguably state what the response contains (progress percentage? status enum?) so an agent knows when to stop polling. This is a real gap: a poller needs a terminal condition to recognize completion.

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 0%, so the description must compensate — and it does meaningfully. The phrase 'returned by download_model' tells the agent exactly where to obtain the job_id value, which is the single most important semantic fact about the parameter and is completely absent from the schema. It could add format hints, but provenance is the critical gap filled.

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 uses a specific verb ('Poll'), a precise resource ('download progress'), and anchors the parameter provenance ('job_id returned by download_model'). This immediately distinguishes it from download_model (which starts the job), download_and_wait, and download_and_test without requiring an agent to inspect sibling schemas.

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 establishes a clear usage context: this is a polling follow-up to download_model, implying the agent should call it repeatedly after initiating a download. It stops short of naming alternatives or stating when-not-to-use (e.g., preferring download_and_wait for blocking scenarios), but the context is clear enough that no exclusions would be strictly required.

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