Skip to main content
Glama
hjbaard

SolidWorks-MCP

add_extruded_profile_on_face

Extrude a closed 3D point profile on any planar face to create pads, ledges, or mounting blocks at a given depth; 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. corner_radii_mm rounds the corners as for add_extruded_profile. Returns mass properties.

Input Schema

NameRequiredDescriptionDefault
faceYes
nameNoBoss
depth_mmYes
points_mmYes
corner_radii_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / corner_radii_mm
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "items": {},
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Corner Radii Mm"
      +}
  2. 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 does disclose a key constraint (points must lie on the face), the point format, corner-rounding behavior, and that it returns mass properties, but omits whether existing geometry is merged/union-ed, failure behavior if points miss the face, or any permission/rate considerations.

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?

Front-loads the action and required inputs in the first sentence, then adds constraint/usage detail. Cross-references are compact, though the reliance on 'as for add_hole_on_face'/'as for add_extruded_profile' slightly leans on the reader knowing siblings.

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?

For a 5-parameter, 0%-schema-coverage, no-annotation, no-output-schema tool, the description covers the core geometry params and return value but leaves the required 'face' selector and 'name' unexplained, so it is only partially complete.

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 description coverage is 0%, so the description must compensate. It explains points_mm ([[x,y,z]] in mm on the face), depth_mm (extrusion depth), and corner_radii_mm (rounds corners), but leaves the required 'face' parameter and the 'name' parameter undocumented.

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+resource: 'Grow a polygon boss ... out of ANY planar face,' with the required points_mm and depth_mm named. It distinguishes itself from the plane-based add_extruded_profile by scoping to 'ANY planar face,' though it does not explicitly separate itself from add_boss_on_face.

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?

Offers use-case context ('For pads, ledges and mounting blocks on an existing part') and analogizes to add_hole_on_face and add_extruded_profile, but gives no explicit when-to-use-vs-alternatives routing against the several similar siblings (add_boss_on_face, add_extruded_profile).

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