Skip to main content
Glama
Sign In
SolidworksMCP-python

SolidworksMCP-python

by andrewbartels1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Create Sketch

create_sketch

Opens a new 2D sketch on a chosen plane of the active part, ready for drawing lines, circles, and other entities, with optional naming for the feature tree.

Instructions

Open a new sketch on a plane of the active part, ready for lines, circles and other sketch entities.

Use it first in every feature: sketch, draw, exit_sketch, then create_extrusion or create_cut_extrude. Planes: Front, Top, Right (or XY, XZ, YZ), or a plane made by create_reference_plane. Coordinates in the sketch are mm from the origin. Needs: an open part. Changes: adds a sketch and opens it for editing; give sketch_name and exit_sketch names it that when it closes it (SolidWorks won't rename an open sketch). Returns: sketch with name (the name in the feature tree now) and plane, plus name_on_exit when you gave sketch_name.

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": "create_sketch"
  }
}

Input Schema

NameRequiredDescriptionDefault
input_dataYesThe sketch. `plane` is required; `sketch_name` names it.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.0
    • changedInput schema / properties / input_data / description
      Previous value: -"The input data value."New value: +"The sketch. `plane` is required; `sketch_name` names it."
    • changedInput schema / properties / input_data / properties / sketch_name / description
      Previous value: -"Sketch name alias"New value: +"Name to give the sketch in the feature tree, applied when exit_sketch closes it; omit to keep SolidWorks' own (Sketch1, Sketch2, ...)"
  2. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (which only mark it as a non-readonly, non-idempotent, non-destructive write), the description discloses that it adds and opens a sketch for editing, that SolidWorks will not rename an already-open sketch so naming is deferred to exit_sketch, and that coordinates are in mm from the origin. This is exactly the kind of side-effect and state context annotations cannot convey.

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 purpose is front-loaded and the follow-on sentences are organized into labeled Needs/Changes/Returns segments, so scanning is easy. The density of backticked identifiers makes it slightly heavy for a one-parameter tool, but nearly every clause carries actionable information.

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?

Even though an output schema exists, the description still summarizes the return shape (`sketch` with `name` and `plane`, plus `name_on_exit`), covering the deferred-naming nuance an agent needs to chain into exit_sketch. Preconditions, units, and sequencing are all present.

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 already 100%, so the baseline is 3; the description adds value by enumerating accepted plane identifiers (Front/Top/Right or XY/XZ/YZ, or a reference-plane-made plane) and by explaining the deferred-naming contract for `sketch_name`. It stops short of describing any format constraints on the name string itself.

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 opening sentence names a specific verb and resource ('Open a new sketch on a plane of the active part') and states the resulting state ('ready for lines, circles and other sketch entities'). It is immediately distinguishable from siblings like create_extrusion or exit_sketch.

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

Usage Guidelines5/5

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

Explicitly prescribes the workflow position ('Use it first in every feature: sketch, draw, `exit_sketch`, then `create_extrusion` or `create_cut_extrude`') and names the successor alternatives. It also states the precondition ('Needs: an open part') and where valid planes come from, including `create_reference_plane`.

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