Dibujar un esquema electrónico en KiCad es una mezcla rara de dos cosas: una parte pequeña de pensar el circuito y una parte enorme de trabajo mecánico — colocar cada componente en su sitio, tirar los cables sin que se crucen, poner los símbolos de masa, mover las etiquetas para que se lean, y repetirlo todo cada vez que cambias de idea. MCP-KiCad es un servidor MCP que le da a Claude la capacidad de hacer esa segunda parte por ti: le describes el circuito hablando, y te devuelve un fichero .kicad_sch de verdad, que abres en KiCad y editas como cualquier otro. El proyecto vive en github.com/unmateria/MCP-Kicad.
01 — El problema: la parte aburrida de un esquema es casi todo el trabajo
Cuando alguien monta un circuito sencillo — un temporizador con un 555, una fuente regulada con un 7805, una placa mínima con un microcontrolador — la parte interesante se resuelve en cinco minutos. Sabes que el 555 en configuración astable necesita dos resistencias y un condensador, sabes que la frecuencia sale de una fórmula, y sabes que hay que poner un condensador de 10 nF en la patilla de control. Eso es el circuito, y es lo que uno tiene en la cabeza.
Lo que viene después es donde se va el tiempo. Abres KiCad, buscas cada símbolo en la librería, lo colocas, lo giras, lo mueves un poco porque no cuadra con el siguiente, tiras un cable, ves que pasa por encima de otro, lo rehaces, pones un símbolo de masa por cada patilla que va a masa, colocas las etiquetas de referencia que salen encima del componente, las mueves una a una… y cuando terminas te das cuenta de que querías cambiar una resistencia de sitio, y media hoja se descoloca.
Ese trabajo no es difícil. Es tedioso, repetitivo y perfectamente mecánico, que es exactamente la definición de algo que debería hacer una máquina. Y aquí es donde entra la parte interesante: los modelos de lenguaje actuales entienden perfectamente qué circuito quieres. Lo que no saben hacer, por su cuenta, es dibujarlo bien.
02 — Qué es un MCP y por qué cambia las reglas
MCP son las siglas de Model Context Protocol, un estándar publicado por Anthropic para que los asistentes de IA puedan comunicarse con programas que corren en tu ordenador. La idea de fondo es simple pero cambia mucho las cosas.
Sin MCP, la interacción con una IA es de ida y vuelta manual: le pides algo, te contesta con un texto, y tú copias ese texto a donde haga falta. Si le pides que te genere un fichero de KiCad, te dará un montón de paréntesis que tendrás que pegar en un archivo, guardar, abrir en KiCad y rezar para que no dé error. Cuando falla — que falla — vuelves a empezar.
Con MCP, el asistente tiene un canal directo con un programa que sabe hacer cosas concretas. Ese programa (el servidor MCP) se ejecuta en tu máquina y expone una lista de herramientas: funciones bien definidas que la IA puede llamar cuando lo considere. La IA no escribe el fichero: pide que se hagan operaciones y el servidor las ejecuta de verdad, con código normal y corriente, comprobando lo que hace.
Esa distinción es la clave de todo lo que viene después. Un modelo de lenguaje es buenísimo decidiendo qué componentes hacen falta y cómo se conectan entre sí. Es malísimo calculando coordenadas en milímetros y previendo si el cable que va del pin 3 al pin 7 va a chocar con el cuerpo de un integrado. Así que el reparto de tareas se hace solo: el modelo decide el circuito, el servidor calcula la geometría. Y el servidor, al ser código normal, puede comprobar su propio trabajo antes de entregarlo.
03 — Qué hace MCP-KiCad exactamente
Le pides un circuito en lenguaje normal. Claude escribe una descripción estructurada del mismo y llama a una herramienta, compile_schematic, que convierte esa descripción en un esquema terminado. La conversación se parece a esto:
Tú: Hazme un astable con un 555 que parpadee a 1 Hz, alimentado a 5 V.
Claude: [consulta los nombres reales de los pines del NE555 en tu librería,
escribe el diseño y lo compila]
Listo — 7 componentes, ERC limpio, netlist verificada.
Aquí tienes la vista previa.
El resultado no es una imagen ni un dibujo: es un fichero .kicad_sch real que abres en KiCad como cualquier otro, con su netlist correcta, listo para pasarlo a placa. Puedes seguir editándolo a mano, añadirle cosas, o pedirle a Claude que lo modifique y lo recompile.
Además de compilar circuitos enteros, el servidor expone otras treinta y dos herramientas para trabajar sobre esquemas ya existentes: buscar componentes en tus librerías de KiCad, consultar los pines reales de un símbolo, leer un esquema y contarte cómo está conectado, mover cosas, pasar el ERC, exportar a PDF o a imagen. En la práctica casi todo se hace con compile_schematic; el resto están para inspeccionar y para reparar.
04 — Por qué casi todos los intentos con IA salen mal
Conseguir que un modelo de lenguaje escupa un fichero .kicad_sch es fácil. El problema es que el resultado es casi siempre basura, y merece la pena entender por qué, porque explica todas las decisiones de diseño de este proyecto.
Los fallos visibles son los que uno espera: cables que cruzan por encima de otros cables que no tienen nada que ver, cables que atraviesan de lado a lado el cuerpo de un integrado, textos de referencia amontonados encima de los componentes, símbolos solapados. Todo eso es feo, se ve a simple vista, y se puede arreglar mirando el dibujo.
Pero hay un fallo mucho peor, y es el que da miedo: el cortocircuito silencioso. En KiCad, un cable que termina exactamente sobre la patilla de un componente queda conectado a ella. Si el modelo calcula mal una coordenada y el extremo de un cable cae justo encima de un pin que pertenece a otra señal, KiCad une las dos señales en una sola. Y aquí viene lo malo: el resultado es perfectamente coherente. No hay ningún cruce raro, no hay nada que se vea torcido, el fichero es válido, el ERC no protesta necesariamente. Simplemente el esquema ha dejado de ser el circuito que pediste, y no hay nada en el dibujo que lo delate.
Ese es el motivo por el que no basta con «revisar que se vea bien». Un esquema puede verse impecable y estar mal. Hace falta comprobar otra cosa.
05 — Las garantías: por qué este esquema sí te lo puedes creer
La decisión de fondo del proyecto es que al modelo no se le pide que dibuje. Se le pide que describa: qué componentes hay y qué patillas van conectadas entre sí. En esa descripción no aparece ni una sola coordenada. Las posiciones se expresan anclando un componente al pin de otro, a un número entero de celdas de 2,54 mm de distancia — que es, por cierto, como piensa un humano cuando coloca piezas en una rejilla.
A partir de ahí trabaja el compilador, que es código normal, determinista y verificable. Y antes de que el fichero llegue a tus manos pasa por varios filtros:
- Una barrera geométrica revisa cada segmento de cable dibujado. Si un cable cruza otra señal, corta el cuerpo de un símbolo, se solapa con otro en la misma línea o pasa por encima de una patilla que no le corresponde, ese cable se borra y la conexión se rehace con etiquetas de red. Eléctricamente es idéntico; estéticamente es peor. Pero nunca es mentira.
- La netlist se verifica reconstruyéndola. Una vez terminado el fichero, se vuelve a leer desde cero, se traza qué está conectado con qué, y se compara con lo que pediste — en los dos sentidos. Que estén todas las conexiones que declaraste, y que no haya ninguna que no declararas. Si algo no cuadra, la compilación falla y te lo dice, en lugar de entregarte un esquema con buena pinta.
- Los símbolos de alimentación se comprueban por contacto físico, no por nombre. KiCad une todas las masas por el nombre
GND, así que un símbolo de masa que se haya quedado suelto en mitad de la hoja parece conectado si solo miras los nombres. Se verifica que toque de verdad la patilla que dice tocar. - Y al final manda KiCad. Se ejecuta
kicad-cli— la herramienta oficial de línea de comandos — para pasar el ERC, y el informe viene con el resultado.
Hay un detalle de implementación que merece la pena mencionar porque es de sentido común y casi nadie lo respeta: los ficheros de KiCad se leen y se escriben con un analizador sintáctico de verdad, nunca buscando y reemplazando texto. Un .kicad_sch es un árbol de paréntesis (una S-expresión, como el Lisp). Manipularlo con expresiones regulares funciona hasta que un día no funciona y te destroza el fichero. Aquí se parsea entero, se modifica el árbol en memoria y se vuelve a escribir.
La consecuencia práctica de todo esto es que el .kicad_sch se trata como un producto de compilación, igual que un ejecutable: no se edita a mano, se edita la descripción y se vuelve a compilar. Si quieres cambiar el circuito, cambias dos líneas de texto y lo recompilas entero en un segundo, en vez de descolocar media hoja arrastrando componentes con el ratón.
06 — Instalación paso a paso
Hace falta tener KiCad 10 instalado, porque el servidor se apoya en kicad-cli, la herramienta de línea de comandos que viene con él, para pasar el ERC y para generar las vistas previas. Y hace falta Claude Desktop o Claude Code. Nada más: el servidor es un único ejecutable que no depende de nada externo.
Hay dos formas de instalarlo.
La fácil, de un clic. Te descargas el fichero mcp-kicad.mcpb de la página de descargas y le haces doble clic. Claude Desktop lo instala como extensión: no hay que editar ningún fichero de configuración ni escribir rutas a mano. Ese mismo fichero lleva dentro las versiones de Windows, macOS y Linux, así que sirve para cualquier sistema.
La manual, con el ejecutable suelto. Si prefieres controlar dónde vive el programa, en la página de releases están los binarios sueltos:
mcp-kicad-windows-amd64.exe— Windowsmcp-kicad-linux-amd64— Linux en PCmcp-kicad-linux-arm64— Linux en ARM (Raspberry Pi y similares)mcp-kicad-darwin-arm64— macOS con Apple Siliconmcp-kicad-darwin-amd64— macOS con Intel
Lo pones donde quieras, por ejemplo en C:\Tools\. En Linux y macOS hay que darle permiso de ejecución con chmod +x, y en macOS además desbloquearlo la primera vez con xattr -d com.apple.quarantine, porque el binario no está firmado.
No hace falta configurar nada. El servidor busca KiCad solo: en Windows mira en C:\Program Files\KiCad\, en Linux en /usr/bin y /usr/local/bin, en macOS dentro de /Applications, y si no lo encuentra ahí prueba el PATH. Solo si tienes la instalación en un sitio raro tendrás que crear un config.ini junto al ejecutable, y el repositorio trae un ejemplo comentado.
07 — Conectarlo a Claude Desktop
Si has usado el instalador de un clic, esto ya está hecho y puedes saltarte la sección. Si has cogido el ejecutable suelto, hay que decirle a Claude Desktop dónde está. Se edita su fichero de configuración, que en Windows vive en %APPDATA%\Claude\claude_desktop_config.json, en macOS en ~/Library/Application Support/Claude/ y en Linux en ~/.config/Claude/. Si no existe, se crea:
{
"mcpServers": {
"kicad": {
"command": "C:\\Tools\\mcp-kicad.exe",
"args": []
}
}
}
Dos avisos que ahorran disgustos. El primero: en JSON, las barras invertidas de Windows van dobladas — C:\\Tools\\, no C:\Tools\. Poner una sola es, con diferencia, el motivo más habitual de que el servidor no arranque y no sepas por qué. El segundo: después de guardar hay que cerrar Claude Desktop del todo y volver a abrirlo. Recargar la ventana no vale, porque el servidor se lanza como proceso hijo y solo arranca en un reinicio completo.
En Claude Code es una sola orden:
claude mcp add kicad -- /ruta/a/mcp-kicad
Para comprobar que funciona, pídele a Claude: «usa get_project_info para comprobar la configuración de KiCad». Debería contestarte con la ruta de kicad-cli que ha detectado, los directorios de librerías y la carpeta donde va a dejar los ficheros generados.
08 — Cómo se usa de verdad
Se describe el circuito y ya está. Cuanto más concreto seas en lo que te importa — tensión de alimentación, referencias concretas que quieras usar, valores que ya tengas decididos — menos tendrá que suponer. Cosas que funcionan bien:
Diséñame una fuente regulada de 5 V a partir de 12 V de entrada con un LM7805, con desacoplo a la entrada y a la salida y un LED de encendido. Hazme una placa mínima con un ATmega328P: cristal de 16 MHz con sus condensadores de carga, pull-up en el reset, conector ICSP y desacoplo en los dos pines de alimentación. Monta un multivibrador astable de dos transistores que haga parpadear dos LEDs a unos 2 Hz.
Y una vez que tienes el esquema, la conversación sigue: «enséñamelo» genera una vista previa, «expórtalo a PDF» te lo saca en PDF vectorial, «pasa el ERC» ejecuta el chequeo eléctrico de KiCad y te explica las violaciones si las hay, y «acerca los condensadores de desacoplo a U1 y recompila» hace exactamente eso. Como la fuente del diseño es texto, revisar sale baratísimo: cambiar de idea cuesta una frase, no media hora de arrastrar cosas.
09 — Qué hay por debajo: la fuente del diseño
Esto no hace falta tocarlo nunca, pero merece la pena verlo porque explica de dónde sale la estabilidad del resultado. Lo que Claude escribe realmente es un documento como este:
{
"version": 1,
"project": "led_18650",
"blocks": [
{
"name": "led",
"symbols": [
{ "ref": "BT1", "lib": "Device:Battery_Cell", "value": "18650" },
{ "ref": "R1", "lib": "Device:R", "value": "100", "rot": 90,
"place": { "pin": "1", "at": "BT1.+", "dir": "up", "cells": 1 } },
{ "ref": "D1", "lib": "Device:LED", "value": "LED_RED", "rot": 90,
"place": { "pin": "A", "at": "R1.2", "dir": "right", "cells": 3 } }
]
}
],
"nets": {
"VBAT": ["BT1.+", "R1.1"],
"_ANODE": ["R1.2", "D1.A"],
"GND": ["D1.K", "BT1.-"]
},
"power_nets": { "GND": "power:GND" }
}
Fíjate en lo que no hay: milímetros. El primer componente de cada bloque es el ancla, y cada uno de los siguientes se cuelga de una patilla de otro que ya está colocado, a tantas celdas de rejilla en tal dirección. «El pin 1 de R1 va un paso por encima del positivo de la batería.» Eso es todo.
Esa manera de expresar las posiciones es la que hace que el resultado sea estable. Si le pidieras coordenadas a un modelo de lenguaje, cada recompilación te daría un dibujo ligeramente distinto y con errores distintos. Anclando pin a pin, el esquema se mantiene en la rejilla de 2,54 mm y las relaciones espaciales se conservan por mucho que se reordenen las cosas. Y como es texto plano, se puede versionar en Git, comparar dos versiones o generar variantes de una placa cambiando cuatro valores.
10 — Cuatro cosas que KiCad no hace como yo creía
Este apartado es para quien esté peleándose con algo parecido, porque cada una de estas cuatro me costó tiempo. Las cuatro estaban escritas en el código como certezas, y las cuatro resultaron ser falsas al medirlas. Ninguna se descubrió razonando: todas salieron de exportar la netlist y los gráficos con kicad-cli y mirar qué había hecho KiCad de verdad.
- Un cable que cruza la punta de una patilla por el medio no conecta con ella. Uno que termina ahí, sí. Esa asimetría es exactamente el cortocircuito silencioso del que hablaba antes, y es lo que obliga a comprobar los extremos de cada segmento.
- El espejado se aplica después del giro, reflejando la colocación ya terminada, no antes. Da igual a 0° y 180°, y da resultados distintos a 90° y 270°. Yo lo tenía al revés, y el test que lo comprobaba estaba escrito con mi propia convención equivocada, así que confirmaba el error alegremente.
- Lo que orienta el texto de una etiqueta es la justificación, no el ángulo. El ángulo solo elige el eje. Girar una etiqueta sin tocar la justificación no mueve absolutamente nada — y yo tenía una función entera dedicada a girar etiquetas que llevaba tiempo sin hacer nada en absoluto.
- En un SVG exportado por KiCad, los elementos de texto son invisibles. Están ahí con transparencia total, como ayudas de selección. Lo que se dibuja de verdad son los trazos vectoriales de otro grupo. Si mides las cajas de texto para saber si dos rótulos se solapan, estás midiendo una cosa que nadie ve.
La moraleja, que vale para cualquier proyecto parecido: cuando dudes de qué hace una herramienta, mídelo. No lo razones, no lo recuerdes, no lo deduzcas de la documentación. Ejecútalo y mira el resultado.
11 — Lo que no hace
Conviene ser claro con esto, porque el nombre puede llevar a engaño.
No hace nada de PCB. Ni colocación de huellas, ni ruteo de pistas, ni Gerbers para fabricación. Y no es un descuido: es deliberado. Una placa hecha a partir de un esquema del que no te puedes fiar no vale absolutamente nada, así que prefiero no tocar el cobre hasta que la parte de esquemas esté sólida de verdad. Es el siguiente paso natural del proyecto, y la receta que ha funcionado en el esquema — descripción declarativa, compilación determinista, barrera geométrica y verificación contra la herramienta oficial — debería aplicarse igual a la placa.
No se inventa componentes. Usa las librerías de símbolos que ya tienes instaladas con KiCad, que son miles. Si necesitas algo que no está, puede descargarlo de SnapEDA si le das una clave de API, pero no fabrica símbolos de la nada.
No es un simulador y no te va a decir si tu circuito es buena idea. Dibuja lo que le describes. Si le pides una fuente sin condensador de salida, te la dibuja sin condensador de salida. El criterio de diseño sigue siendo tuyo.
Y hay asperezas conocidas, que prefiero contar a que las descubras tú. En hojas muy densas los textos todavía se solapan a veces: cada etiqueta se lleva a la posición con menos solape disponible, pero en un esquema apretado la mejor posición posible sigue tocando algo. El compilador te dice exactamente qué ha quedado solapado y cuánta separación haría falta para resolverlo. Y algunas conexiones salen como etiqueta en vez de como cable, que es la barrera geométrica haciendo su trabajo: prefiere una etiqueta correcta a un cable bonito y mentiroso.
Por último, la plataforma en la que está probado de verdad es Windows. Las versiones de Linux y macOS compilan y detectan KiCad correctamente en cada sistema, pero no las he ejecutado sobre hardware real, así que si las usas y algo falla, cuéntamelo.
12 — Para quién es esto
Pensando en quién le puede sacar partido de verdad:
- El aficionado que sabe de electrónica pero pelea con KiCad. Tienes clarísimo el circuito que quieres, pero el programa te resulta hostil y cada esquema te lleva una tarde. Aquí describes el circuito y sale dibujado; y como el fichero es normal y corriente, puedes seguir editándolo a mano donde no te guste.
- El que hace muchas variantes del mismo diseño. Si montas placas parecidas cambiando cuatro valores, tener el circuito en un fichero de texto que se compila es una diferencia enorme frente a duplicar proyectos y editar a mano cada copia.
- El que está aprendiendo. Poder pedir «un divisor de tensión con realimentación» y ver cómo queda dibujado en condiciones, con sus masas y sus etiquetas puestas donde toca, es una manera rápida de aprender convenciones de esquemático.
- Y quien tenga curiosidad por el problema en sí. El asunto de fondo — cómo conseguir que un modelo de lenguaje produzca algo geométricamente correcto y verificable, en vez de algo que parece correcto — es interesante mucho más allá de KiCad. El código está entero en GitHub, comentado y con las decisiones explicadas.
Lo que no es: un sustituto de saber electrónica. Sigues teniendo que decidir el circuito, elegir los valores y entender qué estás montando. Lo que desaparece es la fricción entre tener el circuito en la cabeza y tenerlo dibujado en condiciones, que en mi caso era la parte que más pereza me daba de cualquier proyecto.
El proyecto está en github.com/unmateria/MCP-Kicad, con las descargas para todos los sistemas en su página de releases. Si lo pruebas y algo te chirría — una convención de dibujo que esté mal, un circuito que salga raro — cuéntamelo, que es justo lo que no puedo comprobar yo solo.