Ltspice Mcp · LLM Mart

Name: Ltspice Mcp
Author: LLM Mart

No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.

WIP 0.6.0 was a breaking release: the tool surface consolidated to six operations plus a waveform widget and a code runner, and the same engine became importable as a Python API. Pin ltspice-mcp==0.5.* if you need the old 49-tool surface.

ltspice-mcp lets LLM assistants run LTspice and ngspice simulations and edit LTspice .asc schematics. It returns structured measurements such as cutoff frequency, overshoot, phase margin, rise time, and per-device small-signal operating-point parameters (gm, gds, vth, …). Callers access these values by name without parsing raw files. It works on the same files you open in LTspice. Built on spicelib.

Quick start

Claude Code — two commands, and the tools are there in your next session:

/plugin marketplace add cognitohazard/ltspice-mcp
/plugin install ltspice-mcp

Claude Desktop — build the extension in packaging/mcpb/ and drag the .mcpb file onto Claude Desktop. It installs in one click and asks which folder your circuits are in.

Any other MCP client — Cursor, Windsurf, Gemini CLI, Continue, Cline, Zed and others. Install the server, then add it to that client's MCP config file (each client's own docs say where that file lives):

uv tool install ltspice-mcp        # or: pipx install ltspice-mcp

{
  "mcpServers": {
    "ltspice": { "command": "ltspice-mcp", "args": [] }
  }
}

Needs Python 3.11 or newer; ltspice-mcp --help confirms it installed. In Claude Code you can skip the JSON with claude mcp add -s project ltspice -- ltspice-mcp. The same server is also published as circuit-mcp and ngspice-mcp — same program, in case one of those names is easier to remember.

You also need a simulator on the same machine. LTspice or ngspice — auto-detected on Windows, Linux and macOS; on WSL you point at LTspice yourself (WSL notes). Install LTspice if you can: .asc schematic work needs its symbol libraries. Reading and checking netlists works with no simulator at all. The plugin and the extension fetch the server for you, so those two routes need uv installed.

If your assistant ignores it. Some clients don't show an assistant what a tool does until it picks one, so it may reach for the command line instead. Start with the name: the assistant sees every tool prefixed with it (mcp__ltspice__run_experiments), so a name carrying the domain reads as a SPICE tool even before anything else loads. That name is the key in the JSON above, or the word after claude mcp add; the plugin and the extension already use ltspice. If yours is something like sim1, rename it. Then say so outright, in your project's CLAUDE.md (or whatever your client calls it):

Always use the ltspice MCP server for any SPICE/circuit simulation, sweep, or analysis. Do not invoke ngspice or LTspice from the shell, and do not hand-parse .raw files or wrdata output.

That rule is absolute on purpose. An assistant invited to weigh it up will usually reach for the shell it already knows, which is the behaviour you are trying to correct. If you would rather it judge case by case, when to shell out instead gives the real boundary.

Using it

Once connected, you ask for circuit work in plain language. The assistant designs the circuit and decides what to measure; the server runs the simulator, parses the binary output, and returns the numbers. You and the assistant decide whether the results are acceptable.