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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior: the answer may be provisional ('so far') or final, it carries a confidence value, and findings are classified as verified/assumption/guess. It does not say what happens when no answer exists yet or whether this blocks until completion.

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?

One compact sentence with no filler, front-loaded with the most important notion (the best/final answer). It spends its words on payload contents rather than the action, but nothing is wasted.

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 and the description repeats some of it, so return values are covered; the remaining hole is the unexplained required 'id' and the absence of any precondition information for a tool that clearly depends on a prior start_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?

The single parameter 'id' has no schema description (0% coverage) and the description never mentions it. Whether it is a run id, an answer id, or something else is left ambiguous, which is a real risk given sibling tools that also operate on runs.

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 reads as a summary of the return payload ('best answer so far, its confidence, findings tagged verified/assumption/guess') rather than stating the action: retrieve the current or final answer for a given run. It is understandable but does not distinguish itself from the sibling run_status, which plausibly also reports run progress.

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 no statement of when to call this instead of run_status, nor any prerequisite (e.g., a run must have been started via start_run). The agent must infer the usage entirely from the name and sibling list.

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

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

With no annotations provided, the description carries the full burden, but it only names artifact categories. It does not clarify that this is a listing/read-only operation, whether it returns metadata or file contents, ordering, pagination, or authorization requirements.

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 definition is a single efficient sentence with useful parenthetical examples and no wasted words. Its fragmentary structure slightly weakens front-loading because the leading 'Files' can be misread as a verb.

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 one-parameter listing tool with an output schema, the description still omits critical context: that id is the run id, how this differs from read_file, and what 'files' means operationally. The output schema reduces the need to describe returns, but the invocation semantics remain incomplete.

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 coverage is 0%, so the description must compensate for the undocumented id parameter. 'The run' implies id is a run identifier, but the description never explicitly maps id to run, nor explains its format or required nature.

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 identifies the resource as files produced by a run and gives examples of artifact types, but it does not state the action ('list') explicitly. It is distinguishable from read_file only indirectly, and the fragmentary phrasing makes the purpose vaguer than the tool name alone.

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 no guidance on when to use list_files versus read_file or other siblings, nor any mention of prerequisites or context. The agent is left to infer usage entirely from the tool name and description.

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

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

With no annotations, the description carries the behavioral disclosure burden and does add useful traits: text is returned as text up to 200 KB, and images as images up to 1 MB. However, it omits behavior for oversized files, errors, permissions, and whether reading has side effects or truncation rules.

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 description is a single front-loaded sentence with no wasted words. The key capability and size limits are stated immediately.

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 simple read tool this is partially complete: it explains output modality and size caps. But with no annotations, no parameter descriptions, and no output schema, the missing id/path semantics and error behavior leave meaningful gaps for correct invocation.

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%, and the description does not explain the two required parameters at all. It never clarifies what 'id' identifies or what 'path' is relative to, so the parameters remain ambiguous.

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 states a specific verb and resource: reading one produced file, with text and image variants. It is clear enough to distinguish this from broad sibling operations like list_files, though it does not explicitly name or contrast against the siblings.

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 description gives no explicit when-to-use guidance, alternatives, or prerequisites. An agent can infer that it should be used when file contents are needed, but the definition does not state when to prefer list_files or get_answer instead.

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

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

With no annotations, the description carries more burden, but it does disclose the kind of status information returned: round, best score, and stop reason. It implies a read-only status check but does not state permissions, rate behavior, or lifecycle constraints.

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 description is a single efficient sentence with the core purpose front-loaded. Every phrase adds information about what status includes.

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?

The output schema already exists, so the description need not explain return values in detail. However, for a one-parameter status tool with no annotations, it should clarify the id parameter and typical usage context more explicitly.

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?

The single required parameter 'id' has 0% schema description coverage and the description does not explain that it identifies the run. The agent can infer it from the tool context, but the description adds no parameter-level meaning.

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 states the tool retrieves run status and specifies the useful contents: round, best score so far, and why it stopped once finished. It distinguishes itself conceptually from mutation siblings like start_run and stop_run, though it does not explicitly 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?

There is no explicit guidance on when to call this versus alternatives such as stop_run or start_run. The phrase 'once finished' implies it can be used to check completion, but the agent is left to infer polling and lifecycle usage.

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

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

With no annotations, the description carries the burden and does well: it discloses the async/long-running nature ('runs take several minutes') and what is returned ('the run id'), which is exactly the behavior an agent needs before calling. It does not say whether runs are costly, cancellable (stop_run exists), or whether max_rounds changes cost/latency, leaving some behavioral gaps.

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?

Front-loaded with purpose, then compact per-parameter glosses, then the follow-up workflow in one clause. Every sentence carries information; nothing is padded.

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 an async job-starting tool with an output schema, the description covers the essentials: what it does, the meaningful inputs, and the polling path. The unexplained max_rounds parameter is the main remaining hole.

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 must compensate. It gives useful semantics for three of five params ('given': facts kept exactly as written; 'standards': what a good answer must do; 'pitfalls': mistakes to avoid), but 'problem' and 'max_rounds' — the latter being a knob with real cost implications — are never mentioned.

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 ('Start a ThinkerWave run') plus scope ('hard, open-ended problem'), which distinguishes it from sibling tools that are all about inspecting or stopping existing runs. An agent can route the request without opening the 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?

Explicitly frames the intended input class ('hard, open-ended problem') and prescribes the downstream workflow: 'check back with run_status, then get_answer', naming both siblings in order. It lacks an explicit when-not (e.g. don't use for quick/simple questions), which keeps it below a 5.

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

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

With no annotations, the description carries the whole burden; it does disclose one genuinely useful behavioral trait — partial results are preserved ('best answer so far is kept'). It omits whether stopping is idempotent, what happens if the run is already finished, and whether this is synchronous or asynchronous.

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?

Two short sentences with the action front-loaded and the key side effect second — no waste. It is efficient, though its brevity contributes to the specification gaps noted elsewhere.

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 result-preservation note covers the main outcome. However, for a lifecycle-mutating tool with no annotations and an undocumented id parameter, more about preconditions and post-conditions would be needed to call it confidently.

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?

The single required parameter 'id' has 0% schema description coverage and is never mentioned in the description. The agent gets no clarification on whether it is a run ID, job ID, or something else, so the description fails to compensate for the schema gap.

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 + resource ('Stop a run'), which is enough for an agent to distinguish it from start_run and run_status. It does not explicitly contrast with siblings, but the name/semantics make the distinction obvious.

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?

No guidance on when to stop versus when to poll with run_status or fetch results with get_answer. The agent must infer the workflow (e.g., check status first, then stop) entirely on its own.

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