cad_cam

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description adds value by describing what each action actually produces: counts, toolpath length, bounding box for toolpath; length plus estimated machining time for simulate; and concrete G-code details (G0/G1, drilling cycles, M2 termination) for export_gcode. It goes beyond annotations but does not disclose error conditions or file overwrite semantics for the export action.

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?

An efficient bilingual layout: front-loaded English headline, a systematic triplet of bullets, and a trailing exclusion clause. Every bullet earns its place with concrete output details. The moderate redundancy between the headline and the bullets is minor, and the bilingual duplication of intent actually broadens accessibility without bloat.

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?

This dispatched tool has three distinct parameter modes, and the description covers all three thoroughly. Its geometry basis for each action is explained, and the output schema exists to document return values. Remaining gaps are minor: it doesn't explicitly state that a document must be open with valid contour/circle entities, nor how export_gcode handles existing files. For a compound tool of this complexity, these are acceptable omissions.

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 input schema has full description coverage, with each parameter already carrying types, defaults, and unit-level descriptions (mm/min, RPM, retract height). The tool description adds no parameter-level semantics beyond what the schema provides; it only contextualizes the geometry inputs (rectangles/polygons/circles), which is behavioral rather than parameter-specific. The baseline 3 is therefore appropriate.

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 opening sentence names a specific verb+resource combination — generate, simulate, or export 2.5-axis toolpaths (contour + drilling) — so the agent knows exactly what kind of CAM operation this is. The three action bullets add further precision, and the 'When not to use' clause explicitly announces the tool is out of scope for full 3D toolpaths, distinguishing it from related siblings like cad_sim.

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 contains an explicit 'When not to use' section stating that full 3D toolpaths and tool-axis control are out of scope, which gives the agent a clear exclusion rule. The positive usage conditions are conveyed through the action list ('current document geometry'), but no sibling tool is named as the alternative for the 3D case, leaving the routing slightly less explicit than ideal.

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