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

Annotations already declare readOnly/non-destructive/closed-world, so the description only needs to add context, and it does: it discloses the three distinct outcomes (in-progress percentage, the finished card with words/figures/chart/offers, and the connector's stop reason). That state-dependent return behavior is real value beyond the annotations.

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?

The main content is one rambling, clause-chained sentence riddled with semicolons and asides, so the key fact (this polls a chat-started run's progress) is not front-loaded. The Args block is clean, but the prose is hard to parse and would benefit from restructuring into discrete statements.

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 and 0% param coverage, the description does cover the return states and both parameter meanings. However, for a polling tool it omits how often to poll, terminate conditions for the loop, and how it relates to the many sibling progress tools, leaving gaps an agent must guess at.

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 carry both parameters, and it does: task_id is tied to 'the task_id the start answered with' and progress is defined as 'How far the card already shows the run, in percent.' This meaningfully compensates for the empty schema, though the optional/nullable status of progress at the API path is left unaddressed.

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 conveys that this polls a run started from the chat and returns the report card, but the phrasing ('For the report card only, which calls it while a run started from the chat goes on') is convoluted and never states a clean verb+resource. It does partially differentiate from siblings by scoping it to the chat-initiated run and the report card, but an agent would have to work to parse that out.

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?

There is an implied polling usage ('waiting a few seconds for it to move on'), but no explicit statement of when to call this versus the many sibling progress tools (circuit_progress, get_backtest_progress, get_pairs_scan_progress, etc.) or when to stop polling. The exclusion 'For the report card only' hints at a boundary but never names the alternative.

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