Hardware engineering has long suffered from a lack of the “instant feedback” loop that software developers take for granted. While a software engineer can run a unit test in milliseconds, a hardware engineer often waits for simulations to finish or, worse, for PCBs to arrive from the fab, only to realize a component value was off by an order of magnitude.<\/p>\n
This week, the gap between LLM-driven design and physical reality narrowed significantly. By leveraging Anthropic’s Model Context Protocol (MCP), developers are now bridging Claude Code directly to SPICE simulators and physical test equipment, creating a “compiler for hardware” that catches hallucinations before they reach the breadboard.<\/p>\n
Developer Lucas Gerads recently demonstrated a viral workflow that uses Claude Code<\/a> to automate the entire hardware verification cycle. By connecting Claude to a LeCroy oscilloscope and a SPICE simulator via MCP, Gerads showed how an AI agent can autonomously design a circuit, simulate it, flash code to a microcontroller, and then verify the physical output against the simulated model.<\/p>\n According to Gerads<\/a>, the primary motivation was the difficulty of expressing complex designs in plain English. “I realized that Claude Code really shines when it can get immediate feedback,” he noted. The demonstration involved a simple RC filter and an MCU, but the implications for complex embedded projects are profound. The workflow effectively treats the oscilloscope and the simulator as external “verifiers” that prevent the model from falling into “optimistic hallucinations.”<\/p>\n The technical backbone of this integration is the Model Context Protocol (MCP)<\/a>, an open-source standard that functions like a “USB-C port” for AI models. MCP allows a host (like Claude Desktop or Claude Code) to communicate with local or remote servers that expose specific tools and resources.<\/p>\n To handle the simulation, the workflow utilizes spicelib<\/a>, a Python library designed to bridge the gap between Python’s data science stack and SPICE engines like LTspice, QSpice, and NGSpice.<\/p>\n The connection is facilitated by three specific MCP servers:<\/p>\n Communication between the Claude client and these servers happens via JSON-RPC 2.0<\/strong> over standard input\/output (stdio) for local processes. This allows Claude to call a tool like To replicate this setup, you will need a Windows or Linux machine (macOS requires WINE for LTspice) and a supported SPICE simulator.<\/p>\n First, install the core library that handles the simulation automation:<\/p>\n You can test the Python-to-SPICE bridge with this simple script. This assumes you have a file named To give Claude access, you must configure your Once configured, open Claude Code and run: Claude should invoke the This workflow represents a shift from “AI as a copywriter” to “AI as a systems engineer.”<\/p>\nUnder the hood<\/h2>\n
The Simulation Layer: spicelib<\/h3>\n
spicelib<\/code> is not a simulator itself; it is a controller. Its core capabilities include:<\/p>\n\n
.asc<\/code> or netlist files and modifying component values (e.g., changing a resistor from 1k to 10k).<\/li>\nXVIIx64.exe<\/code> for LTspice) and handling parallel batch runs.<\/li>\nRawRead<\/code> tool to parse .raw<\/code> binary output files directly into NumPy arrays for analysis.<\/li>\n<\/ul>\nThe Hardware Layer: MCP Servers<\/h3>\n
\n
spicelib<\/code> functions as tools for Claude.<\/li>\nrun_simulation<\/code> or get_oscilloscope_waveform<\/code> and receive structured data back in its context window.<\/p>\nHow to try it yourself<\/h2>\n
Prerequisites<\/h3>\n
\n
1. Install spicelib<\/h3>\n
\npip install spicelib\n<\/code><\/pre>\n2. Minimal Working Example<\/h3>\n
filter.asc<\/code> in your directory.<\/p>\n\nfrom spicelib import SimRunner\nfrom spicelib.raw_read import RawRead\n\n# Initialize the runner for LTspice\nrunner = SimRunner(output_folder='.\/sim_results', simulator='LTspice')\n\n# Run a simulation\n# Note: In a real MCP setup, Claude would trigger this via a tool call\nrunner.run_simulation('filter.asc')\n\n# Parse the results\nraw_data = RawRead('.\/sim_results\/filter.raw')\nprint(f\"Available traces: {raw_data.get_trace_names()}\")\n<\/code><\/pre>\n3. Setting up the MCP Server<\/h3>\n
claude_desktop_config.json<\/code> (or the equivalent for Claude Code). Per the MCP specification<\/a>, your config should look like this:<\/p>\n\n{\n \"mcpServers\": {\n \"spice-sim\": {\n \"command\": \"python\",\n \"args\": [\"-m\", \"spicelib_mcp_server\"]\n },\n \"oscilloscope\": {\n \"command\": \"python\",\n \"args\": [\"-m\", \"lecroy_mcp_server\", \"--ip\", \"192.168.1.100\"]\n }\n }\n}\n<\/code><\/pre>\nQuick Test<\/h3>\n
\"Can you run a SPICE simulation of the RC filter in this directory and tell me the -3dB cutoff frequency?\"<\/code><\/p>\nspice-sim<\/code> tool, parse the .raw<\/code> file, and return the numerical result without you ever opening the LTspice GUI.<\/p>\nWhere this fits<\/h2>\n
Competitive Landscape<\/h3>\n
\n
PyLTSpice<\/code> or spicelib<\/code> for Monte Carlo analysis. However, these require the engineer to write the analysis logic themselves.<\/li>\nTrade-offs<\/h3>\n