add_boss_on_face

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so much of the safety profile is carried for the description. In return the description adds a genuinely useful unit convention (mm, degrees, kg) and signals that measurements and error evidence come back. It never says what is modified or destroyed when a boss is placed, and the "independent native SOLIDWORKS engine" phrase is opaque.

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 the purpose front-loaded, so there is little waste. However, two of the three sentences are generic boilerplate that could appear on any tool in this family, and "Inspect verified measurements and error evidence" is vague enough to add little actionable 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?

This is a destructive geometry mutation with 8 undocumented parameters and no output schema, which is exactly the case where the description should do heavy lifting. It omits the face-reference format, the meaning of from_edges, the effect of the name default, and any statement about what happens on failure, leaving the agent unable to call it reliably from the definition alone.

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% across 8 parameters, so the description carries the full burden and only partially meets it: the mm/degrees/kg statement explains the unit suffixes on x_mm, y_mm, z_mm, height_mm, and diameter_mm. The most consequential parameters, `face` (what reference format is accepted) and `from_edges` (what it changes about placement), get no explanation at all.

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 states a specific verb and resource ("Add boss on face"), which is enough to separate it from additive siblings like add_box or add_cylinder. It does not explicitly distinguish itself from the closest neighbors add_hole_on_face, add_text_on_face, and add_extruded_profile_on_face, so an agent must infer the difference from the name alone.

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 guidance on when to choose this tool over add_extruded_profile_on_face or add_hole_on_face, nor any stated prerequisites such as an active document or a valid face reference. The only directive, "Inspect verified measurements and error evidence," concerns what to do after the call, not when to make it.

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