export_report

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 does disclose the key write side effect ('saved to .checkride/ directory'), which tells the agent this tool mutates the filesystem. However, it doesn't disclose whether existing reports are overwritten, whether prior check results must exist, or what the return value is. The core side effect is disclosed but edge behaviors are omitted.

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 15-word sentence that front-loads the verb and purpose, immediately states the output formats and destination. There is zero filler — every word earns its place. The most decision-relevant information (what it produces, in what formats, where it writes) appears in the first clause.

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 tool with 2 optional parameters, no output schema, and no nested objects, the description is largely sufficient: it covers purpose, formats, and destination. The main gap is prerequisites — an agent isn't told that validation results must already exist for a report to be meaningful. Given the tool's simplicity and the clear destination disclosure, this minor omission doesn't warrant lowering below 4.

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% — both 'format' (with enum and default) and 'project_path' are documented in the schema. The tool description adds no parameter-level detail beyond what the schema provides, but it aligns with the schema by naming both supported formats. Baseline 3 is appropriate since the schema carries the full parameter documentation burden.

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 uses a specific verb ('Generate') and precisely names the resource ('visual Markdown or HTML validation reports') plus the destination ('.checkride/ directory'). It distinguishes itself clearly from all siblings, which are check/audit/test execution tools — this is the only report-generation tool in the set, so an agent can identify it unambiguously.

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 implies its usage context — validation reports must be generated from validation results, so it naturally follows the check-running siblings. However, there is no explicit statement of when to use it versus alternatives, no mention that it should be run after run_checks or run_security_audit, and no exclusion guidance. The timing is left to inference.

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