tan000tan/dsh-solidworks

# dsh-solidworks

DeepSeek Harness plugin that puts a local SolidWorks desktop behind 66 CAD tools (parts, assemblies, drawings, DFM, FEA). Read-only by default; document edits need a higher policy tier and persistence needs a one-shot user confirmation.

• Plugin package: dsh-solidworks — AGPL-3.0-only
• Execution engine: the solidworks-automation-skill Python MCP server (MIT, vendored under vendor/, see NOTICE)
• Runtime shape: cordis plugin inside the DSH host → spawns the Python MCP server over stdio → COM → SolidWorks.exe

Chinese documentation, including the full config and troubleshooting tables, lives in README.zh.md.

Requirements

Windows 10/11 x64 · SolidWorks desktop 2023–2026, activated and started at least once · Python 3.10+ x64 with mcp>=1.27,<2, pydantic>=2, jsonschema>=4.20,<5, plus pywin32>=305 and comtypes>=1.2 on Windows (ezdxf, numpy, Pillow, lxml, openpyxl, python-docx, python-pptx, XlsxWriter for the DFM/DXF/FEA families) · Node 22.12+.

The Microsoft Store python.exe alias cannot import mcp; discovery treats it as a failure and names every candidate it tried. Setting pythonPath to a real interpreter is the most reliable configuration.

Install

• Market: install dsh-solidworks from the DSH market, then restart. No install script is needed; all probing happens on first load (market installs block postinstall anyway).
• Local tarball: dsh plugin --profile web add .\dsh-solidworks-0.1.0.tgz. The desktop profile is owned by the desktop app — use the GUI there. Keep the tarball on an ASCII-only path: a non-ASCII directory makes DSH record a garbled file: specifier.
• Development: add this directory to a profile's cordis.patch.yml insert list (this repo ships a ready cordis.patch.yml).

First run (touches no CAD file)

node bin\dsh-solidworks.js doctor --json --python "C:\Python313\python.exe"
node bin\dsh-solidworks.js list-tools --mode read-only
node bin\dsh-solidworks.js selftest

In a session, ask for solidworks_status first (it explains a broken environment), then solidworks_connect, then read-only calls such as solidworks_mass_properties. High-risk calls require solidworks_confirm with byte-identical arguments, then the call itself.

The same policy is reachable from a terminal, which is the fastest way to tell "the plugin is misconfigured" apart from "the model asked for something silly":

# arguments go in a file: PowerShell mangles inline JSON when it is passed to a native exe
node bin\dsh-solidworks.js call solidworks_health_check --arg-file .\args.json --mode read-only
node bin\dsh-solidworks.js call solidworks_save_document --arg-file .\save.json --mode read-only
# -> {"status":"refused","code":"POLICY_MODE","risk":"high",...}

Policy

mode	publishes	write calls	persistence calls
read-only (default)	16 tools (health check, mass props, features, inspect sketch, mates, bounding box...)	refused	refused
standard	42 tools (adds sketches, extrusions, cuts, revolves, fillets, mates...)	allowed inside allowedRoots	refused
full	all 66 tools (adds save, export STEP/STL/DXF/PDF, close, delete, Pack&Go)	allowed inside allowedRoots	needs one-shot grant

A high-risk call without a matching grant returns:

{"status":"refused","code":"CONFIRMATION_REQUIRED","tool":"solidworks_save_document","grantRequired":true}

The user (or an automation flow) approves it through the companion tool:

{"name":"solidworks_confirm","arguments":{"tool":"solidworks_save_document","arguments":{"file_path":"D:\\parts\\bracket.sldprt"}}}

The grant binds to the SHA-256 of the canonical arguments, is single-use, and expires after five minutes (grantTtlMs). The session's current directory is the default write root when allowedRoots is not set; any path outside those roots is refused even if the user confirmed it.

The list of shipped tools and their assigned tiers is in lib/policy.js; it was verified against the real Python MCP server at tools/list time (66 tools, zero drift).

What happens when SolidWorks is missing or fails to launch

The host never crashes on startup:

• If Python is missing, or server.py cannot import mcp, or SolidWorks COM fails to register, apply() logs the diagnostic and publishes only two meta tools: solidworks_status and solidworks_confirm.
• Calling solidworks_status returns structured JSON explaining what is missing (the candidate interpreters tried, the missing COM classes, or the exit code) and the recommended next step.
• The standard server tools stay unpublished until the environment is healthy — the model cannot call tools that cannot run. Deployments that prefer the plugin registration to throw when CAD is expected to be present (e.g. a managed deployment) can opt in to failOnStartupError: true themselves.

Verification status

docs/verification.md is the authoritative record; the short version:

• 110 assertions across seven suites pass: policy 11, MCP client 8, argument-shape 16, packaging 12, audit trail 27, host-shaped end-to-end 27, crash isolation 9. Reproduce everything with $env:DSH_SOLIDWORKS_PYTHON = "<python.exe>"; npm run test:all (exit 0 = all green); npm test runs the four suites that need no Python (47 assertions).
• tools/list against the real Python server returns all 66 tools (protocol 2025-06-18); the read-only tier publishes 16 + 2 meta tools and withholds the other 50. The three modes were measured against the live server: read-only 16, standard 42, full 66 published.
• The plugin loads in a real DSH host from an installed copy, spawns the vendored server, serves a real solidworks_health_check, survives dsh plugin remove, and leaves no orphan Python.
• No modelling, assembly, drawing, save, or export call has been executed against a live SolidWorks session yet. Write paths are gated and unit-tested, not proven. The minimal loop is ready to run the moment SolidWorks may be started: node tests/write-loop.mjs --python <python.exe> --authorised — new blank part → sketch + extrude → read the volume back → export one STEP file → close without saving. Without --authorised it refuses to run (exit 2).

One argument-shape detail is worth knowing if you extend the engine: FastMCP wraps every tool's arguments in {"params": {...}}. The plugin hoists that wrapper out of the schema the model sees and re-wraps on the way back (lib/schema.js); without it every parameterised tool returns an empty result while reporting success.

License and provenance

The plugin is AGPL-3.0-only (LICENSE). The vendored engine is MIT (vendor/solidworks-automation-skill/LICENSE); provenance and the exact upstream source are in PROVENANCE.md. NOTICE tracks third-party notices. docs/license-risk.md is an exhaustive list of runtime imports vs shipped files, the whole-tree SHA-256 comparison against that repository, the runtime dependency licence table, and the one item that still needs a human/legal call (whether the MIT engine could be a derivative of the AGPL upstream — evidence says no, but the upstream could not be fetched from this host).

Releasing and publishing

File	Purpose
docs/github-publish.md	exact commands for repo creation, push, tag v0.1.0, Release, topics, submission PR
docs/release-notes-v0.1.0.md	ready-made GitHub Release body (real numbers, "writes not verified" statement)
docs/market-submission.md	submission checklist plus the three open questions (name semantics, category vocabulary, whether capabilities is required)
docs/submission/tan000tan__dsh-solidworks.yml	the file to add as data/plugins/tan000tan__dsh-solidworks.yml

---

📜 Historical Architecture Note (Pre-0.1.0 Prototype)

The repository's earlier commit history (8af9bef to d4c7fde) includes an initial exploratory prototype exploring a C#-based SolidPilot execution service and custom DSH integration profiles.

In v0.1.0, the project transitioned to a standard npm-distributable DSH plugin architecture (dsh-solidworks), bundling the policy gate, FastMCP schema bridge, and audit logging into a single cohesive package while keeping the full commit history preserved.