add_extruded_profile

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation profile is known. The description adds a genuinely useful convention (public geometry units are mm, degrees and kg) and hints that the result carries measurements and error evidence, but it never says what geometry is created or destroyed, whether the body merges into existing geometry (the merge flag), or what failure modes look like.

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, front-loaded with the action, with no filler. The closing sentence about "verified measurements and error evidence" is somewhat cryptic boilerplate, but the overall length is well matched to a small description.

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 an 8-parameter, 0%-documented, destructive modeling operation with no output schema and many near-identical siblings, the description is far too thin. An agent cannot determine required input shape beyond the field names or predict what the call will produce.

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 burden — yet it only supplies units. Nothing explains that points_mm must be at least three [x, y] pairs forming a closed polygon, what about_mm does, whether corner_radii_mm accepts a scalar versus a per-corner array, or how merge and name affect the result.

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?

"Add extruded profile" gives a verb and a resource, but it essentially restates the tool name and the extrusion family is enormous here (add_extruded_profile_on_plane, add_extruded_profile_on_face, extrude_sketch, add_revolved_profile, add_swept_profile, cut_profile...). The description never states what distinguishes this tool from those siblings — e.g. that it builds a body from an explicit point list rather than an existing sketch or face.

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 when-to-use or when-not-to-use guidance, and no alternative is named. With roughly a dozen overlapping extrusion/profile siblings, an agent is left to infer selection entirely from names, and "independent native SOLIDWORKS engine" does not resolve that choice.

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