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

The annotations provide only basic hints (not read-only, not destructive, open-world). The description goes far beyond this: it explicitly states that STL exports run a watertight verify by default and that failures still write the file, it lists which exports write sidecar mesh files (urdf, sdf-gazebo, usd-isaac), it documents failure codes (export.mesh.not-watertight, export.part.not-found), and it specifies that 'All params except `target` are forwarded verbatim; each target fails closed on its own missing required params.' This is rich behavioral context that is not present in the annotations.

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 long (about 340 words) but packed with necessary details for 12 formats and two targets. It is front-loaded with the core instruction and then organized in two clear blocks with bolded target names. The sentence on STL verify and failure modes is a bit dense, but every sentence adds required information. It earns its length given the complexity, though a shorter summary at the top and more bullet formatting could improve scannability. Still, it is well-structured for its size.

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 huge parameter count (10) and nested object schema, the description covers all critical usage aspects: target selection, required vs optional parameters per target, per-format nuances (meshes written, verify behavior, failure codes), and the interaction between `options.format` and top-level `format`. The output schema exists and is rich, and the description explains what happens when the export fails (file still written, error codes). Nothing an agent needs to decide whether to call this tool and how to fill parameters is missing, aside from trivial details that are already in the schema.

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?

The schema description coverage is 100%, and the schema descriptions already explain each parameter's purpose. The description adds meaning by linking all parameters to their target-specific behavior (e.g., `output_path` for model vs part, `output_dir` for all parts, `no_verify` to skip watertight gate) and by describing the required vs optional status for each target. It also clarifies that `options` is a per-format bag and includes detailed semantics for svg-drawing annotations, sections, autoAnnotate, and joint drives. This is more valuable than a simple schema list, though some schema descriptions already cover basics, so the description adds moderate-high value.

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 starts with 'Use this when you need to export geometry to a file' and immediately introduces two distinct exporters selected by `target`, each with its own output format list, behavior, and file-writing details. It clearly differentiates from siblings like get_model_mesh (which fetches a mesh rather than writing files) and capture_animation (which records visual output). The resource (geometry/assembly) and action (export to file) are explicit, and the sub-modes are unambiguously specified.

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 provides explicit when-to-use ('Use this when you need to export geometry to a file') and then for each target details the required parameters and failure modes. It names the main alternative for reading geometry (get_model_mesh) implicitly by focusing on file export, and it mentions `inspect` as an alternative for BOM data ('same numbers as inspect({ of: 'bom' })'). It also gives guidance on what not to do (e.g., for part export, unknown part names fail; for STL, watertight verify is default). Very strong usage routing.

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