KiCAD MCP Server: Driving KiCAD 9 from an LLM Client
KiCAD MCP is a Model Context Protocol (MCP) implementation that enables Large Language Models (LLMs) like Claude to directly interact with KiCAD for printed circuit board design.
At a glance
- What is it?
- An MIT-licensed MCP server that exposes KiCAD project setup, schematic editing, routing, DRC/ERC and manufacturing export as tools an AI assistant can call. The README also points new development at a Rust rewrite under AGPL-3.0, which is the first thing to weigh before adopting this one.
- Who is it for?
- Adopt it if you already run KiCAD 9.0+ and want a scriptable, MIT-licensed way to let an assistant create symbols, place parts, route, and export fabrication files inside the tool you already use. Do not adopt it for safety-critical boards on the strength of generated output alone: the README's own disclaimer states that AI-generated design suggestions do not replace qualified engineering review.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap it fills between a chat window and a KiCAD project
KiCAD's Python API has always been usable, but using it means writing scripts against a moving target: project files, symbol libraries, footprint libraries, netlists, and the board file all have their own formats. The KiCAD MCP Server sits in that space. It is a Model Context Protocol server, built on the MCP 2025-06-18 specification per the README, that exposes KiCAD operations as tool schemas an LLM client can call. Claude, Copilot in VS Code, and other MCP clients are the intended callers. The audience is engineers who already know what a netlist is and would rather say "place the decoupling caps next to U1" than write a one-off script for it. The README frames the pitch as designing PCBs with natural language, and the feature list backs that up with project setup, schematic editing, component placement, routing, DRC/ERC, and export. Note what is not in the repository description: this is not a KiCAD replacement and not a layout engine. It is a control surface.
How the MCP tool layer reaches into a KiCAD session
The architecture that the material actually shows is a client-server split. The MCP server is the process your AI client talks to over the MCP protocol. On the other side, KiCAD 9.0 or later must be installed on the same machine, because the operations described (symbol creation, footprint creation, placement, routing, export) act on real KiCAD project state. The README calls this real-time project state access. The repository is Python for the server logic with a Node.js build step in the quick start, and the quick start requires both Node.js 18+ and Python 3.11+, so you should expect two runtimes on the machine, not one. Two integrations sit at the edges of that flow. Freerouting is invoked for automatic routing, and the README states it runs via Java or Docker, which means an autorouter dependency outside the Python process. JLCPCB integration supplies a parts catalog with pricing and stock data, so component selection can be informed by what is actually orderable rather than by what is in a local library. Visual feedback comes as snapshots and session logs, which is the traceability mechanism: you can see what the assistant did to the project rather than inferring it from a diff.
Getting it running: the commands and config files named in the README
The prerequisites are explicit: KiCAD 9.0+, Node.js 18+, and Python 3.11+. Installation is a clone, an npm install, and an npm run build. Configuration is per client. For GitHub Copilot in VS Code, the README says to copy config/vscode-mcp.example.json to .vscode/mcp.json, and VS Code auto-detects it. For Claude Desktop, you edit the client's own config file: %APPDATA%\Claude\claude_desktop_config.json on Windows, or ~/.config/claude/claude_desktop_config.json on macOS and Linux. Example configs ship in the repository as config/windows-config.example.json and config/macos-config.example.json. Beyond those entry points, the README routes you into docs/PLATFORM_GUIDE.md for platform setup, docs/ROUTER_QUICK_START.md for first routing steps, docs/TOOL_INVENTORY.md for the full tool list, and separate references for schematic tools, routing tools, the footprint and symbol creator, and JLCPCB usage. That documentation split is worth reading before you configure anything, because the tool inventory is where you find out whether the operations you need exist as callable tools or only as manual KiCAD actions.
Where the design bites back: routing dependencies and generated libraries
Two constraints stand out. First, automatic routing is not self-contained. Freerouting runs via Java or Docker according to the README, so a machine that satisfies the Python and Node prerequisites can still fail at the routing step if neither runtime is present. That is an operational dependency the quick start does not mention. Second, the custom symbol and footprint generation feature is the one most likely to cause silent problems. Generated footprints are geometry, and geometry errors do not surface until fabrication. The README's disclaimer is unusually direct about this, listing errors in generated schematics, PCB layouts, and manufacturing files, damage to hardware, and financial losses from incorrect orders as things the authors accept no liability for. It also states that safety-critical applications in medical, aerospace, and automotive require mandatory independent expert verification. Treat that as the project's own statement of its boundary. There is also a currency risk that the README does not resolve: KiCAD 9.0+ is the stated floor, but the documentation does not say how tool coverage tracks newer KiCAD releases, so a version bump is a thing to verify rather than assume.
Konnect, the Rust rewrite, and what the split actually means
The README opens with a notice that reframes the whole project. Konnect is described as this project rebuilt from scratch in Rust as a native KiCAD 10 plugin, built on KiCAD's official IPC API instead of SWIG, shipping as a single binary with no runtime dependencies, with 171 tools, bundled Claude skills and agents, design-review audits, and a manufacturing pipeline. The README states plainly that Konnect is where new development happens, and that it is licensed AGPL-3.0, free for individuals and open source, with commercial licenses available for businesses. The difference in approach is not cosmetic. This Python server talks to KiCAD through SWIG bindings and needs Node.js, Python, and a build step; Konnect talks to KiCAD 10 through the official IPC API and ships as one binary. The practical consequence is a licence fork in the road. MIT on this server versus AGPL-3.0 on Konnect changes what you can do in a closed-source commercial product, and the README notes commercial Konnect licences exist for that case. If you need permissive licensing and KiCAD 9 compatibility, this repository is the one that matches; if you want the actively developed path and can live with AGPL terms or buy a commercial licence, the README points you elsewhere.
Maintenance, releases, and the cost of staying current
The repository is not archived and last saw a push in September 2026, with releases v2.5.0, v2.6.0, and v2.7.0 landing between late July and late August 2026. That is a steady cadence, and it is the reason the README can say this server remains fully open and maintained even while new development moves to Konnect. The upgrade cost is not in the Python package itself. It is in the surface area: a KiCAD version, a Node.js runtime, a Python runtime, an MCP client config that differs per editor, and optionally Java or Docker for Freerouting. Each of those can move independently and break the chain. The documentation set (platform guide, tool inventory, per-domain references, changelog) is what you would consult when it does. On licensing, MIT is permissive and the README notes the licence excludes all liability, which is consistent with the warranty disclaimer. That is a description of the terms, not advice about your situation; if you are shipping a closed product, read the LICENSE file and the Konnect licence terms side by side before deciding which server to build on.
Editorial conclusion
Adopt it if you already run KiCAD 9.0+ and want a scriptable, MIT-licensed way to let an assistant create symbols, place parts, route, and export fabrication files inside the tool you already use. Do not adopt it for safety-critical boards on the strength of generated output alone: the README's own disclaimer states that AI-generated design suggestions do not replace qualified engineering review. Before trusting it on a real board, confirm the tool inventory in docs/TOOL_INVENTORY.md matches your KiCAD version, then run ERC and DRC yourself and diff the exported Gerbers against a hand-checked reference.
Community notes