DCIR-MCP

A Model Context Protocol server that lets an AI assistant drive DC IR drop analysis on Ansys HFSS 3D Layout through natural language — describe a board's power source and current loads, and the assistant configures, solves, and reports back, without opening the GUI.

Status: early / actively developed. Configuration and solving work end to end and are validated against Ansys's own official example. Post-processing (loop resistance, via-current hotspots, voltage/current plots) is currently done ad hoc through the script escape hatch rather than as typed tools — see Roadmap.

Why gRPC, not COM

Ansys automation is commonly done through SIwave's standalone COM interface. This project deliberately avoids that path after hitting real reliability problems with it in practice: intermittent apartment-threading failures, and a hard AEDT crash traced to an EDB version mismatch (a board that opened fine on AEDT 2025 R2 crashed AEDT outright on 2026 R1).

Instead, everything here runs through:

• Hfss3dLayout (from ansys.aedt.core) — gRPC-based, same reliable family as PyAEDT's Hfss/Icepak classes.

• pyedb.Edb — also gRPC-backed on AEDT 2025 R2+, used standalone (no live AEDT desktop) to configure sources and pin groups directly on the .aedb.

No COM, no pythonnet automation of a live SIwave session.

Known-good version: AEDT 2025 R2. AEDT 2026 R1 has shown real bugs in this workflow (an EDB-backend crash on one board, a KeyError in pyedb's configuration loader on another) — stick to 2025.2 until that's resolved upstream.

Related MCP server: hfss-agent-native

How it works

1. configure_dcir — applies current/voltage sources, auto-generated pin groups, and a siwave_dc setup to an .aedb, standalone. AEDT must be closed for this step (a live desktop and a standalone Edb() session can't hold the same board open — hits "Can't acquire license"). Idempotent: every call fully redefines the DC IR configuration rather than merging with a previous one.

2. open_edb — launches AEDT fresh with the now-configured board loaded.

3. run_dcir_script — the escape hatch: runs arbitrary PyAEDT/PyEDB code against the live session. Solving (h3d.analyze(setup=...)) and result extraction currently go through here.

Setup

cd dcir-mcp
python -m venv venv
venv\Scripts\python.exe -m pip install -e .

Add to your MCP client config:

{
  "mcpServers": {
    "dcir-mcp": {
      "command": "C:/path/to/dcir-mcp/venv/Scripts/python.exe",
      "args": ["C:/path/to/dcir-mcp/dcir_mcp_server.py"],
      "env": {
        "ANSYSEM_ROOT252": "C:/Program Files/ANSYS Inc/v252/AnsysEM"
      }
    }
  }
}

Set the ANSYSEM_ROOTxxx env var(s) to match your installed AEDT version(s) — the number encodes the version (ROOT252 = 2025 R2, ROOT261 = 2026 R1).

Tools

Usage

"Here's my board: C:/boards/my_design.aedb. U1 draws 5A on net VCORE — that's the load. U2 supplies 1.2V on the same net — that's the regulator. Set up and solve a DC IR drop analysis."

The assistant will typically:

1. configure_dcir with the sources you described (AEDT must be closed at this point)

2. open_edb to load the configured board

3. run_dcir_script to solve and pull back results

A real gotcha worth knowing

A component you'd call "the voltage source" on a schematic doesn't always share a physical net with the loads you'd expect — power-sequenced designs (rails split by state, e.g. S0/S3/S5 domains) can look disconnected until you check what the solver actually reports as included in the simulation. Always verify the source and sink nets genuinely connect (or are bridged by a low-impedance component like a ferrite bead) before trusting a result — this project's configure_dcir won't catch that mismatch for you.

Roadmap

• Typed solve_dcir tool (currently done via run_dcir_script)

• Typed result-retrieval tools: loop resistance, via currents, voltage/current field plots

• Board-import tooling (bringing in a raw layout from a non-EDB format)

• Thermal handoff to Icepak

License

MIT — see LICENSE