Create a lofted solid from profile coordinates and height steps through the native SOLIDWORKS engine, with mm units and verified geometry measurements and error evidence.
Add lofted solid through the independent native SOLIDWORKS engine. Public geometry units are mm, degrees and kg. Inspect verified measurements and error evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Loft | |
| heights_mm | Yes | ||
| profiles_mm | Yes |
Changes observed during successful MCP inspections.
v0.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-readonly, destructive, non-idempotent write. The description adds unit conventions (mm, degrees, kg) and points at 'verified measurements and error evidence', which is useful context about what the call returns. However, it never says what a failed loft does to the existing model, whether the solid is added to the active part, or what 'verified measurements' concretely means.
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?
It is short and the action is front-loaded, but 'through the independent native SOLIDWORKS engine' is promotional filler, and 'Inspect verified measurements and error evidence' is vague phrasing that does not clearly tell the agent what to do with the result.
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 modeling operation with a complex nested input schema, no output schema, and no schema descriptions. The description should explain the profile and height inputs and the failure behavior; instead it covers units and a vague verification hint, leaving the hard parts undocumented.
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% and the schema is deeply nested: profiles_mm accepts either polygons of 2D points or circles with center_mm/diameter_mm, and heights_mm needs at least two values. The description explains none of this. The unit sentence at least confirms mm for the *_mm parameters, but the critical profile-format choice is undocumented.
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?
States a specific verb and resource: 'Add lofted solid'. That is clearly distinguishable from most siblings, but it never contrasts itself with 'loft_sketches', which sounds like the closest alternative, so the agent gets no help choosing between the two.
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 guidance, no prerequisite statement, and no mention of alternatives such as loft_sketches. The agent is left to infer that this is the loft creation tool and when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.