Skip to main content
Glama
hjbaard

SolidWorks-MCP

by hjbaard

add_extruded_profile_on_face

Create a polygonal boss on any planar face by extruding a profile defined by 3D points, ideal for pads, ledges, and mounting blocks. Returns mass properties.

Instructions

Grow a polygon boss depth_mm out of ANY planar face: points_mm = [[x,y,z], ...] in mm.

The 3D points lie on the face (found as for add_hole_on_face). For pads, ledges and mounting blocks on an existing part. Returns mass properties.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
faceYes
nameNoBoss
depth_mmYes
points_mmYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the return value ('Returns mass properties') and the geometric precondition (points must lie on the face), but omits the extrusion direction, behavior on invalid/self-intersecting points, and any failure semantics for a mutating solid-modeling operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and the points format. Small redundancy: 'depth_mm out of ANY planar face' and the repeated mention of the face in the next sentence, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations, so the description does most of the work; it covers the return value and input constraint adequately. However, for a solid-modeling mutation it should also state the growth direction and what constitutes a valid face reference, which are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It clarifies points_mm format ([[x,y,z]] in mm), the role of depth_mm, and that the points must lie on the face, but leaves the 'face' identifier convention and the 'name' parameter (default 'Boss') undocumented. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('grow a polygon boss') and scopes it to 'ANY planar face', which separates it from add_extruded_profile (plane-based) and cut_profile_on_face (subtractive). It does not name those siblings explicitly, so full differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'For pads, ledges and mounting blocks on an existing part' gives use-case context, and the face-location hint ('found as for add_hole_on_face') tells the agent how to obtain a valid face. There is no statement of when NOT to use it or which sibling to prefer (e.g. add_boss_on_face vs add_extruded_profile).

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