export_document

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world operation, so the safety profile is covered. The description adds the useful behavioral fact of which file formats are produced, but omits that it writes a file to the given path, whether existing files are overwritten, and what happens with invalid geometry.

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 tight sentence with the verb and resource front-loaded and formats listed compactly. It is not padded, though the format list dominates while more critical parameter meaning is absent.

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?

Although an output schema exists and return values need not be described, this is a file-writing mutation with four undocumented parameters at 0% schema coverage. The description should at minimum explain path, doc_name defaults, and whether object_names selects a subset or exports the whole document.

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 carries the full burden, yet it only effectively explains export_format (formats list) and hints at object_names ('Bodies or solids'). The required path parameter, doc_name and its defaults, and what null object_names means (all objects vs. none) are left entirely undocumented.

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?

States a specific verb (Export) plus the resource (Bodies or solids) and enumerates the concrete output formats, so an agent knows exactly what the tool produces. It does not distinguish itself from siblings like export_techdraw_page, which also exports geometry to a file.

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 phrase 'Bodies or solids' implies the scope of usage (model geometry rather than drawings), but there is no explicit when-to-use/when-not guidance versus save_document or export_techdraw_page, and no prerequisites (e.g., an open, active document) are stated.

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