eda-agent

MCP server that lets an AI (or any MCP-compatible client) interact with a live Altium Designer session, with KiCad available as an additional backend. It exposes 300+ tools covering schematic, PCB, library, project, and design-agent operations, over a persistent DelphiScript bridge for Altium (or KiCad's own IPC API). The AI reads the design you currently have open, asks questions about it, and can modify it in place while you watch. The backend is selected at startup, so an Altium user and a KiCad user each see only their tool set.

⚠️ Experimental. Not all tools are extensively tested. Some can crash the Altium DelphiScript engine. See Known limitations before using on any design you haven't backed up.

Demo

Claude Code reviewing a buck converter through eda-agent. The feedback resistor divider on this schematic is intentionally wrong; Claude catches it among other recommendations.

Dashboard

Two dashboards ship with eda-agent:

• In-Altium status window - a floating Altium-side window showing live status, request count, cumulative Altium-side time, auto-shutdown countdown, and a per-command log with durations. Hide pings filters the 30 s keep-alive traffic; Only >100ms isolates slow calls. The Detach button saves all dirty docs and exits the polling loop cleanly.
• Web dashboard - a local browser dashboard at http://127.0.0.1:8766, focused on design review. A Review tab surfaces datasheet / MPN / manufacturer / footprint coverage gauges and an actionable issue queue (missing datasheet, missing MPN, orphan nets, ...); Project, Components, Nets, Libraries and Plan tabs give live structured views. Click any component or net to drill into a detail drawer; one click cross-probes it into Altium. Light / dark theme, server-sent-events live feed. It is auto-started by the MCP server - the Open Dashboard button on the in-Altium status window launches the browser.

How it works

• Altium Designer stays open and in full control of your design
• A DelphiScript polling loop runs inside Altium's scripting engine
• eda-agent (Python, launched by your MCP client) sends commands via file-based IPC
• Altium executes, writes a response, and returns to polling
• You see the changes happen live in Altium

This is not a batch tool that opens a project, runs a script, and exits. It's a live connection for as long as you want it (conversational design review, guided refactoring, ad-hoc BOM queries, "what nets does this resistor connect to?"), all on the project you currently have open.

Features

• 300+ tools across application, project, library, schematic/general, PCB, and design-agent categories
• Generic primitives (obj_query, obj_modify, obj_create, obj_delete, run_process) that work on almost any schematic or PCB object type via late-binding, avoiding per-type handler proliferation
• Bulk batch primitives: obj_batch_modify, obj_batch_create, obj_batch_delete, pcb_place_tracks, pcb_move_components, sch_place_wires, place_net_labels, place_power_ports, sch_place_components, sch_set_components_parameters, get_sch_doc_pins, lib_add_pins, proj_get_connectivity_many, sim_attach_primitives. Collapse N LLM turns + N IPC round-trips into one. Typical wall-time savings: 10 to 100x on multi-item edits
• Design review snapshot: design_review_snapshot bundles 8 to 12 review reads (project info, components, nets, rules, diff, messages, stats, unrouted, BOM) into a single call. One LLM turn instead of a dozen
• Design-lint sweep: design_lint_report runs 31 audit checks in one IPC pass and returns a structured violation list - schematic-side (component-parameter visibility per class, power-port orientation, floating ports, multi-output / no-driver nets, duplicate designators, off-grid components) and PCB-side (DNP variant components, tented-via ratio, near-miss track endpoints, signal vias without nearby return via, via antennas, removed pad shapes, components outside outline, pads too close to board edge, invalid polygon regions, optional DRC). Each check is also exposed as a standalone audit_* MCP tool; the dashboard's Status → Health subtab has a one-click Lint panel that calls /api/lint and groups results by Schematic / PCB
• Datasheet-first discipline: every component-surfacing response (pcb_get_components, proj_get_bom, proj_get_component_info, proj_find_component, lib_search, design_review_snapshot, sim_get_readiness) carries a _datasheet_guidance block with per-part vendor search queries. app_attach / app_ping carry a _system_reminder so every MCP client that connects sees the rule at session start. LLM-fabricated datasheet values are forbidden; WebFetch/WebSearch are called out by name
• Sch <-> PCB netlist crossref: crossref_net(net_name) compares the schematic pin list against the PCB pad list for the same net. Catches ECO drift, stale post-fabrication routing, phantom nets from port/sheet-entry rename conflicts. in_sync flag + sch_only / pcb_only diff
• SPICE simulation workflow: sim_get_readiness audits every component and partitions into ready / needs-primitive / needs-file. sim_attach_primitives sets SpicePrefix + Value on passives. sim_attach_model links a vendor .mdl / .ckt. sim_run dispatches the simulator. Built-in guardrail: never fabricate a SPICE model file, fetch the vendor one
• Focus-independent PCB access: every PCB handler falls back to GetPCBBoardByPath when GetCurrentPCBBoard returns nil (user has a sch tab focused). No more misleading "No PCB document is active" when the PCB is right there
• Fast and compile-cached: persistent polling loop; ~10 ms per call in active mode. SmartCompile caches DM_Compile with a 2 s TTL so a multi-read review pays for one compile instead of a dozen. Explicit proj_force_recompile + proj_get_compile_freshness probes for cases that need a guaranteed-fresh netlist (e.g. after user edits)
• Persistent polling loop: one script start, then ~10 ms per tool call in active mode
• Annotation runs silently: proj_annotate designates components without popping the annotate dialog
• Deferred save for speed: mutations mark documents as modified in memory; disk writes happen on explicit app_save_all (or automatically on app_detach). Before this, every edit triggered a full project save, which dominated latency
• Two dashboards: an in-Altium floating status window (status, request count, per-command performance, command log, Detach button) and a browser-based web dashboard (127.0.0.1:8766) for design review - datasheet / MPN / footprint coverage gauges, an actionable issue queue, component / net drill-in, one-click cross-probe into Altium, light / dark theme. The whole project view loads in one bundled IPC round-trip (project.dashboard_snapshot); the web dashboard auto-starts with the MCP server
• DelphiScript trap linter: scripts/altium/lint.py (wired into build.py) scans the Pascal sources for known parser hazards - Cardinal() casts, malformed hex literals, empty .Add('') arguments, braces inside comments, fixed-size arrays as function locals, reserved-word identifiers - and fails the build before a bad deploy
• Activity logs: every command is appended to workspace/activity.log (CSV with timestamps, durations, command name, response size). The bridge also writes bridge_trace.log for IPC-level diagnostics
• Bulk-tool nudge: when a singular tool is hit 2 to 3 times in 10 s, the response carries a _hint_bulk field pointing at the batch variant. Clients that missed the bulk tool in the docstring learn about it at runtime
• Design agent surface: six MCP tools (design_get_discipline, design_snapshot_inventory, design_validate_plan, design_execute_plan, design_audit_schematic, design_validate) that let an MCP-client LLM produce a structured DesignPlan JSON, instantiate it on a fresh sheet (parts + wires + labels + rail glyphs), audit the result for layout problems, and validate ERC + connectivity. Datasheet-first, NDA-isolated by construction
• Motif composer + canonical priors + Sugiyama placement: three-layer placement strategy. (1) Sugiyama / force-directed gives every part a baseline position. (2) The motif composer detects canonical sub-circuits in the netlist (bypass cap, voltage divider, fb_divider, lc_output, ...) via VF2 subgraph isomorphism and splats each match into its frozen canonical layout - same data shape, IC-anchored or self-contained. (3) Canonical priors apply per-role-pair nudges (e.g. vcc_decoup sits 400 mils from its IC). A final overlap-shove pass repairs any collisions; sheet-edge clamping keeps every glyph and port within the page boundary. Role-compatibility filter drops false-positive motif matches (a structural rc-lowpass that's actually a decoupling cap stays out of the filter motif). Topology-agnostic - works for a buck, an LDO, an MCU, an audio amp, anything with a clean net graph
• Within-block schematic wiring: stub wires from each pin endpoint outward to the label / port (no more "floating net labels" ERC warnings), Manhattan routing between same-net pins for signal nets, rail consolidation clusters power / ground pins so one VCC bar or GND triangle serves many pins instead of stacking N glyphs. Obstacle-aware: every L-path picks the orientation that crosses fewest component bodies, using real BoundingRectangle data queried from Altium
• Atomic-parts contract: every existing-status Part must carry mpn, footprint, datasheet_url; the inventory snapshot exposes those fields per component; design_validate emits atomic_parts warnings when the contract is missed. Aligns with the KiCad Atomic / Digi-Key Library / atopile / JITX convention
• Schematic audit: design_audit_schematic returns structured {overlaps, wire_crossings, stacked_ports} for the active schematic - pairs of components whose bboxes intersect, wire segments crossing a non-endpoint component body (real Pascal-side Vertex.* + BoundingRectangle.* accessors), and clusters of 3+ rail glyphs of the same net. Each violation carries enough geometry for the planner to compute a corrective move. Programmatic feedback loop without needing a visual snapshot
• Health and doctor preflight: eda-agent health (offline checks: workspace dir, pointer file, bundled scripts) and eda-agent doctor (full preflight talking to Altium: process running, script polling responsive, version match, save_all canary, optional --library lib-path checks). --json for machine-readable output
• pip-installable: no admin, no installer, no touching Altium's config

Requirements

• Python 3.11+
• An EDA tool, one of:
  • Altium Designer (recent versions, AD20+ preferred) - Windows only
  • KiCad 9+ with the IPC API server enabled (Preferences → Plugins → KiCad API server), plus pip install -e .[kicad]

The server picks a backend at startup (EDA_AGENT_BACKEND, default altium), so one install drives either tool. See EDA backends.

Installation

git clone https://github.com/salitronic/eda-agent
cd eda-agent
pip install -e .

Register the server with your MCP client. The binary is eda-agent and runs on stdio; consult your client's docs for how to add a local stdio-based server.

Claude Code

claude mcp add altium eda-agent

Adds eda-agent as an MCP server named altium to your Claude Code project config. Use -s user to register it at the user level (available across every project):

claude mcp add -s user altium eda-agent

If eda-agent isn't on your PATH, give the full path instead (pip reports it after install, typically %USERPROFILE%\AppData\Roaming\Python\Python312\Scripts\eda-agent.exe on Windows). To verify the connection: /mcp in a Claude Code session should list altium as connected.

Other MCP clients

The server speaks standard MCP over stdio; any client that accepts a local stdio command will work. Invoke eda-agent (or eda-agent serve) as the subprocess.

Altium-side scripts

Drop the Altium script project somewhere you can find it:

eda-agent install-scripts

Default destination: %USERPROFILE%\EDA Agent\scripts\. Use --dest PATH to put it elsewhere.

Register the script as a Global Project in Altium (once):

1. DXP → Preferences → Scripting System → Global Projects → Install from file
2. Select the Altium_API.PrjScr you just installed

From then on, every Altium startup compiles the script project and the polling loop is one click away:

1. File → Run Script...
2. Expand Altium_API → Dispatcher.pas, select StartMCPServer, click Run

The polling loop starts and your MCP client can drive Altium.

EDA backends (Altium / KiCad)

The server exposes one of two tool surfaces, chosen at startup by the EDA_AGENT_BACKEND environment variable (or the --backend flag):

• altium (default) - the full Altium suite. Existing installs are unaffected.
• kicad - the KiCad-native tools.
• both - the union, for one server driving either tool.

Selection happens before any tool registers, so an altium user never sees KiCad tools and vice versa. Because MCP clients set environment per server, a user of both tools registers two servers pointing at the same binary:

claude mcp add -s user altium eda-agent
claude mcp add -s user kicad -e EDA_AGENT_BACKEND=kicad eda-agent

KiCad

KiCad support talks to a running KiCad over its own supported IPC API (kicad-python), so - unlike the Altium side - there are no scripts to install. Requirements: KiCad 9+, the API server enabled (Preferences → Plugins → KiCad API server), a board open in the PCB editor, and pip install -e .[kicad].

The KiCad backend covers, at parity with what KiCad's API and CLI expose:

• Review - an EDA-agnostic design review (annotation, connectivity, shorts, decoupling, net classes) that runs the same engine on the PCB and, via the netlist, on the schematic; plus a one-call kicad_full_review that adds DRC, ERC, and schematic↔PCB comparison.
• Checks - geometric DRC and schematic ERC via KiCad's own kicad-cli.
• Reads - footprints, pads, tracks, vias, zones, shapes, text, stackup, layers, net classes, board outline, project info, netlist, and a consolidated BOM.
• Exports - every kicad-cli format: Gerbers, drill, STEP/GLB/VRML/STL/3D-PDF, PDF/SVG/DXF, position files, IPC-2581, ODB++, IPC-D-356, plus schematic BOM/netlist/PDF/SVG.
• Authoring - place/move/rotate/lock components, edit values, and create tracks, vias, zones, text, and graphics.
• Calculators - the same trace-width, impedance, termination, length-match, and thermal-via sizing tools as the Altium backend (pure physics, EDA-independent).

The neutral tools (review_design, run_drc, run_erc, get_board_info, list_components, list_nets) work on whichever backend is active.

If you'd rather not register the script globally, you can also open Altium_API.PrjScr via File > Open... and launch StartMCPServer from the Run Script... dialog the same way; the dialog picks up any loaded script project.

Example use cases

Full-project design review

"Do a design review of the PoE front-end. Pull the snapshot, fetch the TPS2372 and TL072 datasheets, and flag anything that doesn't match."

One design_review_snapshot call gives the AI project info, design stats, components, nets, rules, diff, messages, board stats, and BOM, plus a datasheet-fetch checklist. The AI then grounds every recommendation in the vendor datasheets it actually pulled. 8 to 12 separate queries collapse into one tool call.

Schematic review

The AI reads your schematic live. Ask it anything a reviewer would:

"List every component connected to the 3V3 rail and flag anything whose datasheet limit is below that."

"Find all net labels that appear only once across the whole project. Those are probably typos."

"What's driving the /RESET net? Walk the connectivity and tell me where it resets and how."

"Do any two components share a designator prefix with gaps in numbering (e.g. R1, R2, R4)? Re-annotate or tell me what's missing."

"Compare the focused schematic to the version from 3 weeks ago. What parameter values changed?"

Under the hood, the AI calls tools like query_objects(object_type="eSchComponent", scope="project"), get_connectivity_many(designators=[...]), get_nets(...), modify_objects(...), and so on. You watch Altium repaint as it works.

Sch ↔ PCB drift detection

"Run obj_crossref_net on POE_PG. The PCB seems to have R7 on this net but I'm not sure the schematic still does."

The response shows sch pins, PCB pads, matched count, and the diff in each direction. A non-empty pcb_only list means the board was fabricated from an earlier schematic revision and a later edit broke the post-ECO merge; catch this before the next ECO push rips routed connections. in_sync: false plus the exact diff tells you which port or sheet-entry rename to undo.

SPICE simulation setup

"Set this schematic up for an AC sweep. Attach SPICE primitives to every passive, fetch vendor SPICE models for the op-amps, and tell me if any part can't be simulated."

sim_get_readiness partitions the design into ready / needs_primitive / needs_file. The AI batches primitives onto every passive in one sim_attach_primitives call, searches vendor sites for the IC models, attaches them with sim_attach_model, and reports any holdouts. It will not fabricate a SPICE model file; the rule is baked into the tool response.

Library hygiene

"Open Resistors.SchLib and report every component missing a Value, ManufacturerPart1, or Description parameter. Fill in the missing Description from the datasheet URL if present."

"Diff our Caps.SchLib against Caps_vendor.SchLib and tell me what's new or changed."

"Create a new 48-pin symbol for STM32F411 with this pinout table."

The last one uses lib_add_pins: one call places the whole pinout in a single transaction instead of 48 LLM turns.

PCB spot-checks

"Any unrouted nets on the board?"

"What's the total trace length for the USB differential pair, split by layer?"

"Show me all vias on the 12V net and their drill sizes."

"Run DRC and summarize the violations by severity."

"What does the Clearance_HV rule actually enforce: clearance value, scope expressions, priority?"

That last one uses pcb_get_rule_properties, which returns the actual numeric gap / widths / impedance targets, not just rule metadata.

Bulk changes

"Every 0402 resistor with value 10k, set its Tolerance parameter to 1% and Voltage to 50V."

"Rename the net OLD_CS to SPI_CS across every sheet in the project."

"Move C1-C20 into this 200-mil grid layout pattern."

Bulk tools like obj_batch_modify, pcb_move_components, and sch_place_components finish the whole operation in one IPC round-trip.

Known limitations

This tool is experimental. Please read this section before using on a design you haven't backed up.

Altium DelphiScript engine can crash

Some tool paths trigger DelphiScript compile or runtime errors ("Undeclared identifier…", "Could not convert variant of type (Dispatch) into type (OleStr)", etc.). When that happens, the script project halts mid-execution and the polling loop stops responding. You will see one of:

• An Altium error dialog stating the problem
• Your MCP client timing out waiting for a response

Recovery: in Altium Designer, open the script project tab and press the red Stop button in the Script IDE toolbar (equivalently Run > Stop from the menu, or Ctrl+F3; use Ctrl+Pause/Break if the script is stuck in an infinite loop). This stops the halted debugger. Then re-launch the polling loop via File > Run Script... > StartMCPServer > Run.

This is an ongoing reliability effort. Every identified crash is either fixed or guarded. If you hit a new one, the Altium error dialog tells you the exact identifier or line. Opening an issue with that text helps us harden the relevant path.

Altium tool buttons relying on internal scripting pause while the server is running

Altium itself uses DelphiScript internally for many built-in commands (some ribbon buttons, panel actions, menu items). While the eda-agent polling loop is active, those built-in commands may become temporarily unresponsive because Altium's scripting engine is single-threaded and currently owned by our polling loop.

The polling loop owns the scripting engine for as long as it's running. While it runs, Altium's own script-backed buttons sit waiting. The loop exits when either:

• The MCP client calls app_detach (or the dashboard Detach button is clicked); the loop saves all dirty docs, exits within ~500 ms, and Altium becomes fully responsive, OR
• 10 minutes of total silence from the MCP client (no commands AND no keep-alive pings) triggers the built-in auto-shutdown

In practice, while an MCP client is attached and sending keep-alive pings every 30 s, the loop will never time out on its own; you need to either have the AI call app_detach or close the MCP client session entirely. After the client disconnects, expect up to ~10 minutes for the loop to auto-exit unless you use Detach to release it immediately.

ECO (sch → PCB update) is not reliably scriptable

proj_sync_pcb wraps RunProcess('PCB:UpdatePCBFromProject'). On some Altium builds this runs silently without applying changes; on others it pops the modal ECO dialog. The Altium Schematic API doesn't expose a fully scripted ECO executor: IECO only records proposed changes, no DM_Execute method is documented, and no factory is exposed for obtaining an IECO instance from a script.

Practical workflow: call proj_sync_pcb and check the result's components_added_to_pcb count. If it's zero while in_sync is false, open the PCB in Altium and run Design → Import Changes From … yourself. Once the dialog is dismissed, every other tool (pcb_move_components, pcb_place_tracks, pcb_run_drc, etc.) works normally.

Tools vary in maturity

Not every one of the 300+ tools has been exercised on every Altium version or design size. The generic primitives and the core application / project tools are the best-tested. Some PCB modify operations (polygon repour, room creation, align-components) are less battle-tested. Queries are generally safer than mutations.

Timeout and server lifecycle

The server has three independent timeout mechanisms:

1. Per-command timeout (Python side)

When the MCP client calls a tool, the Python bridge writes a request file and waits up to 10 seconds by default for a response. Fast queries typically complete in under 100 ms, so a 10 s ceiling surfaces stalls quickly while leaving plenty of margin for real work. Long-running tools that are expected to take longer (app_save_all, stop_server, pcb_get_unrouted_nets) set their own larger timeouts internally.

Each request is published to its own request_<id>.json file; Altium replies in response_<id>.json with the matching ID. The bridge's keep-alive thread and MCP-client calls each use their own request IDs, so responses never race. The older single-response.json channel was retired in IPC v2.

2. Server auto-shutdown (Altium side)

The DelphiScript polling loop auto-stops after 10 minutes of inactivity (AUTO_SHUTDOWN_MS = 600000). If the MCP client disconnects and the keep-alive pings stop arriving, the server releases Altium's scripting engine after ten minutes and StartMCPServer returns. To resume, re-launch via File → Run Script... → StartMCPServer → Run.

3. Python keep-alive pings

While an MCP client is attached, the Python bridge pings Altium every 30 seconds so the 10-minute auto-shutdown never fires mid-session. The sequence:

• AI issues command A → Altium busy, then idle
• 30 s later, Python pings → Altium responds "pong", idle timer resets
• 10 min later, still no AI activity and no ping → Altium auto-shuts down

In practice: the server stays alive as long as an MCP client is connected, and exits cleanly ~10 minutes after the client fully disconnects. No manual stop needed in the common case. For a hard exit, the AI (or the Detach button on the dashboard window) calls app_detach, which persists any unsaved work via app_save_all and returns control to Altium within ~500 ms.

Why this matters for Altium UI responsiveness

The polling loop goes into idle mode after ~1 second of no MCP commands. In idle mode it polls every 100 ms with a ProcessMessages yield in between, so Altium's UI stays responsive continuously. In active mode the loop polls every 10 ms (ProcessMessages every 5th tick), giving sub-50 ms round-trip latency for back-to-back commands. For a full release, call app_detach or click Detach on the dashboard.

Tool reference

300+ tools grouped into six categories. The generic primitives are the engine; the rest are convenience wrappers or category-specific operations.

For a browsable index with per-tool maturity (offline / simulator / live-only) and interaction badges (which tools open a blocking dialog or leave work incomplete), see docs/TOOL_REFERENCE.md, auto-generated by python scripts/gen_tool_reference.py. At runtime, the tool_catalog tool serves the same data filtered.

Generic primitives (the core)

These six tools cover most day-to-day work. They accept any object type supported by the bridge.

Supported schematic object types: eNetLabel, ePort, ePowerObject, eSchComponent, eWire, eBus, eBusEntry, eParameter, ePin, eLabel, eLine, eRectangle, eSheetSymbol, eSheetEntry, eNoERC, eJunction, eImage.

Supported PCB object types: eTrackObject, eViaObject, ePadObject, eComponentObject, eArcObject, eFillObject, eTextObject, ePolyObject, eRuleObject, plus selection and design-rule classes.

Scope values: active_doc, project, project:<path>, doc:<path>.

Application (21 tools)

Project (53 tools)

Lifecycle, parameters, compilation, analysis, outputs, ECO sync, variants.

Library (53 tools)

Symbol and footprint creation, linking, batch editing, comparison.

Schematic and general (93 tools)

Schematic-side operations plus viewport and sheet management.

PCB (104 tools)

Queries and modifications on the active PCB document.