Skip to main content
Glama
Sign In
SolidworksMCP-python

SolidworksMCP-python

by andrewbartels1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Add Fillet

add_fillet

Rounds edges of the active SolidWorks part with a constant-radius fillet using edge names, coordinate hints, face selection, or the current selection. Radius is in millimeters.

Instructions

Round edges of the active part with a constant-radius fillet.

Name the edges as "Edge<1>", a point "x,y,z" (metres) or "face:x,y,z" for every edge of a face; or leave edge_names empty to use the current selection (e.g. from select_face_edges). A fillet that leaves the volume unchanged is an error. Needs: an open part with a solid body. Changes: adds a Fillet feature. Returns: fillet with name, radius and edges.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input_data": "<input_data>"
    },
    "name": "add_fillet"
  }
}

Input Schema

NameRequiredDescriptionDefault
input_dataYesThe fillet. `radius` (mm) is required; `edge_names` defaults to the current selection.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / properties / input_data / description
      Previous value: -"Radius and edge names."New value: +"The fillet. `radius` (mm) is required; `edge_names`\ndefaults to the current selection."
  2. Changed1 schema field changedv1.5.0
    • changedInput schema / properties / input_data / properties / edge_names / description
      Previous value: -"Named edges to fillet (e.g. 'Edge<1>'). Leave empty to fillet all edges."New value: +"Edges (or faces) to fillet. Accepts a topology name (e.g. 'Edge<1>'), a coordinate hint in metres ('x,y,z') to select the nearest edge, or 'face:x,y,z' to select a whole face — which fillets every edge bounding it in one call. Prefer 'face:' over a coordinate on an edge that sits exactly on a shared boundary between two faces (e.g. a hole rim flush with a flat face): the nearest-edge match there can silently resolve to a different, unrelated edge. Leave empty to use whatever is *currently selected* in the live SolidWorks UI (e.g. entities read back via get_selected_entities and left selected) without touching the selection — this is the most reliable option when the user has hand-picked specific edges, since it never round-trips through coordinates. Falls back to filleting all edges only if nothing at all is selected."
  3. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations cover safety (readOnly false, destructive false, idempotent false), and the description adds real behavioral context beyond them: a prerequisite (open part with a solid body), the effect (adds a Fillet feature), an error condition (a fillet that leaves volume unchanged), and the return payload. It does not discuss whether existing features are affected or performance/rate considerations, but the mutation semantics are clear.

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-loaded purpose sentence followed by terse Needs/Changes/Returns blocks — well structured and scannable. The edge-naming sentence partially duplicates the schema's edge_names description, which is the only waste.

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 mutation tool with one nested parameter object and an output schema, the description supplies prerequisites, failure mode, and selection fallback semantics, so an agent can call it correctly. Return format is already covered by the output schema, so the description need not (and only briefly does) elaborate on it.

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 100% and the edge_names schema text already spells out Edge<n>, coordinate, and face: syntax along with the shared-boundary pitfall. The description largely restates this (with the extra note that empty means use the current selection), so it adds only marginal meaning beyond structured data, matching the baseline 3.

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?

The description opens with a specific verb and resource ("Round edges of the active part with a constant-radius fillet") plus the scope constraint (active part, constant radius), which is enough for an agent to distinguish this from unrelated tools. It does not explicitly contrast with the closest geometric sibling (add_chamfer), keeping it short of a 5.

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?

Gives concrete selection guidance: name edges as Edge<1>, use coordinates, use face: for a whole face, or leave empty to consume the live selection (pointing at select_face_edges/get_selected_entities as the source). It also explains the fallback-to-all-edges behavior if nothing is selected. It stops short of stating when not to use this tool (e.g. versus chamfer).

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