Procedencia del repositorio: esta bifurcación pública de integración se basa en el upstream cognitohazard/ltspice-mcp etiqueta v0.5.0 (commit 4dc456000e1a436ef37a585c23ab35954a8caf04e). Las adiciones en esta rama proporcionan ejemplos de despliegue y documentación independientes de la instalación. No se ha modificado ningún código fuente del servidor upstream.

ltspice-mcp

Trabajo en curso. La funcionalidad principal es utilizable, pero cabe esperar asperezas y cambios que rompan la compatibilidad.

Un servidor MCP que conecta asistentes LLM (Claude y cualquier otro cliente MCP) con simulación de circuitos real: LTspice y ngspice, además de edición directa de esquemáticos .asc de LTspice. Los resultados de simulación vuelven como números estructurados — frecuencias de corte, sobreoscilación, margen de fase, tiempos de subida y parámetros de punto de operación de pequeña señal por dispositivo (gm, gds, vth, …) leídos por nombre — de modo que el asistente puede diseñar, verificar e iterar sobre circuitos en los mismos archivos que abres en LTspice, sin tener que analizar manualmente un rawfile. Construido sobre spicelib.

Inicio rápido

En Claude Code, instala el plugin:

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

También necesitas LTspice o ngspice en el host (detección automática en Windows, Linux y macOS; en WSL establece la ruta de LTspice explícitamente — notas de WSL). La edición de circuitos funciona sin ningún simulador. Se requiere uv; el servidor en sí se obtiene de PyPI en el primer uso.

Instalación manual (cualquier cliente MCP)

Instala el servidor y luego apunta tu cliente hacia él:

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

Claude Code — un comando (omite -s project para instalarlo globalmente):

claude mcp add -s project ltspice -- ltspice-mcp

Otros clientes — Claude Desktop, Cursor, Windsurf, Gemini CLI, Continue, Cline, Zed y otros — añade esta estrofa mcpServers al archivo de configuración MCP del cliente (cada cliente documenta su propia ruta):

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

Se requiere Python 3.11+. Verifica con ltspice-mcp --help. El mismo servidor también se publica bajo dos nombres de alias — circuit-mcp y ngspice-mcp — de modo que uvx circuit-mcp / uvx ngspice-mcp son equivalentes directos de uvx ltspice-mcp si uno de esos nombres te resulta más reconocible.

Los clientes web (claude.ai, ChatGPT) necesitan un puente stdio→HTTP como mcp-proxy — solo expongas este servidor en una red que controles por completo, ya que escribe archivos y lanza procesos dentro de allowed_paths.

También está disponible una extensión para Claude Desktop: compila el .mcpb en packaging/mcpb/ y arrástralo sobre Claude Desktop para una instalación con un solo clic y un selector de carpetas nativo para tu directorio de circuitos. Al igual que el plugin, envuelve el paquete de PyPI y necesita uv y un simulador en el host (no incluye LTspice ni ngspice).

Related MCP server: ltspice-mcp

Cómo usarlo

Una vez conectado, pides trabajo de circuitos en lenguaje natural. El asistente diseña el circuito y decide qué medir; el servidor ejecuta el simulador, analiza la salida binaria y devuelve los números. Informa de lo que produjo la ejecución, incluidas las advertencias del propio simulador, y deja en manos tuyas y del asistente la decisión de si un resultado es bueno.

"Polariza esta etapa de fuente común con NMOS en saturación a la corriente de drenaje objetivo e informa de gm/ID."

El asistente escribe la netlist, resuelve el punto de polarización en LTspice y lee el punto de operación del dispositivo por nombre — corriente de drenaje, gm, gds, VDS frente a VDSAT para confirmar que está en saturación, y el gm/ID que los diseñadores analógicos dimensionan. Si la polarización no es correcta, ajusta la referencia de puerta o la relación W/L y vuelve a ejecutar, un par de segundos por pasada.

Otras peticiones que funcionan de la misma manera:

• "¿Cuál es la sobreoscilación y el tiempo de asentamiento de la respuesta al escalón de este regulador?" — ejecuta un análisis transitorio y mide ambos a partir de la forma de onda, además del tiempo de subida, la frecuencia de oscilación y el valor final.

• "Ejecuta un Monte Carlo de 200 ejecuciones con resistencias de 5% y dime la dispersión de la salida." — perturba los componentes en cada ejecución, simula el lote e informa de la media, la sigma y los valores en el peor caso por medición.

• "Barre la carga de 100 Ω a 10 kΩ y encuentra dónde cae la eficiencia." — barrido de parámetros con resultados por ejecución.

• "Caracteriza este NMOS: gm y gm/ID frente a VGS." — escribe un deck .dc Vgs con .save @m1[gm] @m1[id], lo ejecuta en ngspice y devuelve la tabla gm/ID como un solo CSV (sin bloque .control, sin análisis de rawfile).

• "Encuentra un MOSFET de potencia de canal N para un interruptor de lado bajo y mide la caída en estado de conducción." — busca una pieza en las librerías cargadas (find_model), la coloca en un transitorio con puerta pulsada y lee Vds(on) y la corriente de carga de los resultados .meas.

• "Construye este par diferencial como un esquemático que pueda abrir en LTspice." — coloca y cablea los componentes en un .asc real, con enrutado ortogonal y comprobaciones de colisión de pines.

• "¿Es estable este lazo?" — análisis AC de la ganancia de lazo; informa del margen de fase y de ganancia en cada cruce, no solo en el primero.

• "¿Cuál es la frecuencia de resonancia y el Q de este RLC en serie?" — ejecuta un barrido AC e informa de la frecuencia central de cada pico, su Q y el ancho de banda de −3 dB.

La advertencia viaja con el número al que afecta. Un simulador como ngspice puede imprimir "singular matrix" una vez, en lo profundo de un registro que nunca abrirías, y luego terminar la ejecución y escribir números perfectamente plausibles de todos modos — léelos a mano y nada parece fuera de lugar. Pide al servidor uno de esos números y la línea enterrada llega adjunta a él, en un campo observations justo al lado del valor, de modo que el fallo aparece donde ya estás mirando en lugar de donde es fácil pasar de largo.

Co-diseño en los mismos archivos

Todo opera sobre archivos ordinarios de LTspice y SPICE, de modo que el trabajo pasa de un lado a otro entre tú y el asistente en lugar de vivir dentro de un chat:

• Dibuja un esquemático en LTspice y luego entrégalo: "¿cuál es el punto de polarización?", "¿por qué no se mueve la salida?", "añade compensación y comprueba el margen de fase."

• O a la inversa: el asistente diseña y verifica el circuito y escribe el .asc; tú lo abres en LTspice, lo inspeccionas y lo ajustas a mano. Tus ediciones manuales son simplemente el nuevo estado del archivo — el asistente continúa desde ahí en la siguiente petición.

• Los cambios pueden fluir en cualquier dirección a mitad del diseño: ajusta un valor en la GUI y pide una re-verificación, o haz que el asistente barra un cambio que estás considerando antes de comprometerte con él.

Qué hace

Simulación y medición. Ejecuta LTspice o ngspice y analiza la salida binaria directamente. Las mediciones se calculan en el lado del servidor y se devuelven como números: dominio temporal (subida/caída, sobreoscilación, asentamiento, retardo, periodo/ciclo de trabajo/jitter, RMS, THD), dominio frecuencial (frecuencias de corte y pendiente de roll-off del filtro, ganancia y fase en cualquier frecuencia, márgenes de estabilidad, picos de resonancia con Q, ruido integrado), puntos de operación DC y resultados de directivas .MEAS, incluidos los que fallaron. Los parámetros de punto de operación de pequeña señal por dispositivo (gm, gds, vth, …) vuelven por nombre en ambos simuladores — LTspice mediante un bloque .options logopinfo añadido automáticamente al registro, ngspice mediante trazas .save @dev[param]. Lee el conjunto a lo largo de un barrido .dc como una tabla gm/ID con export_waveform, o un único punto de polarización con operating_point (dirígete a ellos como m1.gm / @m1[gm], sin análisis de rawfile).

Edición de esquemáticos y netlists. Crea y edita archivos .asc reales de LTspice — coloca componentes, cablea pines, etiqueta nets — con validación antes de escribir nada: se rechaza el cableado que colisionaría con un pin, se solaparía con una unión o iría en diagonal, y cada edición devuelve advertencias sobre pines flotantes o etiquetas colgantes. Las ediciones de una sesión se pueden revertir. Las netlists simples (.cir/.net) reciben las mismas operaciones a nivel de texto, más una pasada de validación estática que detecta tarjetas mal formadas antes de gastar una simulación.

Barridos y Monte Carlo. Barridos de parámetros multidimensionales y Monte Carlo con tolerancias por componente, variación de proceso .MODEL y desajuste de dispositivo W·L de Pelgrom. Las estadísticas por medición se agregan entre ejecuciones, y cualquier ejecución individual se puede extraer y analizar como una simulación independiente.

Trabajos y confianza. Las simulaciones se ejecutan como trabajos cancelables con tiempos de espera y un límite de concurrencia; las ejecuciones largas devuelven un ID de trabajo inmediatamente y el estado del trabajo sobrevive a un reinicio del servidor. Los resultados informan de hechos, no de veredictos: una ejecución completada lleva las advertencias del propio simulador, las mediciones que no produjeron nada y los valores extremos de nodos como observaciones estructuradas. Juzgar si un resultado es fiable se deja al modelo que lo lee.

Simuladores compatibles

Configuración

Funciona con los valores predeterminados sin más. Para personalizar, copia ltspice-mcp.example.toml a ltspice-mcp.toml; cualquier ajuste se puede sobrescribir con una variable de entorno con prefijo LTSPICE_MCP_, y --config PATH o LTSPICE_MCP_CONFIG selecciona el archivo. Opciones clave:

[simulator]
default = "ltspice"      # ltspice, ngspice, qspice, xyce (null = auto-detect)
path = ""                # explicit executable path (required on WSL)
ngbehavior = "hsa"       # ngspice compat mode; unset = spicelib default, "hsa" fixes sectioned .lib corner select

[security]
allowed_paths = ["."]    # sandbox: only these directories are accessible

[simulation]
max_parallel = 4
timeout = 300.0          # seconds

[tools]
profile = "full"         # or "agentic"

[state]
persist_jobs = true

Consulta src/ltspice_mcp/config.py para la lista completa de opciones ([analysis], [schematic], [logging], ...).

En WSL, LTspice.exe se ejecuta mediante interop de Windows (no Wine), y spicelib no puede detectarlo automáticamente a través del límite de WSL. Establece la ruta del lado de Windows explícitamente:

[simulator]
path = "/mnt/c/Program Files/ADI/LTspice/LTspice.exe"

La salida de simulación se redirige automáticamente a un directorio temporal de Windows: los resultados .MEAS de LTspice pasan por archivos .db de SQLite que fallan en rutas UNC (\\wsl.localhost\...), y sin la redirección los datos de medición desaparecen silenciosamente de los registros.

Las rutas de símbolos .asy para la edición de .asc se detectan automáticamente en Windows y WSL; sobrescríbelas con [schematic] symbol_paths o LTSPICE_MCP_SYMBOL_PATHS.

Perfiles de herramientas

El perfil agentic elimina los envoltorios de edición de netlists y la gestión de sesiones de librería — trabajo que un agente capaz hace mediante ediciones directas de archivos — y conserva el ciclo de vida de la simulación, el análisis de .raw binario, la orquestación de lotes y las herramientas de geometría .asc. El directorio skills/ (skills/ltspice/SKILL.md, skills/ngspice/SKILL.md) contiene el conocimiento de dominio que se combina con él: copia la skill relevante en la ubicación de instrucciones persistentes de tu cliente.

Dónde se ejecuta. El servidor invoca un LTspice/ngspice local y lee los archivos de circuito del disco, por lo que debe ejecutarse donde estén el simulador y los archivos. Dos configuraciones funcionan: un host MCP local (Claude Desktop, Claude Code, Cursor, Gemini CLI, Codex, …) en tu propia máquina, o un agente en la nube basado en navegador cuyo sandbox pueda instalar ngspice y registrar el servidor (verificado con Claude). LTspice es solo local (una aplicación de Windows); ngspice es de código abierto y funciona en ambos entornos. El chat web de consumo sin sandbox no tiene simulador ni acceso a archivos, por lo que no puede ejecutar este servidor directamente; conéctalo a una máquina que controles (p. ej. mcp-proxy) si quieres esa interfaz.

Bajo el capó: el bucle a nivel de herramientas

Lo que el asistente hace realmente para «diseñar un paso-bajo RC de 1 kHz y verificarlo». Escribe el netlist (R=1k, C=159.155n → fc = 1 kHz):

* rc.cir — RC low-pass
V1 in 0 AC 1
R1 in out 1k
C1 out 0 159.155n
.ac dec 50 1 1Meg
.end

y luego maneja tres herramientas:

validate_netlist(path="rc.cir")
  → OK: directives valid, element arities check out — safe to simulate

run_simulation(netlist="rc.cir")
  → {"job_id": "sim_a3f1", "status": "completed", "raw_file": ".../rc.raw", ...}

bode_metrics(raw_file=".../rc.raw", signal="V(out)", mode="filter")

y recibe escalares, no un gráfico:

{
  "signal": "V(out)",
  "filter_type": "lowpass",
  "passband_gain_db": 0.0,
  "passband_ripple_db": 0.02,
  "cutoff_low_hz": null,
  "cutoff_high_hz": 1000.4,
  "stopband_rejection_db": 59.97,
  "rolloff_slope_db_per_decade": -19.9,
  "estimated_order": 1,
  "warnings": []
}

(resumido — la respuesta completa también incluye los límites de la banda de paso y el ancho de banda de transición)

Fuera de objetivo → set_component_value, re-ejecutar, re-medir. Las simulaciones largas devuelven un ID de trabajo en lugar de bloquear; check_job/cancel_job las gestionan. Los metadatos de los trabajos persisten en sidecars por circuito ({dir}/.ltspice-mcp/jobs/ — añade .ltspice-mcp/ a tu .gitignore), y los recursos MCP (spice://results/..., spice://netlists/..., spice://config) exponen trabajos, señales, mediciones y configuración para explorar.

Cada herramienta declara anotaciones MCP (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); las herramientas que devuelven datos declaran un outputSchema para la introspección de structuredContent.

Desarrollo

uv sync                        # install runtime + dev dependencies
uv run pytest tests/ -v        # tests
uv run pyright                 # type checking
uv run ruff check src/ tests/  # lint
uv run ltspice-mcp             # run the server (stdio)

Más: docs/DESIGN.md (alcance, arquitectura, no objetivos) y docs/spice_lex.md (internals del analizador SPICE).

Licencia

GPL-3.0