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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world profile, so the safety story is covered. The description adds genuinely new behavior beyond that: it is cost-free and it carries a polling/rate-limit expectation of at least 30 seconds between calls. It does not describe pagination or error behavior, but for a read-only poll endpoint this is strong added context.

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?

Four short sentences that each do distinct work: purpose and return fields first, then the completion handoff, then cost, then the polling constraint. No filler and the core action is front-loaded.

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?

With no output schema, the description compensates by naming exactly what comes back (status, stage, ETA) and enumerating the status vocabulary. Combined with the 30-second polling rule, cost note, and get_downloads follow-up, an agent has everything needed to call and interpret this read-only endpoint.

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 100% with a single documented run_id ('제작(프로젝트) 번호'), so the schema already carries the parameter meaning. The description only restates '한 건' conceptually and adds no format, source, or lookup guidance for run_id beyond what the schema provides, making the baseline 3 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?

States a specific verb and resource ('제작 한 건의 상태... 봅니다') with explicit scope limited to a single run, plus the exact returned fields (status, progress stage, ETA) and the enumerated status values. The '한 건' scoping lets an agent separate it from the list-oriented sibling vidia_list_runs without opening a schema.

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?

Gives explicit operating instructions ('30초 이상 간격으로 확인하세요'), notes the tool is free, and routes the agent to the correct next step once the run finishes ('완성되면 vidia_get_downloads 로 받습니다'). Both the when and the follow-up alternative are named rather than left to inference.

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