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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real context beyond them: the results are contextualized against published reference distributions with a minimum sample of eight videos, it explicitly disclaims any quality score or invented observations, and it warns that source uploads expire after 24 hours. That is meaningful behavioral disclosure, though it says nothing about error states or how frequently a caller should poll.

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?

Three sentences, all front-loaded and information-dense: capability first, then output semantics and limits, then the expiry caveat. No sentence is filler and nothing is buried.

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?

An output schema exists, so return values need not be explained, and the description handles the core semantics well. But for a tool with a 5-field nested filter object at 0% schema coverage, the definition leaves the agent without enough to construct a well-scoped call in the filtered case.

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 carries the full burden and fails: it never explains task_id beyond implied usage, and says nothing at all about the nested 'filters' object, which contains brand, aspect, industry, and min/max duration fields that are entirely undocumented. An agent would have to guess what those filters act on (reference distributions?) and whether they are optional tuning knobs.

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 gives a specific verb (Read) and resource (progress or measured result of your private render task), which clearly separates it from mutation siblings like create_render_upload or cancel_render. It does not explicitly distinguish itself from analysis siblings such as critique_render, compare_to_reference, or get_history, which keeps it from a 5.

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?

Calling this tool is clearly implied to be a polling step for a task identified by a task_id, and the mention of 'no quality score' hints at its boundaries. However, it never states when to use this tool instead of critique_render or compare_to_reference, nor does it say what to do while a task is still running.

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