Skip to main content
Glama
hjbaard

SolidWorks-MCP

by hjbaard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

cut_profile_through_plane

Cuts a polygon sketched on a reference plane symmetrically, either through all or a set depth, to create wedges, windows, or symmetric recesses.

Instructions

Cut a polygon sketched on a reference plane, symmetric about that plane.

plane: 'front' (z = 0), 'top' (y = 0), 'right' (x = 0) or the name of another plane in the part ('Plane1'); points_mm = 3D [x, y, z] points ON that plane (e.g. x = 0 for 'right'). Cuts through all in both directions (depth_mm omitted) or depth_mm in total, centred on the plane. For shapes seen from the side: wedges, windows, symmetric recesses. corner_radii_mm rounds the corners as for add_extruded_profile. keep_inside=True cuts away everything OUTSIDE the profile (through all): extrude the front view, cut the side view with keep_inside, and the part is the 3D shape both views agree on. Returns mass properties.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoCut
planeYes
depth_mmNo
points_mmYes
keep_insideNo
corner_radii_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.0
    • addedInput schema / properties / keep_inside
      Added value: +{
+  "default": false,
+  "title": "Keep Inside",
+  "type": "boolean"
+}
  2. 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"
+}
  3. First observedv0.4.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the default that omitting depth_mm cuts through all in both directions, that depth_mm is a total centered on the plane, and the semantics of keep_inside and corner_radii_mm. It even notes the return ('mass properties'). It does not cover permissions or reversibility, but for a geometry cut that is acceptable.

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?

Purpose is front-loaded in the first sentence, then parameters and usage details follow. The layered per-parameter notes are dense but each earns its place; the keep_inside example is a slight verbosity but clarifies an otherwise ambiguous flag.

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

Completeness5/5

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

For a 6-parameter, no-annotation, no-output-schema mutation tool, the description covers purpose, plane/point conventions, default behavior on omitted depth, the keep_inside workflow, and the return value. An agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 0%, so the description must teach the parameters, and it explains plane naming and the plane-coordinate implication ('x = 0 for right'), that points_mm are 3D points ON the plane, and how depth_mm/keep_inside/corner_radii_mm behave relative to add_extruded_profile. Only the 'name' parameter goes unexplained.

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

Purpose5/5

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

The first sentence names a specific verb and resource ('Cut a polygon sketched on a reference plane') and pins down the distinguishing behavior of the operation: symmetric about the plane, cutting through in both directions. That geometric specificity separates it from cut_profile, cut_profile_on_face, and cut_sketch without the agent having to open schemas.

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

Usage Guidelines4/5

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

It supplies concrete usage context ('For shapes seen from the side: wedges, windows, symmetric recesses') and a worked keep_inside workflow ('extrude the front view, cut the side view... the 3D shape both views agree on'). It stops short of naming an alternative tool or explicitly stating when-not to use this, so it lands just below the top.

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

Deploy Server

Other Tools