export_mesh

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

With no annotations, the description carries the full burden and does so well: it discloses that an existing file is deleted first when overwrite=true, that the document is not saved afterward, that OBJ emits a sidecar <name>.mtl file, and that file_units is ignored for 3MF. It also documents the return payload and warnings, so the agent knows both side effects and results.

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 with scope and formats, then constraints, then return shape, then a concrete example — a well-ordered structure with little wasted text. The parenthetical asides (OBJ sidecar, file_units warning) are dense but each carries real information.

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 12-parameter mutation tool with no annotations and no output schema, the description still covers preconditions, destructive overwrite semantics, the unsaved-document caveat, the return structure, and an example call. Nothing an agent needs to invoke it correctly is missing.

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 already 100%, so the baseline is 3; the description earns above that by adding a cross-field constraint the schema cannot express (deviation/aspect-ratio numbers are an error unless refinement='custom') and by noting the format/extension coupling. It does not add meaning for units vs file_units beyond what the schema titles/descriptions already say.

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?

Opens with a specific verb and resource ('Export the design, a component, an occurrence or a body as a mesh') and enumerates the supported formats. That scope statement clearly separates it from the sibling exporters export_cad and export_sketch_dxf.

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 mesh-format framing plus the refinement/custom rules give a clear context for use, and the description spells out what makes a call invalid (relative path, missing directory, mismatched extension, deviation params without refinement='custom'). It never explicitly contrasts itself with export_cad or export_sketch_dxf, so it falls short of full alternative routing.

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