KiCad has no built-in AI. What it has instead is an ecosystem that grew up around it very quickly, and if you go looking you will find open-source MCP servers, plugins, forum threads, and a lot of confident claims that do not agree with each other.
I have spent a while in this space. Here is an honest map of the four approaches, what each is genuinely good for, and the one distinction that determines whether any of them will help you.
The distinction that matters
Before comparing anything: when an AI triggers KiCad's autorouter, KiCad routes the board. The model supplied the intent and the sequence of actions. It did not lay the copper.
That sounds pedantic. It is not, and it decides everything downstream. If your bottleneck is routing quality, no amount of model capability changes it — you are still getting KiCad's router either way. If your bottleneck is the hours spent on repetitive edits, checks, and exports, then an AI driving those operations is genuinely valuable. Work out which one you have before choosing a tool.
1. MCP servers: let an agent drive KiCad
This is the most capable option available today. The Model Context Protocol lets an assistant call tools directly, and several open-source KiCad MCP servers now expose schematic, board, ERC/DRC, BOM, and export operations as callable tools. With one installed, Claude, Cursor, Copilot, or any MCP client can operate KiCad programmatically instead of through the GUI.
One implementation is a native KiCad 10 plugin written in Rust as a single binary, built on KiCad's official IPC API rather than the older SWIG bindings — which matters, because the IPC API is the path KiCad itself is investing in.
Where it wins: batch edits, running checks across a project, generating BOMs, driving exports, auditing a design against rules. Anything repetitive and well-specified.
What to know: it is a developer setup. You install a server, wire it into your assistant, and keep it working across KiCad versions. And the agent is calling KiCad's engines, so routing quality is KiCad's.
2. Python scripting with an assistant
The most underrated option, by a distance.
KiCad has had a Python API for years, and assistants are very good at writing against it. Bulk-renaming nets, generating footprints from a table, extracting data from a board file, automating the edit you would otherwise do a hundred times by hand — this is squarely in the model's strength.
Where it wins: lowest friction of anything here. No new infrastructure, no protocol, no server. And once the script exists it is completely deterministic — it does the same thing every run.
What to know: read and test what the assistant writes, and run it on a copy first. A script that silently mangles a board file is worse than no script.
If you have never tried this, start here. Most people reaching for an MCP server would get more value from twenty lines of Python this week.
3. Computer use: a model clicking the GUI
Newer models can operate a desktop application directly — open KiCad, place parts, press Auto-Route, export. It works, and it demos extremely well.
Where it wins: nothing to install, no API to learn. Fine for exploring what an agent can do, or a one-off task where writing a script is not worth it.
What to know, and this is the part the demos skip: it is the slowest possible path. Every action costs a screenshot, a decision, and a click, to drive an application that already has a scripting interface doing the same work in milliseconds. It is also not reproducible — run the same request twice and the model may take a different path and land on a different board. For hardware, that last point is usually disqualifying on its own.
4. AI-native tools that are not KiCad
A separate category generates the design itself: you describe a board, a model drafts the parts and netlist, and a deterministic engine places and routes it, then exports fabrication files.
Where it wins: it covers the step none of the above do — producing a design from intent, rather than automating edits to one you already have. Nothing to set up.
What to know: it is a different tool, not a KiCad add-on. If your libraries, your team, and your workflow live in KiCad, a script or an MCP server keeps you where you are, and that is often the right call.
The line that runs through all four
The same boundary shows up every time. A language model is strong at judgement: which regulator, which topology, what a script should do, which checks to run. It has no way to measure whether a trace clears a pad by 0.15 mm — so everything downstream of a measurement has to come from a deterministic engine: a router, a rule checker, a geometry library.
AI that automates the operating of those engines is useful and already works. AI asked to be one is where the claims outrun reality.
So which should you use
- A specific repetitive task you can describe precisely → Python plus an assistant. Least setup, most reliable payoff.
- An agent working across a whole project → an MCP server. Real capability, real setup cost.
- Curious what computer use can do → try it, but do not build a workflow on it.
- You want a board generated from a description → that is a different kind of tool, and worth being clear with yourself that it is not a KiCad add-on.
I work on PCBEditor, which is the fourth category — so take my read on that one with the appropriate salt. The first two are where most KiCad users will get value this year, and neither of them is us.
A longer version of this map lives at pcbeditor.com/kicad-ai.
Top comments (0)