Un daemon MCP compartido por máquina en lugar de una copia por sesión
Levantar un único servidor MCP en loopback en vez de una copia por sesión ahorra memoria, sockets y locks, pero no tokens. Un watchdog mal pensado tumba todas las sesiones.
Registrar un servidor MCP como stdio hace que el cliente lo arranque de cero en cada sesión. Diez sesiones de Claude en paralelo son diez copias del mismo servidor, diez procesos, diez sockets contra el mismo upstream y diez dueños del mismo lock. La alternativa es levantar el servidor una sola vez, atado a 127.0.0.1, y apuntar todos los clientes a su URL HTTP/SSE. El autor de mcp-daemon-diet lo midió en su portátil y publica la receta, plantillas de arranque automático y el aviso que más le costó aprender: un watchdog ingenuo sobre el daemon compartido provoca caídas peores que las que arregla.
Lo que cuesta una copia por sesión
Entre el 1 y el 3 de agosto de 2026 midió varias sesiones de Claude Code contra unos pocos servidores MCP. Telegram sumaba unas 9 copias y 2,7 GB de RSS; mongodb, 26 copias y 3,0 GB; n8n, 15 copias y 2,9 GB; whatsapp, 15 copias y 1,5 GB; y los wrappers de lanzamiento (npx, cmd), unas 60 copias y 5 GB. El propio autor avisa de que sumar RSS engaña: las copias comparten páginas de código y el sistema operativo no retiene tantos bytes distintos, así que arreglar esto no devuelve toda esa memoria. Lo exacto es el número de copias, y el hecho de que cada una es un cliente independiente del upstream, con su socket, su lock y su sesión. Veintiséis clientes contra una base de datos no es un problema de memoria; es un problema de concurrencia disfrazado.
El arreglo cabe en una línea de configuración: declarar el servidor con "type": "sse" y url http://127.0.0.1:8765/sse. El resto del repositorio —lanzador, plantillas de autostart, watchdog— existe para que eso sobreviva a un reinicio y a un compañero de equipo. Las plantillas cubren Windows (clave Run en HKCU), macOS (launchd) y Linux (systemd --user), ninguna con permisos de administrador.
El watchdog es la parte peligrosa
Reiniciar un daemon compartido deja ciegas todas las sesiones vivas. No se reconectan: cada llamada posterior responde -32602 Invalid request parameters hasta que alguien reinicia cada sesión a mano. En el modelo por sesión una caída cuesta una sesión; en el compartido, un reinicio las cuesta todas. Por eso el watchdog obvio —puerto muerto, reinicio— es peor que no tenerlo. El suyo sondea dos veces, registra la falsa alarma en lugar de actuar, guarda evidencia antes de tocar nada y se niega a reiniciar un daemon que solo está mudo.
El texto enumera además tres fallos que produjeron respuestas seguras y equivocadas en vez de errores. La primera versión de la herramienta de medición identificaba los procesos por su comando de lanzamiento, "command": "node", así que cualquier proceso de Node de la máquina contaba como copia; ahora usa el directorio de instalación. Win32_Process.CommandLine vuelve vacío cuando el proceso corre a otro nivel de privilegios, de modo que la sonda no veía un daemon vivo y lo daba por ausente; ahora lo identifica por puerto y siempre imprime cuántos procesos no pudo leer. Y un -- dentro de un comentario XML invalida el plist, con launchctl load fallando en silencio.
No conviene hacer esto si solo mantienes una sesión de agente, si el servidor guarda estado o autenticación por sesión, o si nadie va a mantener el arranque automático y el watchdog. Tampoco ahorra tokens: el coste de contexto viene de los esquemas de herramientas, que el cliente envía igual sea cual sea el transporte. Si el problema son los tokens, hay que desactivar los servidores que un proyecto no necesita.
El repositorio está en mcp-daemon-diet, bajo licencia MIT y sin nada atado a una integración concreta.
