Using KiCad or Fusion Through MCP Is Like Sucking a Pizza Through a Straw
When you connect an AI agent to KiCad or Fusion through MCP or computer use, the agent works the tool the way a human does. Computer use drives the menus, dialogs, and mouse clicks, and reads screenshots. An MCP server for a desktop CAD tool gives the agent the same commands a human uses, one step at a time. That gives people an early taste of AI in hardware design. But it is not how agents will engineer hardware. Agents need direct access to the EDA and CAD kernels, and to the simulation, analysis, inspection, and validation tools behind them.
This week I posted this on X:
“Using KiCad or Fusion through MCP or computer use is like sucking a pizza through a straw.”
A lot of engineers agreed. Some pushed back. Both made me want to explain the idea properly.
Your coding agent doesn’t click around VS Code
Watch an AI coding agent work. It doesn’t open VS Code, find the File menu, and click Save. It works directly with files, compilers, and other tools. It runs the build and the tests, reads the errors, fixes the code, and runs everything again. Hundreds of times an hour.
The editor is still there. It’s for the human who reviews the work, not for the agent that does it.
Now picture the same agent writing code only through screenshots of an IDE. One click at a time. Scrolling to read a stack trace. Nobody would build software that way!
Why MCP and computer use hit a ceiling in CAD
I like these integrations. They give people an early taste of what’s becoming possible, and that matters.
But they’re transitional technology. They’re fundamentally constrained by interfaces designed for humans.
Take one small change: move a USB-C connector 5 mm. In a desktop EDA tool, that’s select, drag, fix the traces that broke, refill the copper, run the design rule check, and read the report. Then open the enclosure in a second tool, move the cutout, and check that the plug still clears the wall.
Each of those steps is sized for a human hand. Through MCP or computer use, the agent does them one at a time, looks at the result, and works out what happened.
The agent never touches the engineering. It touches the buttons that a human presses to reach the engineering.
Text files aren’t the native interface either
Many replies said the same thing: KiCad files are plain text. Your agent can read the netlist, edit the board file, and diff it like code.
True, and it’s a step up from clicking around. But I don’t think editing text files is the native way for AI agents to work with EDA and CAD either.
A board file is a record of the design, not the design. Move a footprint by editing its coordinates, and the file still looks fine. The file can’t tell you that the new position breaks a clearance rule, that the part no longer fits under the lid, or that the regulator next to it now runs too hot. To know that, you need the tools that understand the design: the layout engine, the design rule checker, the CAD kernel, and the simulator.
Mechanical design makes this even clearer. A STEP file holds exact geometry, but nobody designs an enclosure by editing STEP text. You design it with a CAD kernel that knows how to shell a body, fillet an edge, and check that two parts don’t collide.
Other replies pointed to Python CAD packages and to agents that work with B-rep geometry directly. That’s much closer to what I mean. The kernel, not the GUI and not the file format.
What AI agents actually need
The real opportunity is for agents to work directly with the underlying EDA and CAD kernels, along with the simulation, analysis, inspection, and validation tooling.
No GUI gymnastics. No manipulating file formats as a proxy for engineering. Direct access to the actual engineering capabilities!
For a hardware agent, that means:
- The electronics kernel. Parts, nets, schematics, layout, routing, and design rules, as live design data that the agent reads and changes directly.
- The mechanical kernel. Exact solids and assemblies that the agent models, edits, and measures.
- Simulation. Circuit, electromagnetic, and thermal simulation that the agent runs on its own design.
- Inspection and validation. Design rule checks, fit and clearance checks between the board and the enclosure, and the rules of your manufacturer.
- Manufacturing. Fabrication files, quotes, and orders for the board and the mechanical parts.
With these, a hardware agent works the way a coding agent works with a compiler. It makes a change, checks it, reads the result, and fixes what’s wrong. Again and again, in seconds, with no human driving a mouse.
This is how we built Flux
For me, this isn’t a theory. It’s how we built Flux.
The Flux agent doesn’t drive a GUI. It works directly with the electronics and the mechanical design in one project, and with the tools that check them. Ask it to move the mounting holes to a 50 mm pitch, and it changes the board and the enclosure together. Ask it to route the board, and it routes, checks the rules, and refines the routes in the chat.
It can check component heights against the enclosure, run an electromagnetic simulation of the routed board, and edit a STEP file that it didn’t make. All from one request.
The canvas is still there, in 2D and 3D. It’s where you review what the agent did, the way you review a pull request.
And yes, Flux has an MCP server too. The difference is what sits behind it. Your coding agent doesn’t click through a CAD tool. It hands the hardware job to the Flux agent, and the Flux agent does the engineering with direct access to the kernels and the tools.
I see this every day building Flux. The closer the agent works to the engineering, the better the hardware it gets built.
Where this ends
The goal isn’t AI-assisted CAD. The goal is to make the CAD disappear.
MCP and computer use for desktop CAD are the Cursor phase of hardware: AI added to the tools we already have. Software already went through the next phase. The agent became the primary interface, and the tools moved behind it. Hardware is next!
So stop sucking the pizza through a straw. Give your agent the whole kitchen!
FAQs
Yes. MCP servers and computer-use agents let an AI agent open, read, and change projects in desktop tools like KiCad and Fusion. With MCP, the agent calls the commands that the tool gives a human user. With computer use, it clicks through the screens. Either way, it works one step at a time.
Computer use is an AI agent that operates a desktop app the way a person does. It reads screenshots, moves the mouse, and types. It works with almost any app, but every action goes through an interface that was made for humans.
KiCad files are plain text, so an agent can read and edit them. But a file is a record of the design. To know if a change breaks a clearance rule, collides with the enclosure, or makes a part run too hot, the agent needs the tools that understand the design: the layout engine, design rule checks, the CAD kernel, and simulation.
The agent reads and changes the design data itself: parts, nets, layout, and 3D solids. It runs simulation, inspection, and validation tools on that data directly, with no GUI and no file format in between. Then it checks the result and fixes what is wrong.
Yes. Connect the Flux MCP server to Claude Code, Cursor, Codex, ChatGPT, or another MCP client. Your agent can then read your Flux projects and hand hardware design jobs to the Flux agent, which does the electronics and mechanical work in Flux.
Related Content
Let’s start building.
Let’s build your idea together. All you need to do is describe what you want to make, or what problem you want to solve. Flux will work with you to make it a reality.
