mcpsnoop: Wireshark para MCP, instalado en un solo comando
Si pasaste tiempo real construyendo contra servidores MCP, ya conocés la frustración puntual a la que apunta esta herramienta. Un tool call que silenciosamente no se dispara. Un handshake de capabilities que no coincide con lo que esperabas. Un request que simplemente… queda colgado. Y cuando recurrís al MCP Inspector oficial para entender qué pasó, no te ayuda — porque el Inspector no está mirando tu conversación real. Se conecta como su propio cliente separado, corre sus propios test calls, y te muestra lo que él ve, no lo que tu cliente y tu servidor reales se dijeron entre sí.
mcpsnoop, una herramienta open-source nueva publicada en GitHub y posteada en Hacker News el 4 de julio, va por el camino contrario: se ubica directamente en el data path entre tu cliente real y tu servidor real, y te muestra el tráfico tal como sucede.
El punto ciego que resuelve
MCP corre sobre JSON-RPC 2.0, y hay una sutileza en el protocolo que hace tropezar mucho debugging: un tool call puede volver como un response perfectamente exitoso a nivel transporte mientras carga adentro, en result.isError, un fallo a nivel de aplicación. Si solo estás mirando status codes HTTP o logs básicos de requests, ese fallo es invisible — el call “tuvo éxito” en lo que a tu logging respecta, aunque el tool mismo acaba de reportar que falló.
La arquitectura side-channel del Inspector tampoco puede detectar esto, ya que nunca ve el call real en primer lugar. Todo el diseño de mcpsnoop está construido para ocupar el pipe real en lugar de pararse a un costado, así que ve:
- Cada frame JSON-RPC entre tu cliente real (Claude Desktop, Cursor, Claude Code, o tu propio agente) y tu servidor real, sin importar en qué lenguaje esté escrito el servidor
- Responses con
isErrora nivel tool marcadas explícitamente, no escondidas - Calls colgados, mostrados en vivo con un timer corriendo en lugar de trabarse en silencio
- El capability handshake que ambos lados realmente negociaron al conectar
Cómo se usa
Es un único binary de Go con dos roles incorporados. Como shim, envuelve el comando de arranque de tu servidor y forwardea los bytes tal cual mientras le manda una copia de cada frame al hub. Como hub, es la TUI en vivo que efectivamente mirás. Se encuentran automáticamente a través de un socket conocido y logs en disco — sin pairing manual, sin orden de arranque requerido.
Envolver un servidor stdio se ve así en la config de tu cliente:
{
"mcpServers": {
"my-server": {
"command": "mcpsnoop",
"args": ["--", "node", "build/index.js"]
}
}
}
Todo lo que va después de -- es el comando que normalmente levanta tu servidor. Para servidores streamable-HTTP, corre como reverse proxy en cambio:
mcpsnoop http --target http://localhost:3000/mcp --listen :7000
Una vez corriendo, la TUI soporta filtering en vivo con tokens separados por espacio — tool:search status:slow para aislar calls lentos a un tool específico, o dir:s2c kind:req para sacar a la superficie requests iniciados por el servidor, como sampling o roots. Las sesiones capturadas se pueden hacer replay contra una copia fresca y aislada del servidor, así podés reproducir un fallo específico sin volver a manejar toda tu sesión de agente, y exportarlas después como JSON, HTML o texto plano.
Instalación
go install github.com/kerlenton/mcpsnoop@latest
o vía Homebrew, aunque con una salvedad para tener en cuenta de entrada: un brew install mcpsnoop sin tap requiere que el proyecto supere la vara de notability de Homebrew core (stars, forks, watchers), algo que todavía no logra en esta etapa. Por ahora, las instalaciones vía Homebrew pasan por confiar directamente en el tap del autor, o podés bajar un binary prearmado desde la página de Releases en GitHub.
Antes de usarlo
Es un proyecto fresco — el repo es chico, pre-1.0, y sigue semver de manera laxa mientras está en 0.x (lo que significa que releases menores todavía pueden cambiar el comportamiento de cara al usuario). La comparación con el Inspector oficial es el framing propio del autor, no un benchmark independiente, aunque la distinción arquitectónica que señala — estar en el pipe versus conectarse como segundo cliente — es precisa y fácil de verificar leyendo el código fuente de cualquiera de las dos herramientas.
También vale aclarar que mcpsnoop solo ejecuta el comando de servidor que vos explícitamente envolvés, así que aplica la precaución de siempre: envolvé solo servidores en los que confiás, y corré los que no en un container.
Para cualquiera que haya perdido tiempo adivinando fallos de MCP a partir de logs dispersos, esto es una solución puntual genuinamente útil — chica, enfocada, y que resuelve un punto ciego específico en lugar de intentar ser una plataforma de observability completa.