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

Beyond the annotations (readOnlyHint=true, openWorldHint=false, destructiveHint=false), the description discloses real behavior: the seal is verified, pinned inputs must match their recorded content or the call is refused by name, and only hypotheses lacking evidence whose last attempt failed or was deferred are re-executed with their original settings. That is strong disclosure of failure modes and selection logic. The one gap is persistence — 'continue' and 'hypotheses ... are run' imply the run file is written back, which sits in mild tension with readOnlyHint and is not clarified.

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?

A single front-loaded sentence whose clauses each carry distinct information — trigger, seal check, input-identity check, refusal behavior, hypothesis selection, and settings reuse. Nothing is repeated and nothing is filler.

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 nested-schema, 5-parameter tool with an output schema and full annotation coverage, the description covers the important runtime behavior: what is verified, what causes refusal, and what actually executes. What is missing is how the resumed run reports results and whether the caller needs any prior state (e.g. an unchanged working corpus), which would matter for a first-time caller.

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%, so the schema already defines run, _files, _subject, sequences and budget_seconds, including the deferral semantics of budget_seconds. The description adds meaning only indirectly, by explaining what resumption does with the registered corpus and settings. Baseline 3 is 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?

The description opens with a specific verb and resource ('Continue a research run from its file') and immediately scopes it to a precise condition ('after an interruption or a failed test'), which separates it cleanly from run_discovery_programme, research_run_status, list_research_runs and cancel_research_run without needing to name them.

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 trigger condition is explicit: use it when a run was interrupted or a test failed. It also implicitly excludes first-time runs, since the run must already exist as a file. It stops short of naming the sibling tools (e.g. research_run_status for inspection, run_discovery_programme for a fresh run), so the agent must infer the boundary.

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