export_run

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.