Skip to main content
Glama
Sign In
SolidworksMCP-python

SolidworksMCP-python

by andrewbartels1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_assembly

Creates a new SolidWorks assembly document from a specified template or the default, making it active and ready for component insertion, mating, and assembly-level operations.

Instructions

Create a new SolidWorks assembly document.

Creates a new SolidWorks assembly document from template (a .asmdot path) or, without one, the default assembly template. The new assembly becomes the active document and is ready for component insertion, mating, and assembly-level operations.

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_assembly"
  }
}

Input Schema

NameRequiredDescriptionDefault
input_dataYesThe input data value.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • changedInput schema / properties / input_data / properties / template / description
      Previous value: -"Assembly template file path"New value: +"Assembly template (.asmdot) path; omit to use the SolidWorks default"
  2. First observedv1.0.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 usefully discloses two side effects: the document becomes the active document, and an unspecified default template is used when none is passed. It says nothing about whether anything is written to disk, whether name is a filename/path, what happens on an invalid template path, or whether the call fails when the template is missing.

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?

Three tight sentences with the core action front-loaded. The final clause about component insertion and mating is the weakest part but still conveys the post-creation state, so it broadly earns its place.

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?

An output schema exists so return values need not be described, and the schema is fully documented. However, the tool takes a nested input object with a `components` field that the description entirely ignores, leaving the agent unsure whether to supply components at creation time or call insert_component afterward.

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 100% and already explains that name is the assembly name and template is an .asmdot path defaulting to the SolidWorks default, so the description adds no new parameter detail. Notably it never addresses the `components` array, and its "ready for component insertion" phrasing creates ambiguity about whether components are inserted at creation or afterwards.

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?

Opens with a specific verb + resource ("Create a new SolidWorks assembly document"), which cleanly separates it from create_part, create_drawing, and load_assembly among the siblings. It does not name those siblings explicitly, so the differentiation is inferable rather than stated.

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 implies the usage flow ("ready for component insertion, mating, and assembly-level operations") and explains the template-or-default choice, but never states when an agent should call this versus load_assembly (open existing) or create_part. No exclusions or prerequisites are given.

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