export_dxf

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 discloses that the export runs without a dialog and returns pieces read back from the file as a check, which adds useful context. However, it does not mention whether the tool overwrites existing files, handles errors, or has any side effects beyond creating the file. This is a moderate disclosure but not exhaustive.

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 structured with a purpose statement up front followed by a parameter list. Each line in the Args block is necessary and adds value. There is no fluff or repetition. The format is efficient and easy to scan, though it could be slightly more compact.

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 moderate complexity (11 parameters, no output schema, no annotations), the description covers all parameters and the return behavior. It explains the output as a list of piece data (name, size, quantity, outline box in mm), which is helpful. It lacks explicit error handling or file overwrite behavior, but for an export tool this is a relatively complete specification.

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 explain parameters. It does so for every one of the 11 parameters in the Args block, adding meaning beyond the schema's titles and defaults (e.g., file_path must be an absolute path ending in .dxf, format values and their interpretation, metric as mm vs inches). The explanations are concise yet informative, covering all parameters adequately.

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 clearly states the tool exports a pattern as a DXF for CAD, plotters, and cutters, with a specific use case. It distinguishes itself from other export tools (obj, fbx, glb, etc.) by naming the DXF format and its target applications. However, it doesn't explicitly contrast with sibling export tools, so a 4 rather than 5.

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 via the format options (aama, astm, gerber) and target use cases (CAD, plotters, cutters), but it does not explicitly state when to choose this tool over alternatives or include any exclusions. It's clear enough for an agent to infer, but guidance is not overt.

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