Skip to main content
Glama
NejcDvorsek

SolidWorks MCP

by NejcDvorsek

add_loft

Create a lofted solid or cut by blending two or more closed sketches or coordinate profiles across parallel planes, with optional cut and mass-property results.

Instructions

Loft (blend) 2+ closed profiles, given one of two ways.

  • sketches=['Heel', 'Toe']: closed sketches by name (add_sketch on any planes), in order; cut=True cuts the lofted shape away (a straight bevel gear's tooth gap is a loft cut between heel and toe profiles).

  • profiles_mm + heights_mm: per profile a polygon [[x,y], ...] (mm) in Front-plane coords, or a round section {"center_mm": [x, y], "diameter_mm": d}, on parallel planes at heights_mm along +Z (same length, strictly increasing, starting at 0). A 2-profile loft is a ruled transition; 3+ blend smoothly. Each profile starts at its first vertex (a round one on +x).

Give profiles in the same order and sense so they do not twist. Returns mass properties.

Input Schema

NameRequiredDescriptionDefault
cutNo
nameNo
sketchesNo
heights_mmNo
profiles_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.16.3

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden well: it explains cut semantics, profile ordering/twist risk, blend behavior, and that mass properties are returned. It still omits permission requirements, failure modes, and document-modification details, but adds substantial context beyond the schema.

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?

The description is front-loaded with the core operation and organized into two clear input modes. It is dense and mostly earns its length, though the multi-line format could be slightly tighter for a tool definition.

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

Completeness4/5

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

For a complex loft feature with no annotations and no output schema, the description gives enough detail on input modes, constraints, and return behavior. It remains incomplete only around the missing name parameter and unstated failure conditions.

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 document all five parameters. It explains sketches, cut, profiles_mm, and heights_mm formats and constraints in detail, but never mentions the name parameter, leaving one 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 CAD operation: lofting/blending 2+ closed profiles, with two input modes. It is clear what the tool creates, but it does not explicitly contrast itself with siblings like add_swept_profile or add_revolved_profile.

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?

The description explains the two ways to supply profiles and gives constraints such as ordering and height rules. However, it does not explicitly say when to choose loft over alternative sibling tools or when not to use it.

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