export

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=false, so the write-and-risk profile is largely covered by structured data. The description adds real context not present in annotations: public geometry units are mm, degrees and kg, and the call surfaces "verified measurements and error evidence" rather than a bare success flag. It still omits that the call writes a file to a path, what refusal looks like on an existing target, and any rate or engine-session constraints, so it only marginally clears the lowered bar.

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?

Three short sentences with no filler, and the engine statement is front-loaded. However, the closing sentence "Inspect verified measurements and error evidence" is an imperative fragment with no object and reads as direction to the reader rather than description of tool output.

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?

A destructive, seven-parameter export with no output schema and 14% schema coverage needs the description to carry a lot, and it carries very little: no supported formats, no explanation of the fine/default quality knobs, no description of the evidence returned. The units disclosure is the one substantive contribution. An agent could invoke it but could not predict its side effects or choose correct parameter values.

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 14%: only overwrite is documented, and that documentation lives in the schema, not the description. The units sentence usefully pins down angle_deg (degrees) and deviation_mm (mm), but the required path parameter is never explained as an output destination, and quality, file_format and per_component are left with no meaning in either place.

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?

"Export through the independent native SOLIDWORKS engine" names the verb but never states what is exported (part, assembly, sketch, mesh) or to what destination. Siblings save_part, save_assembly, screenshot, make_drawing and pro_visualize_export all overlap with "export", and nothing in the description separates this tool from them. The "independent native SOLIDWORKS engine" phrasing is identity marketing rather than scope.

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?

There is no statement of when to choose this over save_part/save_assembly or the pro_visualize_export family. No prerequisites, no mention of what an agent must have open beforehand, and no when-not guidance despite a crowded sibling set of overlapping save/export tools.

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