Closing the Hardware Loop: Claude Code, SPICE, and Oscilloscopes

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.

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.

What happened

Developer Lucas Gerads recently demonstrated a viral workflow that uses Claude Code 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.

According to Gerads, 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.”

Under the hood

The technical backbone of this integration is the Model Context Protocol (MCP), 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.

The Simulation Layer: spicelib

To handle the simulation, the workflow utilizes spicelib, a Python library designed to bridge the gap between Python’s data science stack and SPICE engines like LTspice, QSpice, and NGSpice.

spicelib is not a simulator itself; it is a controller. Its core capabilities include:

• Netlist Manipulation: Programmatically opening .asc or netlist files and modifying component values (e.g., changing a resistor from 1k to 10k).
• Execution Management: Managing the simulator executable (e.g., XVIIx64.exe for LTspice) and handling parallel batch runs.
• Binary Parsing: Using the RawRead tool to parse .raw binary output files directly into NumPy arrays for analysis.

The Hardware Layer: MCP Servers

The connection is facilitated by three specific MCP servers:

1. lecroy-mcp: An MCP server that wraps the LeCroy oscilloscope’s remote control API (typically via VISA/VXI-11).
2. spicelib-mcp: A server that exposes spicelib functions as tools for Claude.
3. rc-filter-demo-files: A repository containing the specific demo configurations.

Communication between the Claude client and these servers happens via JSON-RPC 2.0 over standard input/output (stdio) for local processes. This allows Claude to call a tool like run_simulation or get_oscilloscope_waveform and receive structured data back in its context window.

How to try it yourself

To replicate this setup, you will need a Windows or Linux machine (macOS requires WINE for LTspice) and a supported SPICE simulator.

Prerequisites

• Python 3.10 or higher.
• LTspice installed (ensure the executable is in your system PATH).
• An Anthropic API key for Claude Code.

1. Install spicelib

First, install the core library that handles the simulation automation:

pip install spicelib

2. Minimal Working Example

You can test the Python-to-SPICE bridge with this simple script. This assumes you have a file named filter.asc in your directory.

from spicelib import SimRunner
from spicelib.raw_read import RawRead

# Initialize the runner for LTspice
runner = SimRunner(output_folder='./sim_results', simulator='LTspice')

# Run a simulation
# Note: In a real MCP setup, Claude would trigger this via a tool call
runner.run_simulation('filter.asc')

# Parse the results
raw_data = RawRead('./sim_results/filter.raw')
print(f"Available traces: {raw_data.get_trace_names()}")

3. Setting up the MCP Server

To give Claude access, you must configure your claude_desktop_config.json (or the equivalent for Claude Code). Per the MCP specification, your config should look like this:

{
  "mcpServers": {
    "spice-sim": {
      "command": "python",
      "args": ["-m", "spicelib_mcp_server"]
    },
    "oscilloscope": {
      "command": "python",
      "args": ["-m", "lecroy_mcp_server", "--ip", "192.168.1.100"]
    }
  }
}

Quick Test

Once configured, open Claude Code and run: "Can you run a SPICE simulation of the RC filter in this directory and tell me the -3dB cutoff frequency?"

Claude should invoke the spice-sim tool, parse the .raw file, and return the numerical result without you ever opening the LTspice GUI.

Where this fits

This workflow represents a shift from “AI as a copywriter” to “AI as a systems engineer.”

Competitive Landscape

• Manual GUI Simulation: The status quo. It is slow and prone to human error in data transcription. While tools like LTspice are powerful, they are “islands” of data.
• Custom Python Scripts: Many engineers already use libraries like PyLTSpice or spicelib for Monte Carlo analysis. However, these require the engineer to write the analysis logic themselves.
• Claude + MCP: Replaces the need for the engineer to write the “glue code.” Claude can look at the simulation data, identify a discrepancy, and suggest a component change autonomously.

Trade-offs

What practitioners are saying

The reaction from the community has been a mix of awe and caution. On Hacker News, the consensus is that “closing the loop” is the only way to make LLMs viable for hardware.

One practitioner noted the “Verifier Theory”: the idea that because LLMs lack a physical world model, they default to “optimistic narration.” As one user put it, the model “can’t talk its way past” a mismatched waveform on a physical scope. If the simulation says 1V and the scope says 0.5V, the model is forced to reconcile that reality rather than hallucinating a success.

However, there is significant dissent regarding the “rabbit holes” of toolchain setup. Some users on Reddit warned that Claude Code can be “dangerously confident” without these constraints, sharing anecdotes where the model hallucinated entire board capabilities that didn’t exist. The consensus: MCP isn’t just a feature; it’s a safety requirement for hardware AI.

Takeaways

• LLMs require external grounding: Never trust an LLM’s circuit design without a simulation or hardware-in-the-loop (HIL) verification step. The “optimistic hallucination” is too high a risk in electronics.
• MCP is the new standard: If you are building AI tools for engineers, stop writing custom integrations. Use MCP to ensure your tools can talk to any host (Claude, Cursor, etc.).
• Data Management is key: When using MCP, do not dump raw waveform data into the LLM context. Save it to a file and let the model use tools (like spicelib‘s parser) to extract specific metrics (Vpp, frequency, rise time).
• The “Compiler” for Hardware is here: By treating SPICE as a compiler and the oscilloscope as a debugger, we can finally apply modern CI/CD practices to physical hardware design.

Full analysis: {BLOG_URL}