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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that – a finished run is required, and the response carries the run's anchor plus any look-ahead warning (point-in-time caveat). It says nothing about error behavior for an unfinished/unknown task_id, which is the main remaining gap.

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 text is one long run-on construction with hedging filler ('and the like') and an awkward clause ('The figures ... come with `get_primitives_run_progress` as `result`, and from `summarize_workflow`') that obscures rather than front-loads the key point. The useful content (which tier fields are returned) is buried mid-sentence.

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 does take on the burden of enumerating return fields, and it lists them reasonably well (tiers, market-state label, dates, beat-holding flag, rounded return, Sharpe, worst drop, trades, anchor, look-ahead warning). But it omits the required task_id entirely and gives no indication of result volume, ordering, or what happens for an unfinished run.

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?

There is a single required parameter, task_id, and schema description coverage is 0% – the schema gives only a title. The description never mentions task_id or explains that it identifies the run whose result is returned, so it does not compensate for the coverage gap; an agent must guess what the identifier refers to (task vs. project branch).

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 the content of the response (per-circuit tier rows with performance_tier, drawdown_band, trades_tier, skill_band, market-state labels) but never states a verb or says it fetches a result for a given task. Its differentiation from get_primitives_run_progress and summarize_workflow is attempted but muddled – it tells the agent the numeric figures 'come with' those other tools, leaving it unclear exactly what this tool returns on its own.

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 outcome of a finished lab run' implies a prerequisite (the run must have completed) and implicitly routes in-progress polling to get_primitives_run_progress. However, there is no explicit statement of when to call this versus summarize_workflow or what to do if the run is not finished, so usage must be inferred.

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