dsh-weknora
Tencent/WeKnora把 WeKnora 知识库接入 dsh 的四个只读工具:列出知识库、混合检索原文片段、按顺序还原单篇文档,以及直接取用 WeKnora 自己带引用的 RAG 或 ReAct agent 回答(含可续聊的 session id)。
注册两个 MCP 服务器,在 Windows 上通过 COM 驱动本机安装的 AutoCAD 与 SolidWorks,另附两个按需技能。仅 Windows,需要 Python 3.11+;首次加载时自动安装钉死版本的上游服务器,并且只给真正装了的 CAD 应用注册对应的那一行。两者都只广告两个元工具而非完整工具表(SolidWorks 用本仓库的 discovery 垫片,AutoCAD 用上游 DISCOVERY_MODE=search),首次请求前加载的工具定义分别从 23,404 降到 256 token、从 83,732 降到 365 token。
Two MCP servers and two skills that let a DeepSeek Harness or Codex agent drive real CAD software. They wire up two existing open-source projects — U-C4N/Autocad-MCP and wzyn20051216/solidworks-automation-skill — so an agent can draw in AutoCAD, model in SolidWorks, and export the results. This repository is the configuration layer: isolated environments, launch parameters, on-demand loading and client registration. It does not fork, patch or repackage either server. Where upstream lacks a capability — SolidWorks has no way to hide its 66-tool catalog — this repository adds a small shim in front of it instead of touching it.
English | 中文
A CLI agent that can read a drawing is useful. One that can *produce* one is a different tool. With this kit installed, dsh or Codex can take a sentence like "draw an M6 threaded-hole bracket on an ISO A3 sheet and export PDF" and actually do it — create layers, draw geometry, dimension it, stamp a title block, run a validator, and hand back a file.
The catch is the same as every COM automation: the CAD application must be running, and the agent must run as the same Windows user and integrity level as the CAD app. This is not a cloud service and there is no headless substitute for native .dwg / .sldprt output.
Two skills are the entry points. They load lazily — the SKILL.md is read only when a request matches its description, so an idle session pays nothing for them:
Skill · How it works solidworks-automation · Script-driven: 66 Python modules (30 sw_*.py COM wrappers plus OCCT/FEA/DFM tooling), with preflight, capability gating and evidence chains autocad-mcp-pro · Authored here (upstream ships no AutoCAD skill). Drives the AutoCAD MCP through its two meta-tools
Two MCP servers are the muscle, registered in the client config:
Server · Tools advertised · Idle cost · Mode autocad · 2 · 365 tokens · Upstream DISCOVERY_MODE=search: only search_tools + call_tool; the 242-tool catalog is searched by keyword solidworks · 2 · 256 tokens · mcp-shim/ from this repository in front of upstream's 66-tool server (50 solidworks_* + 14 cadstudio_* + 2 design_*), which would otherwise cost 23,404
*Tool schemas are paid for before the first request. Connected directly the two servers cost 107,136 tokens; through this kit they cost 621, a 99.4% cut. Reproduce with mcp-shim/verify_shim.py.*
you speak natural language
│
├─ dsh / Codex lazily loads a skill by its SKILL.md description
│ ├─ solidworks-automation → sw_*.py scripts → COM → SolidWorks
│ └─ autocad-mcp-pro → search_tools / call_tool → MCP → AutoCAD
│
└─ MCP servers (cordis.patch.yml / codex config.toml)
├─ autocad upstream discovery mode, 242 tools on demand
└─ solidworks our shim, 2 meta-tools, 66 tools on demand
└─ spawns upstream server.py lazilyThis matters more than usual here, because the two servers are other people's work. The split is:
Part · Origin · License AutoCAD MCP server (autocad-mcp-pro) · U-C4N/Autocad-MCP, installed from PyPI · MIT SolidWorks skill + MCP server · wzyn20051216/solidworks-automation-skill, cloned at install time · MIT skills/autocad-mcp-pro/SKILL.md · Authored here — upstream has no AutoCAD skill · MIT mcp-shim/ (SolidWorks discovery shim + lexicon) · Authored here — upstream has no equivalent · MIT bin/, lib/ (including probe.py, which checks for the CAD COM servers), package.json, cordis.patch.yml, install.ps1, bootstrap.ps1, codex-config.snippet.toml, assets/, READMEs · Authored here · MIT
Nothing upstream is vendored. The installer fetches the PyPI package and clones (or zip-downloads) the SolidWorks repository at install time, so you always get upstream's current code and upstream keeps ownership of it. The value this repository adds is the part that was missing: verified launch parameters, the discovery-mode configuration, a discovery shim for the server that lacks one, the on-demand skill wiring, the junction trick that keeps gigabytes off C:, and an installer that survives a blocked git protocol.
Three ways in. Pick one, then check the prerequisites at the end of this section.
dsh plugin --profile web add dsh-sw-cadThat is the whole install. package.json declares dsh.bundle.patch, so dsh picks up this repository's cordis.patch.yml, which inserts one row: this package. The package is a real cordis plugin (lib/index.js), not a wrapper around a binary, so dsh imports it from the profile and nothing has to be on PATH.
On first load the plugin resolves its own paths, installs the pinned upstream servers if they are missing (a few minutes, once), and then registers the two MCP clients with absolute paths. If the install cannot succeed it throws with the failing path and the command to re-run, instead of registering rows that would fail silently. SW_CAD_NO_AUTO_INSTALL=1 turns the automatic install off and surfaces the missing pieces as an error instead.
npm install -g dsh-sw-cad
dsh-sw-cad installSame result, plus dsh-sw-cad on PATH for doctor, where and serve — useful when you want to check the install without booting dsh.
bootstrap.ps1git clone https://github.com/27painter/dsh-sw-cad.git
cd dsh-sw-cad
.\bootstrap.ps1 -Check # report only, changes nothing; exits 1 if something is missing
.\bootstrap.ps1 # install whatever is missingIt inspects ten things and repairs only what is absent or stale:
Check · Fixed by Python ≥ 3.11 · nothing — it reports the problem and stops venv-autocad + autocad-mcp-pro · install.ps1 venv-solidworks + mcp / pymupdf / ezdxf / pywin32 · install.ps1 SolidWorks skill clone · install.ps1 discovery shim · copied from this repository shim catalogue · rebuilt with --build-catalog, also when older than server.py ~/.dsh/skills junction · created ~/.dsh/cordis.patch.yml entries · install.ps1 (backs the file up first) ~/.codex/skills junctions · created ~/.codex/config.toml entries · appended, with a backup
Running it twice is a no-op. It exits 0 when everything is in place and 1 otherwise, so it is safe to wrap in a script or hand to an agent. Nothing is downloaded unless a core piece is actually missing.
[!WARNING]
Route 3 also writes ~/.dsh/cordis.patch.yml. If you installed the plugin as well, that is a secondregistration of the same two servers under the same serverName, and dsh refuses the duplicate — thesession fails to start. Use one route or the other, not both: with the plugin installed, keep
~/.dsh/cordis.patch.ymlat[].
Command · What it does dsh-sw-cad install · install the pinned upstream servers and write ~/.dsh/sw-cad.json dsh-sw-cad doctor · report present/missing pieces and the pinned versions, change nothing, exit 1 if something is missing dsh-sw-cad where · print every path the servers will use dsh-sw-cad serve autocad\ · solidworks · run one MCP server over stdio, for manual testing
install is idempotent, and the plugin runs it for you on first load. Versions are pinned in lib/upstream.json — autocad-mcp-pro 1.6.0 and one SolidWorks skill commit — so a machine that installs today and one that installs next month get the same servers.
[!TIP]
Rather not run any of this yourself? Paste the block below into dsh, Codex, or any agent that can
run commands on this machine. It carries everything the agent needs, so you can read the rest of this
section only if something goes wrong.
Install https://github.com/27painter/dsh-sw-cad on this Windows machine.
Run: npm install -g dsh-sw-cad && dsh-sw-cad install
That installs the package, then the two upstream servers (AutoCAD MCP and the
SolidWorks skill) plus the client entries. dsh-sw-cad install is idempotent and
only touches what is missing.
Do not run it elevated: it must run as the same Windows user as AutoCAD and
SolidWorks. It writes nothing on C: except ~/.dsh and ~/.codex, and never touches
the CAD installations or the registry.
Then verify with: dsh-sw-cad doctor, dsh --profile headless --dump-config, codex mcp list.
Report any step that fails instead of silently working around it.python --version)The plugin checks for both COM servers before registering anything (lib/probe.py, a registry ProgID lookup — it does not launch either application). A machine with only AutoCAD registers only the AutoCAD server, and vice versa; a machine with neither registers nothing and says so in the log instead of offering tools that could only fail.
[dsh-sw-cad] solidworks: no COM server registered on this machine, not registering it
[dsh-sw-cad] registered autocad (base D://cad-agents, upstream pinned in lib/upstream.json)SW_CAD_DISABLE=autocad,solidworks turns that decision into a setting, and dsh-sw-cad doctor prints what the probe found without starting dsh.
Note that *installed* is not the same as *running*. AutoCAD registered but closed means the AutoCAD tools wait for the application and then fail with a message about a modal dialog; SolidWorks' own health check reports the install, not the running instance. Starting the CAD application as the same Windows user as your agent is the last step of any install.
Upstream verifies against a single release but writes for a range. The honest picture:
CAD · Verified · Expected to work · Why AutoCAD · 2026 (every COM path, live run), 2027 (API compatible) · 2025 / 2024 / 2023 · COM goes through the long-stable ActiveX API. Run the upstream scripts\smoke_*_com.py against your build to confirm. And if COM cannot do something on your version, the ezdxf backend still can — it needs no AutoCAD at all. SolidWorks · 2026 SP4.1 (upstream's acceptance target) · 2025 / 2024 / 2023 · The code carries explicit SW2024 fixes (Chinese edition: selecting a sketch by name, AddComponent4 returning None), and upstream's contributor guide asks for 2020–2025 compatibility. 2023 has not been exercised.
Older versions are not refused — nothing checks a version number. They are simply outside what upstream verified, so start with one small job and look at the result before trusting a full drawing.
These are the upstream projects' own instructions. This is also what install.ps1 automates, so read it if you want to understand or debug the install.
AutoCAD MCP server — upstream install. Into a venv on the data drive (recommended here):
python -m venv D:\cad-agents\venv-autocad
D:\cad-agents\venv-autocad\Scripts\python.exe -m pip install "autocad-mcp-pro[full]"
D:\cad-agents\venv-autocad\Scripts\autocad-mcp.exe --help # stdio server entry pointUpstream's own one-liners, if you do not want a venv:
pip install autocad-mcp-pro # or: uvx autocad-mcp-pro
autocad-mcp # backend auto-selected
AUTOCAD_MCP_BACKEND=ezdxf autocad-mcp # headless DXF, no AutoCAD needed
AUTOCAD_MCP_BACKEND=com autocad-mcp # live AutoCAD (needs the [com] extra)Extras: [com] = live AutoCAD control (pywin32 + Pillow), [pdf] = matplotlib for PDF/PNG output, [office] = openpyxl for XLSX takeoffs, [full] = all of them. Upstream also documents an HTTP transport (autocad-mcp --transport http --port 8000) and a JSON config for Claude Desktop / Cursor.
SolidWorks skill + MCP — upstream quick start. Upstream offers three entry points; pick one:
# Option 1 — skill only (simplest)
npx github:wzyn20051216/solidworks-automation-skill
# Option 2 — MCP via Smithery
npm install -g @smithery/cli
smithery mcp add wzyn20051216/solidworks-automation-skill --client codex --config '{}'
# Option 3 — CAD Studio desktop app, from the upstream Releases pageManual clone (what this kit does, and what you need if you want the skill on the data drive):
git clone --depth 1 https://github.com/wzyn20051216/solidworks-automation-skill.git D:\cad-agents\dsh-skills\solidworks-automation
D:\cad-agents\venv-solidworks\Scripts\python.exe -m pip install -r D:\cad-agents\dsh-skills\solidworks-automation\requirements.txt
D:\cad-agents\venv-solidworks\Scripts\python.exe -m pip install -r D:\cad-agents\dsh-skills\solidworks-automation\mcp-server\requirements.txt
D:\cad-agents\venv-solidworks\Scripts\python.exe D:\cad-agents\dsh-skills\solidworks-automation\scripts\cad_doctor.pyOptionally put the discovery shim in front of SolidWorks (every route above does this for you; these are the manual steps). Without it the client carries all 66 tool schemas — 23,404 tokens — in every request:
New-Item -ItemType Directory -Force -Path D:\cad-agents\mcp-shim | Out-Null
Copy-Item .\mcp-shim\* D:\cad-agents\mcp-shim\ -Force
# build the search catalogue (once, and again after any upstream update)
D:\cad-agents\venv-solidworks\Scripts\python.exe D:\cad-agents\mcp-shim\sw_discovery_shim.py `
--python D:\cad-agents\venv-solidworks\Scripts\python.exe `
--server D:\cad-agents\dsh-skills\solidworks-automation\mcp-server\server.py --build-catalogRegister both servers with your client. dsh reads ~/.dsh/cordis.patch.yml — copy this repository's cordis.patch.yml there. It carries no absolute path: each row calls dsh-sw-cad serve , so the only requirement is that the binary is on PATH (npm install -g dsh-sw-cad). Codex reads ~/.codex/config.toml — append codex-config.snippet.toml, or use upstream's own registrar (mcp-server\register_codex_mcp.ps1 -Python -InstallDependencies). The Codex snippet does contain absolute paths, so adjust those to your -BaseDir.
Make the skills visible. Both clients only scan their own skills directory:
# dsh: one junction for the whole skills folder (matches what install.ps1 does)
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.dsh" | Out-Null
New-Item -ItemType Junction -Path "$env:USERPROFILE\.dsh\skills" -Target "D:\cad-agents\dsh-skills"
# Codex: one junction per skill (its skills folder may hold other skills)
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.codex\skills" | Out-Null
New-Item -ItemType Junction -Path "$env:USERPROFILE\.codex\skills\solidworks-automation" -Target "D:\cad-agents\dsh-skills\solidworks-automation"
New-Item -ItemType Junction -Path "$env:USERPROFILE\.codex\skills\autocad-mcp-pro" -Target "D:\cad-agents\dsh-skills\autocad-mcp-pro"install.ps1 doesinstall.ps1 runs everything in the appendix above, plus the parts that are easy to get wrong: both venvs on the data drive, the junctions, the discovery-mode parameters, and a timestamped backup of ~/.dsh/cordis.patch.yml.
powershell -ExecutionPolicy Bypass -File .\install.ps1
# custom locations / force rebuild
.\install.ps1 -BaseDir "E:\cad" -WorkDir "E:\AutoCad" -ForceIt checks Python, creates the directories, builds the venvs, installs autocad-mcp-pro[full] and the SolidWorks requirements, clones the skill (or zip-downloads it when git is blocked), installs the discovery shim and builds its catalogue, junctions the skills into ~/.dsh/skills, writes the dsh config, and drops the AutoCAD skill in place.
If you are not sure what is already on the machine, run bootstrap.ps1 instead: it decides whether install.ps1 is needed at all.
Codex users still need one step — append codex-config.snippet.toml to ~/.codex/config.toml and junction the two skills into ~/.codex/skills/ (last four commands of the appendix above).
[!IMPORTANT]
Start AutoCAD / SolidWorks first, as the same user. COM automation crosses a process boundary that
Windows guards by user and integrity level. An agent started elevated while the CAD app runs normally
(or vice versa) will connect to nothing, and the failure looks like "the tool did nothing".