Konnect: a single Rust binary that turns KiCAD 10 into an MCP server
AI-assisted PCB design for KiCAD 10. Native KiCAD plugin — a single Rust binary exposing 217 schematic, layout, routing, placement, design-review, and manufacturing tools to Claude, or the LLM of your choosing
At a glance
- What is it?
- Konnect is a beta KiCAD 10 plugin that exposes schematic, layout, routing and manufacturing tools to Claude and other LLM clients over MCP. The pitch is architectural: one process, no SWIG, no Python subprocess, and on-demand toolsets to keep context cost down.
- Who is it for?
- Adopt Konnect if you are on KiCAD 10, you already drive an MCP-capable assistant, and you want schematic and board edits to happen inside the running editor with undo/redo rather than through file rewrites. Skip it if you are pinned to KiCAD 9 or older, if you need a stable non-beta toolchain, or if AGPL-3.0 is incompatible with how you ship your own plugin or derivative work.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, 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 problem Konnect is aimed at, and who feels it
The README frames Konnect as the successor to KiCAD-MCP-Server, a Python and TypeScript project by the same author. The stated failure modes of that predecessor are specific: a tool call crosses TypeScript, schema validation, a spawned Python subprocess, JSON over stdin/stdout, a command router, and SWIG-generated C++ proxies before it reaches the board. Four language and serialization boundaries, each with its own failure mode, including subprocess lifecycle management, stdout parsing that has to filter warnings KiCAD writes into the stream, and chunked JSON reassembly. Konnect's answer is that a tool call becomes a function call in one process.
The audience is narrower than "PCB designers." It is people who already run KiCAD 10, already use an MCP client such as Claude, and want the assistant to modify the live project rather than produce a description they apply by hand. The README lists what that means in practice: placing and wiring schematic components by pin name, moving and routing footprints in real time, running ERC and DRC, exporting Gerbers and pick-and-place files, and searching a local 2.5M-part JLCPCB catalog. If your workflow is a text editor and a batch script, the value proposition is much weaker.
Two editing paths: S-expressions for schematics, IPC for boards
The mechanism table splits the work. Schematic editing is direct `.kicad_sch` S-expression editing with atomic writes, and the README states it does not require KiCAD to be running. The write pattern is described as write, fsync, rename, with UUID preservation and round-trip tests. That is a plausible design for avoiding half-written schematic files, and it also means schematic work does not depend on the editor being open.
PCB editing goes the other way. It uses the KiCAD 10 IPC API, which the README describes as protobuf over NNG, and it is real-time and undo-aware. This is the layer that replaces SWIG, which the README says KiCAD is deprecating in favour of the IPC API. The stated operational reasons for leaving SWIG behind are concrete: a zone-fill call that can segfault the backend, proxy-object comparison bugs, and a fallback path that can silently swap backends mid-session. Those are the kinds of problems that are hard to reproduce and hard to report.
One detail worth reading carefully: single-footprint placement has a safe headless fallback. That phrasing implies the IPC path is not always available, and the fallback exists to keep one class of operation working when it is not.
The toolset router, and why 226 tools is not the number that matters
The header of the README says 226 tools across 21 on-demand toolsets; the repository description says 217. The two numbers disagree, and the README's own context-economy section repeats 226. Treat the count as approximate and check `tool-directory.md` for the authoritative list if the exact number matters to you.
The design decision behind the router is the interesting part. Exposing every tool to the model costs roughly 23K tokens of context on every listing, according to the README. Konnect instead loads a starter kit of about 2K tokens and lets the model pull toolsets in on demand. For anyone who has watched a long agent session degrade as the context fills with tool schemas, this is the right problem to attack, and it is a router-level fix rather than a prompt-level one.
The README also mentions built-in observability: `get_recent_calls`, `server_stats`, and JSONL call logs. The stated purpose is to let the model diagnose its own tool failures. Whether a model actually does that well is an open question, but the logs are there for a human to read regardless.
Installation, transport, and the settings that matter
The recommended path is the KiCAD Plugin and Content Manager. Download the platform package from Releases, named `konnect-pcm-v<version>-windows.zip`, `-macos.zip` or `-linux.zip`. Each bundles that platform's server binary, and the macOS package is a universal build covering Apple Silicon and Intel. The README distinguishes these from the other archives, which are standalone server binaries rather than plugin packages. Then open KiCAD 10, go to Plugin and Content Manager, click Install from File, select the zip, and restart KiCAD. The stated verification step is PCB Editor, then Tools, then External Plugins, where Konnect should appear.
Transport defaults to MCP JSON-RPC over stdio. Streamable HTTP is available by setting `transport` to `"http"` or `"both"`. Exports and checks such as Gerber, PDF, ERC and DRC run through a `kicad-cli` subprocess, so `kicad-cli` needs to be present and working even though the schematic editor itself does not.
For KiCAD 10 there is an optional native Specctra bridge in the Konnect settings dialog. With it enabled, `export_specctra_dsn` can ask the active PCB Editor to generate its native DSN while Konnect binds the export to the exact IPC snapshot and builds the strict reverse manifest used during SES import. The README describes the bridge as explicit opt-in and authenticated. The default routing path is a revision-bound Rust DSN export, local Freerouting MCP routing, and a strict one-transaction SES import.
Where this is the wrong tool
The project labels itself beta. The README says the core toolchain is tested and working but that the release "wants real-world mileage and review." That is the author's own assessment, and it should be taken at face value when deciding whether to point it at a board you intend to manufacture.
The hard dependency is KiCAD 10. The IPC API path, the native Specctra bridge, and the plugin packaging all assume it. If your team is standardized on KiCAD 9 or an older release, Konnect is not a candidate, and there is no stated backport plan.
The routing story is the most indirect part of the system. Freerouting runs as a separate MCP server, DSN export is revision-bound, and SES import is described as strict and single-transaction. Each of those constraints is defensible on its own, but together they mean autorouting has more moving parts than schematic edits do. The native bridge reduces part of that by letting KiCAD generate the DSN, but it is opt-in, and the README does not describe what happens when the bridge is enabled but the active PCB Editor is not the one Konnect expects.
Finally, the licence is AGPL-3.0. If you plan to modify Konnect and distribute it, or to embed it in something you ship, that is a constraint you need to evaluate with your own counsel. Nothing in the README discusses commercial licensing.
How it differs from the project it replaces
The obvious alternative is KiCAD-MCP-Server, and the README is unusually direct about the comparison. The predecessor carries Node.js and its npm tree, Python and its pip packages, wxPython, kicad-skip, and KiCAD's SWIG bindings. That is two package ecosystems plus a binding layer, and the README calls each of them a moving target that can break an install. Konnect ships as a single static binary, described as 20 to 25 MB depending on platform with a roughly 9 MB download, and there is nothing to install alongside it.
The deeper difference is which KiCAD interface each one targets. The predecessor's PCB backend depends on SWIG Python bindings, which the README says KiCAD is deprecating. Konnect targets the IPC API. If you are choosing between them today, the question is not which one is faster but which interface will still exist in two years. The README states that the original project remains open, maintained, and useful, and points to a comparison section for details, so this is not a deprecation notice for the older tool.
There is also an adjacent product in the same README: Nimrod, a web-research MCP server from the same group, offered as a way to pull live parts availability and datasheets during design. It is a separate service with its own credit model (one credit per search, extraction free, a 50-credit trial), not part of Konnect.
Maintenance surface and upgrade cost
The release cadence visible in the repository is fast. v0.11.1 landed on 2026-09-07, v0.11.0 on 2026-08-29, and v0.10.1 earlier the same day. Three releases in roughly ten days at the 0.10 to 0.11 boundary suggests the tool surface is still moving, and that a pinned version is safer than tracking the latest if you have a working setup.
The dependency surface after installation is small by design: a single binary, plus `kicad-cli` for exports and checks, plus KiCAD 10 itself for the IPC path. The heavier operational dependency is Freerouting for the routing flow, which the README describes as a local MCP server. Upgrading Konnect therefore means matching the plugin package to the KiCAD version you run, not reconciling a Python environment. That is the main maintenance win the README claims, and it is the one most likely to hold up.
On licensing: AGPL-3.0 is a copyleft licence with network-use provisions. The README does not address what that means for plugins that call Konnect, for internal-only deployments, or for forks. That is a question for your legal team, not for this article.
Editorial conclusion
Adopt Konnect if you are on KiCAD 10, you already drive an MCP-capable assistant, and you want schematic and board edits to happen inside the running editor with undo/redo rather than through file rewrites. Skip it if you are pinned to KiCAD 9 or older, if you need a stable non-beta toolchain, or if AGPL-3.0 is incompatible with how you ship your own plugin or derivative work. Before committing, verify three things yourself: that the plugin appears under PCB Editor then Tools then External Plugins after install, that the IPC API path actually edits a board on your machine (the README notes a safe headless fallback for single-footprint placement, which implies the IPC path can be unavailable), and that your board's DSN and SES round trip through the Specctra flow without the native bridge enabled, since that bridge is opt-in and authenticated.
Community notes