# Bug Report: MCP `export_cadence_netlist` Tool Fails Due to MSYS-Style Path Translation

[ryanCity]

Bug Report: MCP export_cadence_netlist Tool Fails Due to MSYS-Style Path Translation

Date: 2026-03-03
System: Windows 10/11, x64
Cadence Version: SPB 23.1
Shell: PowerShell 7

---

Summary

The export_cadence_netlist MCP tool fails on every Cadence OrCAD design when run on a Windows system. The root cause is that the tool internally converts native Windows file paths to MSYS/Git Bash-style paths before invoking pstswp.exe. Since pstswp.exe is a native Windows executable, it cannot resolve these paths and fails silently.

Running the identical pstswp.exe command manually from PowerShell with native Windows paths succeeds.

---

Root Cause

The MCP tool constructs its shell command using MSYS path conventions:

cd "/c/Users/username/projects/my_design/..."
&& "/c/Cadence/SPB_23.1/tools/bin/pstswp.exe" -pst -d "DESIGN.DSN" -n "allegro"
   -c "/c/Cadence/SPB_23.1/tools/capture/allegro.cfg" ...

Problems with this approach:

Issue	MSYS Path (broken)	Windows Path (works)
Drive letter	/c/Users/...	c:\Users\...
Path separator	Forward slashes throughout	Backslashes (native)
Config file -c flag	/c/Cadence/SPB_23.1/tools/capture/allegro.cfg	c:\Cadence\SPB_23.1\tools\capture\allegro.cfg
Working directory	MSYS-style cd target	Native Windows cd target

The pstswp.exe binary is a native Win32 executable — it does not understand MSYS/Git Bash path conventions. It interprets /c/Users/... as a relative path, fails to find the file, and returns a generic "Command failed" error with no diagnostic output.

---

Reproduction

Failing (MCP tool)

> export_cadence_netlist(design="c:\projects\my_design\Schematic\my_board.DSN")

Error: "Cadence pstswp failed: Command failed: cd "/c/Users/username/projects/my_design/Schematic"
       && "/c/Cadence/SPB_23.1/tools/bin/pstswp.exe" ..."

This was reproduced on every DSN file tested — zero successes via the MCP tool.

Working (manual PowerShell)

cd "c:\projects\my_design\Schematic"

if (-not (Test-Path "allegro")) { New-Item -ItemType Directory -Name "allegro" | Out-Null }

& "c:\Cadence\SPB_23.1\tools\bin\pstswp.exe" `
    -pst -d "my_board.DSN" `
    -n "allegro" `
    -c "c:\Cadence\SPB_23.1\tools\capture\allegro.cfg" `
    -v 3 -l 255 -j "PCB Footprint" 2>&1

Output (success):

#1 WARNING(ORCAP-36050): No pins are present in PCB0100. Ignoring this component in netlist.
#2 WARNING(ORCAP-36050): No pins are present in DOC0100. Ignoring this component in netlist.
INFO(ORCAP-36080): Scanning netlist files ...
Loading... allegro\pstchip.dat
Loading... allegro\pstxprt.dat
Loading... allegro\pstxnet.dat
packaging the design view...

---

Test Results

Tested on 19 Cadence OrCAD designs of varying complexity (passive flex circuits, system-on-modules with FPGAs/MCUs, sensor boards, baseboards):

Metric	MCP Tool	Manual PowerShell
Designs attempted	19	19
Successes	0	14
Failures (tool bug)	19	0
Failures (design issues)	—	5

The 5 manual failures were caused by design-level issues unrelated to the tool:

• 4 designs had hardcoded absolute paths from a different developer's workspace baked into the DSN file (exit code 1, silent failure)
• 1 design had duplicate reference designators in the schematic (ORCAP-36032 errors; pstswp refuses to netlist)

---

Impact

• The export_cadence_netlist MCP tool is completely non-functional on Windows systems where the default shell is PowerShell.
• Engineers must fall back to manual CLI commands every time a fresh netlist export is needed.
• The MCP tool's query functions (list_components, query_xnet_by_net_name, etc.) are unaffected — they work correctly because they read pre-existing .dat files and do not invoke pstswp.exe.

---

Suggested Fix

The MCP tool should detect the host OS and shell environment, then construct the pstswp.exe command using native Windows paths when running on Windows. Specifically:

1. Do not translate c:\... paths to /c/... MSYS format.
2. Use backslashes as path separators in the cd, -d, and -c arguments.
3. Ensure the allegro/ output directory exists before invoking pstswp (create it if needed).
4. Run the command via the system's default shell (PowerShell on modern Windows), not through a MSYS/bash compatibility layer.

Minimal fix pseudocode:

// Before (broken — MSYS-style paths):
const cmd = `cd "${toMsysPath(designDir)}" && "${toMsysPath(pstswpPath)}" -pst -d "${dsnFile}" ...`;

// After (working — native Windows paths):
const cmd = `cd "${designDir}" ; & "${pstswpPath}" -pst -d "${dsnFile}" ...`;
//           ^^ native paths     ^^ PowerShell call operator

---

Workaround

Until the MCP tool is fixed, use this PowerShell command template to export netlists manually:

cd "c:\path\to\design\Schematic"
if (-not (Test-Path "allegro")) { New-Item -ItemType Directory -Name "allegro" | Out-Null }
& "c:\Cadence\SPB_23.1\tools\bin\pstswp.exe" `
    -pst -d "DESIGN_FILE.DSN" `
    -n "allegro" `
    -c "c:\Cadence\SPB_23.1\tools\capture\allegro.cfg" `
    -v 3 -l 255 -j "PCB Footprint" 2>&1

Key requirements:

• Must cd into the directory containing the .DSN file before running pstswp
• The allegro/ output directory must exist (create it if needed)
• Warnings about No_connect pins (ORCAP-36038) and title block components (ORCAP-36050) are normal and non-blocking
• Part name truncation warnings (ORCAP-36006) are cosmetic

---

Common pstswp Warning Reference

Warning Code	Meaning	Action
ORCAP-36050	Title block / documentation component has no pins	Normal — ignore
ORCAP-36038	No-connect pin connected to a net	Normal — schematic intent override
ORCAP-36006	Part name truncated (exceeds max length)	Cosmetic — ignore
ORCAP-36042	Duplicate power pin renamed	Normal — package-level pin aliasing
ORCAP-36032	Duplicate reference designator	Error — must fix in schematic
ORCAP-36035	Conflicting nets on duplicate refdes pins	Error — must fix in schematic
ORCAP-36018	Netlisting aborted due to errors	Fatal — resolve errors above first

[valentinozegna]

Thanks for the detailed report @ryanCity! This is fixed in v0.1.3 — we now use cmd.exe with native Windows paths instead of requiring bash. This should work on all Windows systems regardless of shell configuration.

Fix: #56