Export the plan

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

Annotations indicate destructiveHint=true, so the description must disclose the destructive nature. It does, by stating 'Export to a file' – implying file creation/overwrite without explicit confirmation. It adds context about format-specific behaviors: `.pdf` has scale options, `.png` supports width/height, others are true scale. This goes beyond the annotations, giving the agent safety-critical details about side effects. No contradiction with annotations; the description reinforces the destructive hint by implying file system changes.

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, compact sentence that packs all essential information: formats, key options, and scale behavior. It is front-loaded with the primary action and quickly covers format-specific details, with no wasted words. Every clause earns its place, providing high information density.

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?

Given the tool's complexity (multiple formats, scale options) and the output schema, the description covers the main usage patterns. It does not explain return values, but the output schema exists, so that is not required. It lacks details on how the export path is used, but the schema covers that. Slight gap: it doesn't mention error conditions (e.g., missing extensions) but the format guidance mitigates that. Overall, it is complete enough for typical use.

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 100%, so parameters are fully documented in the schema, giving a baseline of 3. The description adds value by explaining format-dependent behavior: for `.pdf`, it specifies scale options and fitting; for `.png`, it mentions dimensions; and it clarifies that `.svg` is true scale. This enhances understanding beyond the schema, justifying a 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 uses a specific verb ('Export') and clearly states the resource and key behavior: exporting to various file formats determined by the file extension. It lists the formats (`.pdf`, `.svg`, `.png`, `.glb`, `.obj`), making the purpose unmistakable. It also differentiates from siblings like 'export_cut_list' and 'render_plan' by specifying what it exports (the plan) and the output formats.

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 usage: 'Export to a file by extension' indicates the decision is based on the file extension, which is a clear contextual rule. It does not explicitly mention when not to use it or name alternatives like 'render_plan' for image rendering, but it provides enough context for an agent to infer when this tool is appropriate. The omission of explicit exclusions keeps the score below 5, but the guidance is clear.

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