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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the semantics of the comparison (percentage of 'confidently wrong' vs accuracy, broken out per language), which is real behavioral context, but says nothing about read-only nature, permissions, cost of aggregating multiple runs, or failure modes for invalid run IDs.

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 one-sentence summary followed by a short Args block, with little waste. The Args entry is nearly redundant with its own wording ('the runs to compare'), but it does document the only parameter where the schema has no descriptions.

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 the description is not obliged to explain return values, and it already hints at the compared metrics. For a single-parameter tool this is nearly complete; what is missing is any note on run comparability (e.g. same dataset/model) or behavior on invalid IDs.

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. 'run_ids: the runs to compare' tells the agent to pass run identifiers and that plural runs are expected, but adds no format, count limits, or ordering semantics beyond the schema's array-of-strings definition.

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?

Specific verb (compare) plus resource (runs) and even names the outputs computed (confidently-wrong % and accuracy % per language). The phrase 'for several runs (e.g. different models)' implicitly separates it from the single-run siblings like get_report and run_status, but no sibling is named explicitly.

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?

Usage is implied rather than stated: the agent can infer this is the tool to reach for when more than one run exists. There is no explicit when-to-use/when-not guidance and no named alternative versus get_report or export_run.

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 full burden. It usefully discloses the side effect (a file is written), the encoding choice (UTF-8 with BOM, for Excel/Urdu rendering), and the return value (file path). However it omits overwrite behavior, where the file is placed, permission requirements, and what happens if the run is missing or incomplete.

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 first sentence front-loads the essential information about what is written and how it is encoded; the Args block is brief. The trailing 'Args:' line is somewhat boilerplate and only echoes the schema, but nothing is bloated.

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 explaining return values is not required, yet the description still mentions the file path. What is missing is operational context: preconditions on run state, overwrite/error behavior, and guidance on choosing this tool over sibling reporting tools. Adequate but with clear gaps.

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% for the single run_id parameter, so the description must compensate. Its gloss, 'the run to export,' is close to restating the parameter name and gives no format, provenance (e.g., from start_run), or validity constraints. For one simple string parameter this is minimally acceptable but adds little.

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 names a specific verb (write/export to CSV) and resource (a run's questions, answers, verdicts, confidence scores, hedge matches), and it enumerates exactly which fields land in the file. It does not explicitly differentiate itself from siblings like get_report or compare_runs, so an agent must infer the distinction.

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?

Beyond the phrase 'the run to export,' there is no when-to-use guidance: nothing says when to prefer this over get_report or compare_runs, nor whether the run must be completed before exporting. The usage context is left entirely to inference.

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 full behavioral burden, and it discloses the report's content categories but not its operational traits: whether it requires a completed run, whether it is read-only or persists anything, cost or latency, or permission needs. The content enumeration adds some value, though it partially overlaps with the existing output schema.

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 section list is compressed into one front-loaded sentence and the Args block is minimal, with no filler. The opening sentence is a dense comma list rather than a clean 'generates a Markdown report for a run' framing, which slightly blunts front-loading.

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?

Because an output schema exists, return values need not be described, and the description is adequate for a reporting tool. However, for a lifecycle-bound tool surrounded by start_run/run_status/resume_run siblings, the omission of any prerequisite (e.g. run must be complete) leaves a real gap.

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%, yet the Args block glosses all three parameters meaningfully: run_id identifies the target run, examples controls how many confidently-wrong answers are quoted, and per_question toggles the grid. This compensates well for the empty schema, though the glosses remain terse.

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 concrete artifact and enumerates its contents ('confidently-wrong rate per language, accuracy, confidence when right vs wrong, hedge-word cross-check, language gaps, per-question grid and example answers'), so an agent knows exactly what this produces. It implicitly separates itself from compare_runs and export_run, but never names those siblings. Clear but no explicit sibling differentiation.

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 use this tool versus compare_runs or export_run, and no precondition such as the run needing to be finished. Usage is only inferable from the run_id parameter and the report's analytical framing. No exclusions or alternatives are offered.

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?

No annotations are provided, so the description carries the full burden. 'Show' implies a read-only operation and the field list hints at the response shape, but there is nothing about permissions, side effects, pagination, or whether the custom file is read or written. It covers the basics but leaves real 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?

The lead sentence front-loads purpose and returned fields, then a compact Args block covers the three parameters. No filler; the structure is easy to scan.

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 an output schema present the description need not explain return values in depth, and the three parameters are each addressed despite 0% schema coverage. The main gap is the absence of any behavioral/permission context, which is a modest shortfall for a simple listing tool.

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, and it largely does: it enumerates the allowed category values, explains that language selects a version or 'all' for all three, and documents the questions_file default resolution via SBW_QUESTIONS or the built-in bank. Only minor format details are missing.

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 ('Show') and resource ('the question bank') and enumerates the returned fields (id, category, difficulty, question text, reference answer). It is clearly distinguishable from the run-management siblings, though it never explicitly frames itself against any alternative.

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?

Usage is implied by the name and the parameter semantics (inspect the bank, optionally filtered by category/language), but there is no explicit statement of when to reach for this tool versus other means of inspecting questions. Adequate minimum-viable guidance, no exclusions or alternatives.

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 full burden. It usefully discloses that the check is lightweight ('one tiny request') and validates both reachability and auth, but says nothing about failure behavior, error surfacing, rate limits, or cost beyond the request being tiny.

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?

Purpose is front-loaded in one sentence and the args note is short. The 'Args:' block is mildly boilerplate since it repeats the param name, but the format guidance justifies its presence.

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 no explanation, and the single parameter is fully specified. The only real omission is failure behavior, which is minor for a low-risk ping utility.

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% and the single param is an undescribed string, so the description must compensate. It does so well by giving the required 'provider:model' format plus two concrete examples covering both cloud and local providers.

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: it checks that a model is reachable and its API key works. This is unambiguous and, given the run/report-oriented siblings, self-evidently a distinct diagnostic utility that needs no differentiation.

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 stated purpose implies usage (validating a model/provider before launching a run), but there is no explicit when-to-use, when-not, or named alternative. The context is implied rather than spelled out.

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?

No annotations are provided, so the description carries the full disclosure burden. It usefully explains that failed items are retried and unprocessed ones finished, and clarifies the wait flag's blocking behavior, but omits whether the call is idempotent, what state it mutates on the existing run, and any permission 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?

Purpose is front-loaded in one sentence, followed by a compact Args block with no filler. The structure is efficient, though the Args list is a slightly verbose way to convey three short hints.

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 covers the core mutation behavior plus the wait-mode return. Remaining gaps (idempotency, effect on already-completed items) are minor for a resume tool.

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, and it does: run_id ('the run to resume'), concurrency ('parallel questions in flight'), and wait ('block until finished and return the report') are each given meaning beyond the bare type. It could still clarify the concurrency default of 4.

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: retry failed items and finish unprocessed ones on a run. It is clearly distinguishable from start_run (new run) and run_status/get_report (read-only inspection), though it does not name those siblings explicitly.

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?

It gives a clear when-to-use condition: 'after an interruption or rate-limit errors.' However, it names no alternatives or exclusions (e.g. when to call start_run vs resume_run), so the routing guidance is incomplete.

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?

No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral nuance — omitting run_id switches from a single-run check to a recent-runs listing — which is useful. However, it says nothing about read-only nature, permissions, pagination, or truncation limits, leaving meaningful behavioral gaps for a tool with zero annotation coverage.

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 compact sentences, front-loaded with the primary behavior before the argument details. The Args block is slightly mechanical and restates run_id ('the run to check'), but nothing is padded or wasteful.

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?

A read-only status tool with an output schema, so return-value documentation is not required. Both parameters and both operating modes are explained. Minor gaps remain around error behavior for an invalid run_id and whether the recent-runs list is bounded, but the definition is sufficient to call the tool correctly.

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, and it largely does: run_id is 'the run to check' and limit is scoped to only apply 'when run_id is omitted.' That conditional coupling of limit to run_id is not derivable from the schema, which only shows types and defaults. It omits the default value (15) and acceptable ranges, keeping it from a 5.

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 resource and operation: 'Progress of one run, or a list of recent runs.' The dual behavior is spelled out up front, so an agent can tell it apart from siblings like start_run, resume_run, get_report, and compare_runs, which all do something different. It does not explicitly name a sibling, so it falls short of the top tier.

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 condition selecting each mode is explicit: provide run_id to check one run, omit it to list recent runs. This is real routing guidance rather than implied usage. There are no exclusions or prerequisites (e.g., auth, valid state), so it stops at 4.

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 full behavioral burden and does well: async execution and run_id return, blocking behavior and client-timeout risk with wait=True, the judge env fallback that is 'not recommended', and rate-limit pressure on concurrency. It omits cost/auth implications, but the async and timeout semantics are exactly the traits an agent needs.

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 one-line purpose is front-loaded and every args entry earns its place with a concrete hint rather than restating the schema. It is long, but the length is driven by 12 genuinely distinct parameters rather than padding.

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 eval launcher with 12 parameters and an output schema present, the description covers execution model, return contract (run_id vs report), defaults, and filtering knobs. An agent has everything needed to invoke it correctly without inspecting source.

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% across 12 parameters, so the description must compensate and does: target/judge 'provider:model' format with an example, languages enum subset, question_ids/categories filters, limit as a cheap trial knob, temperature null meaning model default, system_prompt default 'none like a plain chat', max_tokens, concurrency, and questions_file as a custom bank path.

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 opening sentence gives a specific verb and resource: it asks the target model every question per language, grades each answer, and records confident-but-wrong answers. This is clearly an eval-launch tool, distinct from siblings like run_status, get_report, and resume_run.

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?

It states the key usage fork (background run returning a run_id vs wait=True blocking for the report, with timeout risk on big runs) and practical conditions like lowering concurrency on rate limits and using limit for a cheap trial. It never names the sibling tools (run_status/get_report) as the polling alternative, so it stops short of explicit when-not guidance.

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