¿Un servidor MCP de Cursor muestra un punto rojo, una lista de herramientas vacía o fallos silenciosos? Lee los logs, corrige los errores de PATH y de JSON, arregla los permisos de los tokens de GitHub, los puertos de Figma y los errores del navegador de Playwright, y prueba cualquier servidor con el inspector para que tu agente vuelva a usar sus herramientas.
Pegas un bloque de servidor en mcp.json, reinicias Cursor y el panel de ajustes muestra un punto rojo, o un punto verde junto a una lista de herramientas vacía. El agente sigue como si tu servidor de GitHub, Figma o Playwright nunca hubiera existido. Ese silencio es lo que hace tan frustrante depurar MCP: nada se rompe, nada se explica y, normalmente, la solución es una línea que no ves desde la pantalla de ajustes.
Este artículo repasa los fallos que hay detrás de los servidores MCP de Cursor que no funcionan, en el orden que más rápido los encuentra. La primera sección recoge cuatro comprobaciones que valen para cualquier servidor. Después vienen las trampas concretas de GitHub, Figma y Playwright, luego los límites de herramientas, las solicitudes de aprobación y una forma de probar cualquier servidor fuera del editor. Cada solución indica su síntoma, así que puedes ir directo a la que coincide con lo que ves en pantalla.
💡 Nota sobre las versiones: Cursor y los tres servidores cambian rápido. Las etiquetas de los menús, los flags y las URL varían entre versiones, así que, si un nombre en tu pantalla no coincide con esta página, fíate de lo que muestre tu log antes que de este artículo.
Antes de culpar a un solo servidor, descarta los problemas que los rompen todos a la vez. En la mayoría de los casos, uno de estos cuatro es el culpable.
Abre el panel Output de Cursor y elige el canal de logs de MCP en el desplegable. La etiqueta exacta cambia entre versiones, pero está junto a los demás canales de Output. El log muestra el comando que ejecutó Cursor y lo que el servidor escribió en stderr antes de detenerse. Tres mensajes explican la mayoría de los fallos:
spawn npx ENOENT: Cursor no encuentra el ejecutable. Ve a la solución de PATH más abajo.MCP error -32000: Connection closed: el proceso arrancó y se cerró de inmediato, normalmente por un token que falta, un argumento incorrecto o un fallo al iniciarse.Request timed out: el servidor está vivo pero va lento, a menudo porque npx está descargando un paquete en su primera ejecución.💡 Consejo: Copia las últimas 30 líneas del log antes de cambiar nada. Cada reinicio sobrescribe las pruebas que necesitas si tu primera suposición es errónea.
Cursor lee dos archivos: ~/.cursor/mcp.json para todos los proyectos, y .cursor/mcp.json dentro del proyecto actual. Ambos necesitan JSON estricto, lo que significa sin comentarios, sin comas finales y solo con comillas rectas. Una coma mal puesta puede hacer que Cursor ignore todo el archivo sin un mensaje claro.
{
"mcpServers": {
"github": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}" }
}
}
}
Para revisar un archivo, ejecuta node -e "JSON.parse(require('fs').readFileSync('.cursor/mcp.json','utf8'))". No imprime nada cuando el JSON es válido y, si no lo es, indica la posición exacta del error. Las versiones recientes de Cursor expanden los marcadores ${env:NAME} con variables de tu entorno. Si tu versión pasa el texto literal, el servidor recibe un token falso y falla con un error de autenticación, así que prueba con un valor real en un archivo local que no subas al repositorio.
Cursor abierto desde el dock, el menú Inicio o Spotlight no lee tu perfil de shell. Las herramientas instaladas con nvm, fnm o Homebrew pueden ser invisibles para él aunque funcionen en tu terminal, y el log muestra spawn npx ENOENT. Sustituye el comando simple por una ruta absoluta. Ejecuta which npx en macOS y Linux, o where npx en Windows, y pega el resultado:
"command": "/Users/you/.nvm/versions/node/v22.11.0/bin/npx"
Windows añade una segunda trampa. npx es un script de .cmd, y algunos lanzadores no pueden ejecutarlo directamente. Envuélvelo en cmd y pasa siempre -y, para que npx nunca se detenga a pedir permiso para una descarga que nadie puede ver:
"command": "cmd",
"args": ["/c", "npx", "-y", "@playwright/mcp@latest"]
Editar el archivo no siempre reinicia un servidor en marcha. Desactiva y vuelve a activar el servidor en Cursor Settings, Tools & MCP (las versiones antiguas lo muestran simplemente como MCP), o ejecuta Developer: Reload Window desde la paleta de comandos. Si el estado anterior persiste, cierra Cursor por completo. Un proceso que quedó abierto puede ocupar un puerto o un perfil de navegador y hacer que un inicio nuevo falle por motivos que no tienen nada que ver con tu configuración.
GitHub mantiene su propio servidor en el repositorio github/github-mcp-server, en dos formas: una local que se ejecuta en Docker y otra alojada. Si tu configuración todavía apunta al antiguo paquete npm @modelcontextprotocol/server-github, cámbiala. Ese paquete está obsoleto en favor del servidor oficial de GitHub, y el nuevo recibe las correcciones y las herramientas nuevas.
El fallo más común de GitHub es un servidor que conecta bien mientras cada llamada a una herramienta devuelve 401, 403 o un 404 desconcertante. Un 404 en un repositorio privado suele significar que el token no puede verlo, no que el repositorio no exista. Comprueba cuatro cosas:
repo, y read:org si consultas datos de la organización.💡 Consejo: Prueba el token fuera de Cursor con
curl -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user. Si devuelve un perfil en JSON, el token funciona y el problema está en la configuración.
El servidor local necesita Docker. Tres líneas del log apuntan a esto: docker: command not found, Cannot connect to the Docker daemon y un tiempo de espera agotado mientras se descarga la imagen. Inicia primero Docker Desktop y luego ejecuta docker pull ghcr.io/github/github-mcp-server una vez en una terminal, para que Cursor nunca espere a la primera descarga. Revisa también el flag -i en tus argumentos. Mantiene stdin abierto y, sin él, el servidor se cierra en cuanto arranca. Detrás de un proxy corporativo, la descarga desde ghcr.io puede fallar aunque las demás descargas de Docker funcionen.
Si Docker te da guerra sin parar, cambia al servidor alojado. No necesita Docker, ni Node, ni configurar PATH:
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${env:GITHUB_TOKEN}" }
}
Un 401 apunta al token, y un tiempo de espera agotado apunta a un proxy o a un firewall. El servidor de GitHub también expone muchas herramientas, lo que importa para los límites que se explican más adelante. Su README documenta los conjuntos de herramientas, que se configuran con la variable de entorno GITHUB_TOOLSETS en el servidor local o con una cabecera X-MCP-Toolsets en el remoto, así que puedes cargar solo repos, issues y pull_requests y dejar el resto fuera.
Figma ofrece dos vías. La primera es un servidor local que se ejecuta dentro de la aplicación de escritorio de Figma. La segunda es un servidor alojado con inicio de sesión en el navegador. Los nombres, los puertos y las rutas han cambiado desde el lanzamiento, así que confírmalos en la documentación actual de Figma cuando un paso de abajo no coincida con lo que ves. Los fallos se agrupan en tres categorías.
El servidor local vive dentro de la aplicación de escritorio, no en la pestaña del navegador. La aplicación debe estar abierta, debe haber un archivo de diseño cargado y el servidor MCP debe estar activado desde el panel de inspección de Dev Mode o desde las preferencias, según tu versión. Figma también ha vinculado el acceso MCP a planes de pago y a ciertos tipos de licencia, así que comprueba que tu licencia lo permite antes de pasar una hora con la configuración. Cuando la aplicación está cerrada, Cursor muestra una conexión rechazada, que parece un servidor roto pero en realidad es un proceso que falta.
El servidor local escucha en el puerto 3845. Las versiones nuevas responden en /mcp, y las antiguas usaban /sse. Una configuración que todavía lleva la ruta antigua recibe un 404 o un handshake rechazado:
"figma": { "url": "http://127.0.0.1:3845/mcp" }
Usa 127.0.0.1 en lugar de localhost. En algunos equipos, localhost se resuelve primero por IPv6, y un servidor enlazado a IPv4 rechaza esa ruta. Si el puerto está ocupado, averigua quién lo usa con lsof -i :3845 en macOS y Linux, o netstat -ano | findstr 3845 en Windows. Para la vía alojada, apunta Cursor a https://mcp.figma.com/mcp y termina el inicio de sesión en el navegador cuando te lo pida. ¿Cerraste la pestaña del inicio de sesión sin querer? Desactiva y vuelve a activar el servidor para reiniciar el proceso.
Las herramientas locales actúan sobre tu selección actual o sobre un enlace a un marco. Si le pides al agente que "construya esta pantalla" sin nada seleccionado, recibe una respuesta vacía, lo que parece un servidor muerto aunque la conexión esté perfectamente sana. Selecciona un marco en Figma o pega el enlace del marco en tu prompt. Si un marco muy grande agota el tiempo de espera, selecciona una sección más pequeña y construye la pantalla por partes.
💡 Consejo: Tras cada cambio en Figma, hazle primero al agente una pregunta muy simple, como el nombre del marco seleccionado. Si la respuesta es correcta, has comprobado que toda la cadena funciona antes de pedir una maquetación completa.
La opción habitual es @playwright/mcp de Microsoft, y la configuración mínima es corta:
"playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
Como lanza un navegador real, falla de más maneras que los otros dos servidores.
Una línea del log como Executable doesn't exist o Chromium distribution 'chrome' is not found significa que no hay instalado ningún navegador compatible. Por defecto, el servidor pide Chrome. Instala Chrome de la forma habitual o ejecuta npx playwright install chrome en una terminal. El servidor también incluye una herramienta browser_install, así que puedes pedirle al agente que la llame cuando aparezca este error. Para usar otro motor, añade --browser firefox o --browser webkit a args e instala ese motor de la misma manera.
La sesión por defecto usa una carpeta de perfil persistente. Una segunda ventana de Cursor, o un proceso de Chrome que quedó de una ejecución fallida, bloquea esa carpeta, y el log indica que el navegador ya está en uso y sugiere el flag --isolated. Cierra los procesos sobrantes o añade el flag para que cada sesión empiece con un perfil nuevo en memoria:
"args": ["@playwright/mcp@latest", "--isolated"]
Las sesiones aisladas olvidan los inicios de sesión. Si necesitas seguir conectado a un sitio, dale al servidor un perfil dedicado con --user-data-dir.
Los contenedores, WSL, las sesiones SSH y las máquinas de CI suelen no tener pantalla, así que añade --headless. Como último recurso, dentro de un contenedor que se ejecuta como root, --no-sandbox elimina el error del sandbox, a costa de un aislamiento más débil. Revisa también la versión de Node, porque el paquete espera Node 18 o posterior. Por último, el primer arranque descarga el paquete y lanza un navegador, lo que puede superar el tiempo de espera de Cursor. Ejecuta npx @playwright/mcp@latest --help una vez en una terminal para precargar la caché, y el siguiente inicio desde Cursor será rápido.
Algunos fallos dejan todos los puntos en verde. El servidor está conectado y el agente nunca lo usa. Dos causas explican la mayoría de estos casos.
Demasiadas herramientas cargadas. Cursor ha avisado cuando el número total de herramientas de todos los servidores crece mucho, con un límite histórico de alrededor de 40 herramientas que puede variar en tu versión. Solo GitHub puede exponer decenas. Cuando el total supera ese umbral, las herramientas de algunos servidores pueden no llegar nunca al modelo. Desactiva los servidores que no necesites en el proyecto actual, usa los conjuntos de herramientas de GitHub y mantén ligeros los archivos .cursor/mcp.json a nivel de proyecto.
Modo incorrecto o una aprobación sin responder. Las herramientas de MCP funcionan en modo Agent. En modo Ask, el modelo no puede llamarlas. Por defecto, cada llamada pide aprobación, y si pasas de largo el aviso, el chat parece congelado. Aprueba la llamada o activa la ejecución automática para los servidores en los que confíes. Abre también la entrada del servidor y confirma que no has desactivado herramientas individuales.
💡 Consejo: Un buen prompt de prueba es explícito: "Usa la herramienta de playwright para abrir example.com y dime el título de la página". Nombrar el servidor elimina cualquier duda sobre qué herramienta debe elegir el modelo.
Ejecuta el MCP Inspector. El inspector oficial arranca cualquier servidor y lista sus herramientas sin que Cursor interfiera:
npx @modelcontextprotocol/inspector npx -y @playwright/mcp@latest
Si el servidor conecta y lista herramientas allí pero no en Cursor, el problema está en el entorno de Cursor: PATH, variables de entorno o el archivo de configuración. Si también falla en el inspector, el problema está en el servidor o en tu equipo, y el texto del error normalmente lo indica.
Deja que un LLM lea los logs. Los logs largos son tediosos, y un modelo de lenguaje localiza rápido la única línea relevante. Con Claude Sonnet 5 en PicassoIA:
REDACTED.GPT 5.6 Sol es una buena segunda opinión para los casos difíciles, y Gemini 3.5 Flash sirve para una primera pasada rápida de logs muy largos. Todo lo que pegues en un modelo alojado sale de tu equipo, así que oculta primero los secretos, siempre.
| Síntoma | Causa probable | Solución |
|---|---|---|
spawn npx ENOENT | Cursor no ve Node en el PATH | Usa la ruta absoluta a npx |
Connection closed justo después de arrancar | Token que falta o fallo al iniciarse | Lee stderr en el log y revisa los valores del entorno |
| Herramientas listadas, las llamadas devuelven 401 o 403 | Token de GitHub caducado o con permisos insuficientes | Vuelve a crear el token y autorízalo para SSO |
docker: command not found | Docker no está instalado o está detenido | Inicia Docker Desktop y descarga la imagen previamente |
| Figma rechaza la conexión | Aplicación de escritorio cerrada o servidor MCP desactivado | Abre un archivo de diseño y activa el servidor |
| Figma devuelve 404 | Ruta antigua /sse | Cambia la URL a /mcp |
| Ejecutable de Playwright no encontrado | No hay ningún navegador compatible instalado | Ejecuta npx playwright install chrome |
| El navegador de Playwright ya está en uso | Carpeta de perfil bloqueada | Cierra los procesos sobrantes o añade --isolated |
| Punto verde, el agente ignora las herramientas | Demasiadas herramientas o modo Ask | Reduce los servidores y cambia al modo Agent |
Cuando tus servidores funcionen, MCP resulta interesante mucho más allá del código. PicassoIA también expone sus modelos de generación a través de su propia conexión MCP y de su API para desarrolladores, con cuatro modelos: PicassoIA Image, Image Editor Pro, PicassoIA Video y Seedance 2.5 Lite para video con audio. Configuras la conexión desde la página MCP de tu cuenta en picassoia.com/en/mcp/accounts, y se comporta como cualquier otro servidor en Cursor, así que todas las comprobaciones anteriores también le son aplicables.
Hay un límite que conviene conocer cuando los trabajos parecen estancados: una cuenta ejecuta hasta 5 predicciones a la vez, compartidas entre todas tus credenciales y conexiones MCP. Un sexto trabajo espera, y desde el editor eso puede parecer un servidor bloqueado.
Aun así, no necesitas un servidor MCP para empezar. Abre la aplicación web, escribe un prompt y verás un resultado en segundos:
Elige una necesidad real de tu último proyecto, como una imagen principal para un README, una cabecera para una entrada de blog o una foto de producto de muestra para una demo, y genera tres versiones. Compáralas, cambia un detalle cada vez y quédate con la que encaje. Abre Picasso IA, escribe tu primer prompt y mira cómo podría ser tu próximo proyecto.
Elige tu idioma
