Skip to main content
Glama
rskproductions

solidworks-mcp-python

by rskproductions
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sw_execute_script

Execute Python code against a live SOLIDWORKS COM session to automate modeling, assemblies, mates, interference checks, and STEP/DXF exports.

Instructions

Ejecuta Python arbitrario contra la sesion de SOLIDWORKS, igual que el 'script' del MCP de Fusion. En el scope del script: sw (la aplicacion), doc (ActiveDoc, puede ser None), c (el modulo solidworks_mcp.core, alias sw_core: extrude, bodies_info, overall_bbox, features_info, save_as...), fx (features: revolve, shell, hole_wizard, circular/linear_pattern, mirror_body, draft, rib, ref_plane_offset, loft, sweep, chapa, ecuaciones, configuraciones, mass_props), mz (mecanizado: dfm_3ejes, export_cam) y am (ensamblaje: add_mate, interferences). Escribe en la variable 'result' para devolver datos estructurados; lo impreso por print() se devuelve en 'stdout'.

ANTES de escribir una llamada COM que no conozcas de memoria, consulta sw_api_doc(iface, member): devuelve el orden y tipo real de los parametros en esta instalacion mas su significado, el enum que los gobierna y las unidades (la API trabaja en METROS y radianes). Los metodos de features tienen 20+ parametros posicionales; adivinarlos falla en silencio.

readOnly=true declara que el script no modifica el documento. Se comprueba en dos pasos: antes de ejecutar se bloquea si el texto contiene una llamada con pinta de mutar (Feature*, Insert*, Set*, Save*...) o una asignacion a propiedad; despues de ejecutar se compara el numero de cuerpos, de caras y el flag de modificado del documento, y si algo cambio pese a todo se devuelve en 'readOnlyViolation' en vez de ocultarlo. ESTO NO ES UNA CAJA DE ARENA: es una red contra el despiste, no una barrera de seguridad; con COM cualquier script con acceso a doc puede llamar a lo que quiera. No hay limite de tiempo: un script que cuelga bloquea el servidor hasta que termine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scriptYesCodigo Python a ejecutar.
readOnlyNoDeclara que el script no debe modificar el documento (ver arriba).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so richly: the two-step readOnly enforcement (pre-execution textual block on Feature*/Insert*/Set*/Save* patterns, post-execution body/face/modified-flag comparison), the readOnlyViolation return on failure, the explicit 'this is not a sandbox' warning, and the no-timeout/hang-blocks-server caveat.

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 with purpose, then scope, then prerequisites, then safety caveats — a logical order with every sentence carrying weight. It is dense and long, but for an arbitrary-code-execution tool the density is justified rather than filler.

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 tool with no output schema and full arbitrary-code power, the description covers return channels (result, stdout, readOnlyViolation), execution constraints (no timeout), safety limits, and prerequisite tooling. Nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it documents the injected scope names, the 'result' variable for structured output, and print() mapping to stdout. The readOnly parameter's semantics are also elaborated far beyond the schema's one-line note.

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?

States a specific verb and resource: it runs arbitrary Python against the SOLIDWORKS session, explicitly analogous to Fusion's 'script' tool. The enumerated scopes (sw, doc, c, fx, mz, am) make it unmistakable against siblings like sw_extrude or sw_bbox, which are narrow single-operation tools.

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 clear conditional guidance, notably 'ANTES de escribir una llamada COM que no conozcas de memoria, consulta sw_api_doc(iface, member)', routing the agent to the right sibling for API signatures. It also explains how and when readOnly triggers its two-step check. It stops short of explicitly saying when to prefer this escape hatch over the dedicated sw_* tools, so 4 rather than 5.

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