CAM Forge

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

Annotations provide readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial behavioral context: guarantees wall thickness by construction, watertight STL with signed-volume integrity check, non-watertight results FAIL with mesh refunded, deterministic same-bytes output, and over-cap request rejection. The only gap is it doesn't disclose the 15 MESH/call cost or auth requirements beyond the cost line in parentheses.

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 information-dense but well-organized: opens with the core value proposition, then behavioral guarantees, use cases, parameters, caps, and return format. It front-loads the key action (generative fabrication tool) and packs substantial detail into a compact block. Slightly long but every sentence carries distinct 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 1-nested-parameter, complex tool with 100% schema coverage, the description covers purpose, guarantees, failure modes, caps, return shape, and use cases. No output schema exists, so it handily lists the return fields (format, encoding, content, volume_check, stats, params). It could add the 15 MESH/call pricing detail more explicitly rather than as a parenthetical aside.

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 100%, so the schema documents all parameters well. The description adds aggregate context (all input in mm, default values, coordinate meanings like density fraction and jpos organic look) but the per-parameter detail lives in the schema. This is the baseline-3 scenario where the schema does the heavy lifting and the description supplements with overall ranges and semantics.

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 has a very specific verb+resource: 'Turn parameters into a manufacturable file' for fabrication, listing exact output formats (STL, DXF, SVG) and use cases (vent panels, speaker grilles, acoustic diffusers). It clearly distinguishes from siblings like character-forge and mesh_follow by emphasizing kernel-free parametric fabrication output.

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 explicitly states when to use it ('Use for vent panels, speaker grilles, acoustic diffusers, lattice infill plates, decorative screens') and lists hard caps (<=600 cells, <=60000 triangles) with rejection behavior. It also notes deterministic output and no model call, clarifying it's a parametric generator rather than a mesh-altering tool like mesh_follow.

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