KiCad MCP servers: what they do and which one to use

The Model Context Protocol describes itself as an open-source standard for connecting AI applications to external systems. An MCP client (Claude Desktop, Claude Code, Cursor, VS Code with Copilot and others) connects to an MCP server, and the server exposes tools the model can call. The model decides when to call a tool, and the server does the work.

For KiCad, that work happens in one of three ways. Some servers parse the KiCad files directly. Some call kicad-cli, KiCad's command-line tool, which can run a DRC on the board and an ERC on the schematic, export Gerbers, a BOM and a netlist, but has no commands for editing a design. And some talk to a running copy of KiCad through its IPC API, which KiCad's developer docs describe as an interface to remotely control a running instance of KiCad.

The route a server takes sets what it can do. File parsing and kicad-cli are good at reading and checking. Editing needs either careful file writing or the IPC API, and that is where the servers differ most.

An MCP session is a model calling tools and reading what comes back, so we watched that loop on a real board. An AI agent built a small Bluetooth tag with tscircuit, the open-source engine Cherry Blossom runs on, on our own machine, using the same tscircuit version and review tool as Cherry Blossom's agent. Its tools were a build, a netlist check, a design rule check and a schematic review. The final board passed all four: 0 DRC errors, 0 netlist errors or warnings, and no review problems.

Along the way, three tool results were wrong or led somewhere bad. The parts lookup rated the module's pinout only "single_source", so we checked the pin mapping against Ebyte's own pin table. Rotated 0402 resistors kept an unrotated courtyard (the keep-clear outline around a part), which tripped the placement check. And a 0.25 mm trace width made the router drop a via inside a resistor pad, so the width went back to 0.2 mm.

That is what the server READMEs above warn about. A clean report says the checks passed, not that the design is right. This board passed all four and still carried three risky choices, which an outside review found by reading the datasheets pin by pin. One was USB power wired straight into a module pin rated 5.8 V at most; another asked an LED pin for 4 mA when its standard drive is about 2 mA. Both are fixed now, and the checks pass again. The board still needs a person to confirm battery polarity with a meter and match the connector footprints to the vendor drawings, and it has not been built or tested in hardware.

The weak link is the model, not the server. A server can run DRC perfectly and the model can still misread the report, pick the wrong part or connect the wrong pin. On EEBench, atopile's circuit benchmark, the best frontier model scores 69.3% (our write-up), which is roughly three circuit tasks in ten wrong. So treat an MCP session like a fast junior helper: useful, and checked. That is also why Cherry Blossom puts a verification gate after every AI edit, and why an automatic design check matters more than the assistant's confidence.

Edits made to KiCad files from outside KiCad can also leave the project in a state the GUI does not expect. Work on a branch, reopen the project after each change, and run ERC and DRC yourself before exporting anything for fabrication.