mcpsnoop

Wireshark para MCP. Un proxy transparente que muestra cada llamada real a herramientas entre tu cliente de IA y tus servidores MCP, en vivo en tu terminal.

mcpsnoop demo

El problema

El Inspector MCP oficial se conecta como su propio cliente, por lo que nunca ve lo que tu cliente (Cursor, Claude Code, Codex) envía realmente a tu servidor. Y cualquier cosa que espera a que llegue una solicitud no puede mostrar la llamada que el modelo nunca hizo, o que hizo con argumentos incorrectos. Cuando una herramienta no se llama silenciosamente, las capacidades no coinciden, o una llamada simplemente se cuelga, te quedas revisando registros y adivinando.

Repite `redact-key`, `redact-value` y `redact-path` en líneas propias para añadir más de uno de cada. Esas son todas las claves que admite. El archivo solo se busca en el directorio de trabajo actual, no en directorios padres. Las banderas explícitas de la línea de comandos anulan los valores del archivo de configuración. ## Comandos | Comando | Qué hace | |---|---| | `mcpsnoop -- <server>` | envuelve un servidor stdio como un shim transparente | | `mcpsnoop` | abre la TUI en vivo | | `mcpsnoop http --target <url>` | hace de proxy para un servidor HTTP transmisible | | `mcpsnoop export` | renderiza una sesión a json, html, text, har u otlp | | `mcpsnoop check` | falla el CI por errores, marcos inválidos, advertencias, desajustes de enrutamiento, llamadas colgadas, resultados tardíos o un presupuesto de latencia | | `mcpsnoop baseline` | inspecciona, acepta o restablece definiciones de herramientas de confianza | | `mcpsnoop diff` | compara herramientas y llamadas entre dos sesiones capturadas | | `mcpsnoop open` | abre una sesión guardada en la TUI | | `mcpsnoop inventory` | lista cada servidor que haya pasado por mcpsnoop en esta máquina | | `mcpsnoop stats` | pliega cada captura almacenada en una fila por servidor y herramienta | | `mcpsnoop prune` | elimina registros de sesiones guardadas más antiguos que un límite | | `mcpsnoop wrap <server>` | enruta uno de los servidores de Claude Desktop a través de mcpsnoop | | `mcpsnoop unwrap <server>` | restaura la entrada de ese servidor a como estaba | | `mcpsnoop remote <user@host>` | imprime el comando del túnel SSH | | `mcpsnoop demo` | reproduce una sesión con guion | Ejecuta `mcpsnoop help` para la lista completa, o `mcpsnoop help <comando>` para las banderas de uno. ## Cómo se compara | | MCP Inspector | mcpsnoop | |---|:---:|:---:| | Ve tu tráfico real de cliente y servidor | no | sí | | Señala llamadas colgadas y errores de flujo | no | sí | | Señala salida dispersa que corrompe el flujo | no | sí | | Señala marcos JSON-RPC malformados | no | sí | | Detecta deriva en definiciones de herramientas tras la aprobación | no | sí | | Interfaz de terminal interactiva | no | sí | | Cero configuración, sin banderas ni orden | no | sí | | Inspector de capacidades | parcial | sí | | Reproduce una llamada capturada | no | sí, por stdio y por HTTP | | Exportación de sesión (json / html / text / otlp) | no | sí | | Binario único, sin dependencias de ejecución | no | sí | ## Instalación ### npm No se necesita cadena de herramientas Go. La mayoría de los servidores MCP están escritos en Node o Python, así que esta es la vía más corta.```bash npx mcpsnoop -- node build/index.js

`--older-than` es obligatorio (no hay un valor predeterminado que elimine nada) y acepta un recuento de días como `30d` o una duración de Go como `72h`. Las líneas base de las herramientas se dejan intactas, ya que una línea base está vinculada por la etiqueta del servidor y no por la sesión. Debido a que se encuentra en la tubería real, no a un lado como el Inspector, ve exactamente lo que su cliente y servidor reales se dicen entre sí, sin importar en qué esté escrito el servidor. ## Atajos de teclado | Tecla | Acción | | Tecla | Acción | |---|---|---|---|---| | `enter` | inspeccionar / profundizar | | `/` | filtrar | | `esc` | atrás | | `:` | comando | | `j` / `k` | mover | | `r` / `R` | reproducir / editar y reproducir | | `g` / `G` | arriba / abajo | | `c` | capacidades | | `ctrl-f` / `ctrl-b` | página | | `s` | resumen de herramienta | | `p` | pausa | | `y` | copiar | | `shift`+`<tecla>` | ordenar por columna | | `e` | exportar | | `ctrl-d` | eliminar sesión | | `f` | seguir | | `?` | ayuda | | | | Pulsa `?` en la aplicación para ver la lista completa. ## Filtrar el flujo Pulsa `/` en una sesión y combina tokens separados por espacios, con AND. El texto sin formato coincide con el método, la herramienta, el id y la carga útil. | Token | Filtra por | Ejemplo | |---|---|---| | `tool:` | nombre de la herramienta | `tool:search` | | `method:` | método JSON-RPC | `method:tools/call` | | `id:` | id de solicitud, y cualquier reintento que lo continúe | `id:7` | | `task:` | id de tarea | `task:01J...` | | `dir:` | dirección (`c2s`, `s2c`) | `dir:s2c` | | `kind:` | tipo de trama (`req`, `resp`, `notify`, `stderr`, `invalid`) | `kind:invalid` | | `status:` | resultado de la llamada (`ok`, `error`, `cancel`, `late`, `cancelled`, `pending`, `bad`, `warn`, `mismatch`, o un estado HTTP como `401`) | `status:error` | Apila tokens para obtener algo específico.```text tool:search status:pending # in-flight calls to one search tool status:cancel # calls the client gave up on (status:cancelled is a cancelled task) status:late # results that arrived after the cancellation method:tools/call status:error # tool calls that failed dir:s2c kind:req # server-initiated requests (servers before 2026-07-28)

Estas banderas reescriben el archivo exportado o la vista TUI en memoria, nunca el JSONL de origen. `export` rechaza una salida que nombre el mismo archivo que su entrada, y escribe a través de un archivo temporal que se renombra en su lugar, de modo que una ejecución que falle deja intacto el archivo anterior. El `inputSchema` y `outputSchema` de una herramienta, tal como se anuncian en un resultado de `tools/list`, no se ven afectados por `--redact-key` ni `--redact-secrets`, por tres razones. - Un nombre dentro de un esquema es una declaración de tipo, no un valor. - El nombre en sí permanece en el registro de todos modos. - Depurar el subesquema bajo una propiedad llamada `token` eliminaría también las propias comprobaciones de la herramienta. La exención se aplica solo a esa posición, de modo que un argumento que casualmente se llame `inputSchema` se depura como cualquier otro, y se detiene en `default`, `const`, `examples` y `enum`, que contienen datos en lugar de estructura. Usa `--redact-path` para nombrar algo dentro de un esquema, o `--redact-value`, que coincide con texto dondequiera que esté, excepto en las dos palabras clave que mcpsnoop analiza, `type` y `x-mcp-header`. Lo que alcanza cada bandera difiere, así que revisa el resultado en lugar de asumir. Las cuatro depuran cargas útiles JSON-RPC, y `--redact-key`, `--redact-path` y `--redact-secrets` solo llegan a esas. Solo `--redact-value` también depura stderr, otro texto no JSON y el interior de una cadena. Una cabecera `Mcp-Param-*` se depura junto con el valor del cuerpo que refleja. El resto de los metadatos del sobre, las etiquetas del servidor, `Mcp-Name`, `Mcp-Method` y el estado HTTP, se dejan tal como se capturaron. La redacción es de mejor esfuerzo, así que usa una ruta de salida separada y lee el resultado antes de compartirlo. ### Transmitir llamadas completadas a un colector OTLP Envía spans mientras el proxy está en ejecución apuntándolo a un endpoint de trazas OTLP/HTTP JSON. Repite `--otlp-header` para la autenticación del colector o las cabeceras de tenant.```bash mcpsnoop \ --otlp-endpoint http://localhost:4318/v1/traces \ --otlp-header "Authorization=Bearer $OTLP_TOKEN" \ -- node build/index.js mcpsnoop http \ --target http://localhost:3000/mcp \ --otlp-endpoint http://localhost:4318/v1/traces

Fija una versión, la que quieras. La más reciente está en la [página de releases](https://github.com/kerlenton/mcpsnoop/releases). No hay un `v1` flotante, a propósito. La versión fijada es también el binario que instala la acción, por lo que los dos nunca pueden discrepar y no hay una versión predeterminada que quede obsoleta. | Entrada | | |---|---| | `session` | la captura `.jsonl` a comprobar, relativa a la raíz del repositorio. Obligatoria | | `fail-on` | igual que `--fail-on`, con el mismo valor predeterminado que usa la CLI | | `args` | cualquier otra bandera de `check`, entre comillas como en una línea de comandos. Se rechaza `--format`, ya que la acción lee el informe | | `upload-sarif` | envía el informe al code scanning. `true` | | `category` | el espacio de nombres de code scanning. `mcpsnoop`. Varíalo por cada rama de una matriz, o las ramas se sobrescriben entre sí | | `fail-on-findings` | hace fallar el job ante un hallazgo. `true`. Pon `false` para archivar las alertas y dejar que la comprobación obligatoria de code scanning decida | | `version` | qué mcpsnoop instalar. Por defecto, la versión que fijaste | | `install` | `false` cuando mcpsnoop ya está en PATH, que es la vía en una plataforma para la que no se ha compilado ninguna release | Las salidas son `outcome`, `sarif` y `exit-code`. `outcome` es `passed`, `findings` o `error`, y la tercera merece tratarse por separado. Significa que no se comprobó nada, que no es lo mismo que no se encontrara nada. **Una ejecución que no pudo comprobar hace fallar el job diga lo que diga `fail-on-findings`**, porque un pipeline que se pone en verde habiendo verificado nada es peor que uno que falla. El job necesita `security-events: write`, o la subida responde 403. Pon `upload-sarif: false` en un repositorio sin code scanning. ### O conéctalo tú mismo La acción son cuatro pasos y nada de magia. Hacerlo a mano requiere el mismo cuidado que requiere. La subida tiene que ejecutarse en las ejecuciones que tienen un informe, que son las que salieron con 0 o 1 y no las que salieron con 2, y el paso que hace fallar el job tiene que ir después, o los hallazgos nunca llegan a la pestaña para la que existen.```yaml permissions: # required for all workflows security-events: write # only required for workflows in private repositories actions: read contents: read steps: - name: Check captured MCP session id: check run: | code=0 mcpsnoop check --format sarif artifacts/session.jsonl > mcpsnoop.sarif || code=$? echo "exit-code=$code" >> "$GITHUB_OUTPUT" # 2 means the check never happened, so there is no report to publish and # nothing was verified. Stop here rather than uploading an empty file. [ "$code" -le 1 ] || exit 1 - name: Upload mcpsnoop SARIF report if: ${{ !cancelled() }} uses: github/codeql-action/upload-sarif@v4 with: sarif_file: mcpsnoop.sarif category: mcpsnoop - name: Fail on findings # Separate, and after the upload, so the findings reach the Security tab on # exactly the runs that have some. if: ${{ !cancelled() && steps.check.outputs.exit-code == '1' }} run: exit 1

Como `drift`, `deprecated` es opcional. Una ejecución por defecto informa el recuento y permanece en verde, por lo que una sesión que use una característica obsoleta aún legal nunca pone CI en rojo por sí sola. ### Construcciones de esquema de marca que los clientes manejan mal Un servidor puede ser perfectamente válido y aun así ser difícil de usar para un agente. Los clientes difieren en cuánto de JSON Schema realmente soportan, y una herramienta que el modelo sigue invocando incorrectamente suele ser una herramienta cuyo esquema pidió más de lo que el cliente entrega. El resumen de herramientas, abierto con `s`, tiene una columna SCHEMA que nombra lo más notable de cada esquema de herramienta anunciado, con un `+` al final cuando hay más de un tipo. | Mostrado | Significado | |---|---| | `no root` | el `inputSchema` está ausente, no es un objeto JSON, o tiene un tipo raíz distinto de `"object"` | | `dialect` | un `$schema` que nombra un dialecto distinto del 2020-12 al que la revisión se ajusta por defecto | | `ext ref` | un `$ref` que apunta fuera del documento, que también es el caso en el que la especificación advierte a los implementadores que no sigan a ciegas | | `oneOf`, `anyOf`, `allOf`, `not` | una palabra clave de composición, manejada de forma inconsistente entre clientes | | `ref` | un `$ref` que apunta dentro del mismo documento | | `untyped` | una propiedad que no declara tipo ni ninguna otra forma de indicar qué acepta | Todas menos la primera son observaciones más que veredictos. Un esquema que usa `oneOf` no es incorrecto, solo es probable que distintos clientes lo lean de forma diferente, y un esquema puede declarar el dialecto que quiera. `no root` es la excepción: la definición de `Tool` requiere `inputSchema` y fija su tipo raíz a `"object"`, por lo que un cliente que valide un listado rechaza esa herramienta por completo y nunca llega a ser invocable, sin nada en el cable que explique por qué. `no root` encabeza la columna por esa razón, y un esquema que la propia redacción de mcpsnoop haya borrado nunca se informa, ya que un esquema ilegible no es uno incorrecto. Esa división decide qué hace `check` con ellos. `no root` es una advertencia en el marco `tools/list`, por lo que falla la puerta por defecto `error,invalid,warn` sin ninguna marca, que es el punto: un servidor que envía una herramienta inutilizable responde a cada protocolo de forma normal y simplemente nunca recibe un `tools/call`. Las observaciones se cuentan como `schema_findings` y se informan bajo `schema findings:`, y solo hacen fallar la ejecución cuando añades `schema` a `--fail-on`. Ambas llegan a `--format junit` y `--format sarif`, y `export` lleva la lista por herramienta bajo `summary.definitions.per_tool[].findings`.```bash mcpsnoop check session.jsonl # a non-object root already fails this mcpsnoop check --fail-on schema session.jsonl # and now so do the observations

Sin `--replay-target`, una sesión HTTP lo dice explícitamente en lugar de ofrecer una clave que no puede funcionar. Con ella, `r` sigue preguntando antes del primer envío de una sesión, igual que se responde a un comando grabado antes de ejecutarlo. Una credencial llega al servidor a través de `--replay-header` y de ningún otro sitio. mcpsnoop no registra ninguna cabecera `Authorization` ni reproduce ninguna, así que no hay nada capturado que una reproducción pueda filtrar. El POST reproducido lleva lo que el transporte hace obligatorio, algo que un POST del cuerpo capturado desnudo no hace: `MCP-Protocol-Version`, un `Accept` que lista tanto `application/json` como `text/event-stream`, `Mcp-Method`, `Mcp-Name` donde la especificación lo exige, y cada `Mcp-Param-*` capturado. Esos se reenvían textualmente desde la captura, centinela base64 incluido, por lo que no pueden discrepar del cuerpo como podría hacerlo una rederivación. La única cabecera que no se copia es la versión del protocolo, porque el cuerpo reproducido declara la revisión que habla mcpsnoop y la cabecera debe coincidir con el cuerpo. `Mcp-Name` se deriva del cuerpo que se envía en lugar de copiarse, porque la especificación lo toma de `params.name` o `params.uri` y exige que un servidor rechace una cabecera que discrepe del cuerpo, así que una edición que renombre la herramienta enviaría de otro modo el nombre antiguo. Las cabeceras `Mcp-Param-*` reflejan los argumentos capturados, por lo que una reproducción editada no envía ninguna de ellas en lugar de afirmar algo sobre un cuerpo que alguien reescribió. Una captura solo puede establecer cabeceras de esa única familia. Un registro es un archivo que la gente se pasa, y permitirle nombrar cualquier cabecera le permitiría sobrescribir las obligatorias o añadir una credencial que nadie pasó. Un `Mcp-Param-*` que una regla de redacción haya depurado detiene la reproducción con un motivo. Enviar el marcador de posición pondría los propios bytes de mcpsnoop en un servidor en vivo como si un usuario los hubiera tecleado. Una redirección se rechaza en lugar de seguirse. La dirección es la que nombraste y por la que respondiste, y seguir un 307 entregaría esa elección al extremo remoto, reenviando el cuerpo y, en un salto que solo cambia el puerto, también la credencial. mcpsnoop informa a dónde quería enviarlo el servidor y te deja decidir si nombrar esa dirección en su lugar. Una respuesta que llega como un único objeto JSON y una que llega como un flujo de eventos se leen ambas, y un fallo se nombra en lugar de numerarse: - un 401 informa del esquema que exigió el servidor - un `-32020` informa de a qué puso objeciones - un 400 o 404 no JSON-RPC dice que la dirección no es un endpoint HTTP Streamable de esta revisión ### Distinguir la latencia del servidor de la del usuario En peticiones de múltiples idas y vueltas, una llamada de herramienta son varias peticiones, y los segundos que una persona dedicó a responder una elicitación quedan dentro del intervalo. Eso es deliberado, ya que ese intervalo suele ser el que más quieres ver, pero significa que un solo número no puede responder a ambas preguntas. En una cadena `book_flight` donde el servidor trabajó 1,2 segundos mientras el usuario tardó 37, `check --max-duration 5s` culpa a la herramienta por 38,2 segundos. Sigue haciéndolo, porque cambiar lo que significa esa opción aflojaría cada canalización que ya la establece. Dos hermanos nombran lo que miden en su lugar.```bash mcpsnoop check --max-server-duration 1s session.jsonl # the server's share alone mcpsnoop check --max-round-trips 2 session.jsonl # how chatty a tool is

Ambos están desactivados por defecto, por lo que una ejecución de `check` por defecto no se ve afectada, y ambos se leen de las marcas de tiempo de los frames y de un enlace que mcpsnoop ya había inferido, así que ninguno adivina intenciones. Pulsa `i` en la TUI para ver el desglose, o lee `interactions` en las exportaciones json, text y html. Cada entrada es una operación lógica con su número de viajes de ida y vuelta, su total, la parte que el servidor mantuvo y la parte que esperó al cliente, más una línea por salto que nombra qué pidió cada respuesta. El resumen por herramienta gana una columna `TRIPS` para que una herramienta habladora sea visible sin abrir nada. `export --format har` pone la parte del servidor en `wait` y el resto en `blocked`, que es para lo que sirve ese campo, así un visor deja de dibujar una espera de servidor de 38 segundos que nunca ocurrió. Los contadores y las dos partes se acumulan a medida que llegan los frames en lugar de derivarse cuando lo pides, porque el almacén en vivo libera frames antiguos para mantenerse dentro de su presupuesto y una respuesta derivada sería silenciosamente una ventana en lugar de una cadena. El desglose por salto se lee de los frames aún retenidos, y lo indica cuando es solo parte de uno. `ServerTime + ClientTurnaround` equivale al total por construcción, no por una aritmética en la que alguien tenga que confiar. `--max-round-trips` juzga una cadena que aún está en curso, porque cada petición que ya ha hecho es contable y un servidor que pregunta una y otra vez produce exactamente la operación que nadie termina jamás. `--max-server-duration` espera a un final, que es la regla que `--max-duration` ya aplica, ya que una operación aún abierta no tiene latencia que juzgar. Una operación que mcpsnoop no pudo enlazar permanece como su propia entrada de un solo salto. `matchRetry` rechaza un enlace ambiguo a propósito, y esta vista no rellena ese hueco. Una operación que tomó una sola petición no lleva desglose de saltos, porque un único salto repite palabra por palabra los totales de arriba. Una cadena informa de un salto por petición, y lo indica cuando el almacén ya no retiene cada frame o cuando el trabajo se resolvió fuera del par petición-respuesta del que se compone un salto, como hace un identificador de tarea. ### Ver qué pidió un servidor a tu usuario La elicitación es el único camino en MCP donde una persona escribe datos en un servidor, y bajo MRTR la pregunta y la respuesta ya no son dos mitades de un mismo intercambio. La pregunta está enterrada en un `InputRequiredResult`, la respuesta vuelve dentro de `inputResponses` en un reintento bajo un id diferente, y lo único que las une es el enlace que mcpsnoop ya infiere. Sin ese emparejamiento, una solicitud de contraseña rechazada se lee como un simple error de herramienta.``` tools/call login_legacy [form] creds: decline after 3s password string

Una fila por servidor en lugar de por sesión. La clave de la fila es el comando registrado y el directorio de trabajo, nunca la etiqueta, porque la etiqueta proviene del último elemento de ruta del comando y tanto `node ~/one/build/index.js` como `node ~/two/build/index.js` derivan `index.js`. Una sesión HTTP se identifica por el endpoint que proxy, ya que mcpsnoop no lanzó nada allí. La lectura es un sobre por registro, el marco de metadatos que el proxy escribe primero, por lo que sigue siendo barata sobre un directorio de capturas grandes. `--tools` es la excepción y lee un registro por servidor, la ejecución más reciente de cada uno, por lo que es una bandera en lugar de una columna. Incluso entonces la lectura está acotada, porque un inventario de herramientas es estado de sesión que la tienda incorpora sobre la marcha, de modo que una captura de cien megabytes se lee a través de una ventana fija en lugar de mantenerse completa para producir un entero. Cuando no hay recuento, la fila indica cuál de tres cosas ocurrió, porque un registro que no pudo leerse no es un servidor que no anunció nada, y una sola frase para ambos haría que mcpsnoop afirmara algo falso. Un comando que una regla de `--redact` reescribió se imprime tal como se registró y se marca, en lugar de presentarse como el comando que se ejecutó. Dos ejecuciones de un servidor, una depurada y otra no, son dos filas. mcpsnoop no puede saber qué reemplazó el marcador de posición, y fusionarlas implicaría adivinar que las mitades ocultas coincidían. Un servidor ejecutado bajo dos valores de `--label` es una fila que lleva ambos nombres, ya que la clave es el comando en lugar del nombre. Nada en una fila lo escribe mcpsnoop. Un comando proviene de quien instaló el servidor, un directorio de trabajo sale del sistema de archivos y una etiqueta derivada proviene del comando. Un valor que contiene un carácter de control se cita en lugar de imprimirse en bruto, de modo que un directorio cuyo nombre contiene un salto de línea no puede cerrar el campo en el que se imprime y hacer que las líneas siguientes se lean como servidores que nunca se ejecutaron. Un argumento que contiene un espacio también se cita, porque `node "~/My Project/ build/index.js"` de otro modo es indistinguible de dos argumentos. Cualquier cosa que el recorrido no pudiera incorporar se nombra en el encabezado en lugar de descartarse. Los registros vacíos se cuentan aparte de los dañados, ya que un registro de cero bytes es el residuo ordinario de una ejecución cuyo exec falló o de un proxy HTTP al que nadie llamó. La salida se ordena por nombre en lugar de por actualidad, de modo que dos ejecuciones sobre un directorio producen los mismos bytes, que es lo que la hace utilizable como línea base para comparar más adelante. Hay dos vacíos por construcción, no por descuido. Una ejecución con `--trace-file` escribió fuera del directorio de sesiones y no aparecerá, y `prune` elimina registros, por lo que la primera vez vista solo es tan antigua como lo que aún está en disco. mcpsnoop informa lo que se ejecutó en esta máquina a través de él. No escanea ninguna red, no lee ninguna configuración de cliente a la que no se le haya apuntado, y no juzga nada. ### Distinguir un servidor roto de una herramienta que dice que no Una herramienta que responde `result.isError` está funcionando. Miró y no encontró nada, o rechazó la entrada. Un servidor que responde con un error JSON-RPC está roto. Ambos eran un número en el resumen de herramientas, lo que significaba que una herramienta bien comportada que informa fallos de dominio parecía exactamente un servidor roto, y se ordenaba por encima de uno. La columna `ERR` los separa. El rojo es el lado del servidor, que es un error JSON-RPC o una tarea que terminó fallida sin decir por qué. El color de advertencia es el propio `isError` de la herramienta. Una herramienta con ambos muestra los recuentos unidos, rojo primero, y una línea bajo la tabla nombra los dos totales siempre que haya un número de advertencia que explicar. La exportación lleva la misma división como `protocol_errors` y `tool_errors` junto al total de `errors` al que siempre suman. `check --fail-on error` no cambia y sigue disparándose con cualquiera de los dos, ya que una puerta que ignorara uno de ellos sería una puerta que un servidor podría desactivar devolviendo el otro.```bash mcpsnoop export -T json | jq '.summary.tools[] | {name, errors, protocol_errors, tool_errors}'

La exportación incluye las mismas cifras, por herramienta y divididas en bytes de descripción y de esquema, de modo que una descripción voluminosa y un esquema voluminoso siguen siendo separables y cualquiera de ellos puede rastrearse entre capturas. `mcpsnoop diff` te indica si una descripción o un esquema cambió entre dos sesiones. La exportación es donde reside el tamaño de ese cambio. **Estos son bytes, no tokens.** Un recuento de tokens depende del modelo, así que medirlo implicaría incluir un tokenizador y elegir de quién. Los bytes son exactos y puedes aplicar tu propia proporción. Una `tools/list` inconclusa informa lo que vio como un mínimo y lo dice, en lugar de presentar una suma parcial como si fuera el total. ### Detectar un cliente que altera el estado del servidor En el patrón de múltiples idas y vueltas, el servidor entrega al cliente un `requestState` opaco y el cliente debe devolverlo intacto en el reintento. Se le indica al servidor que lo trate como entrada controlada por el atacante, porque un cliente que lo manipule puede intentar alterar el comportamiento del servidor o eludir una comprobación de autorización. Situado en el canal, mcpsnoop ve el valor salir y volver, por lo que puede decir cuándo se rompió el contrato. Hay tres formas en que puede romperse, cada una reportada como advertencia de protocolo en el reintento. | Reportado | Significado | |---|---| | `MRTR retry changed requestState` | el cliente devolvió algo distinto de lo que emitió el servidor | | `MRTR retry is missing requestState` | el servidor emitió uno y el reintento lo omitió | | `MRTR retry invented requestState` | el reintento llevaba uno que el servidor nunca emitió | Estas son violaciones de protocolo por parte del cliente, no observaciones nuestras, así que viajan por la señal de advertencia ordinaria y **una ejecución de `check` por defecto falla ante una de ellas**. Eso es deliberado. Un cliente que altera el estado del servidor merece detener una compilación. El valor en sí nunca se muestra ni se registra, y nada lo decodifica ni lo analiza. Puede ser un blob cifrado que lleva un principal y un token, y comparar bytes opacos es toda la comprobación. Un caso queda fuera de alcance. Cuando un servidor responde con un `requestState` y sin `inputRequests`, un reintento manipulado no coincide con nada y no responde a ninguna clave, así que no queda nada que lo vincule a la solicitud original y se lee como una llamada no relacionada en lugar de una violación. Un intercambio abandonado no perturba el siguiente, ni se conserva para siempre. Sesenta y cuatro intercambios abiertos son muchos más de los que cualquier cliente tiene a la vez, así que una sesión que mantiene más está manteniendo algunos que nadie terminará, y los más antiguos se retiran porque la especificación indica a los servidores que den a ese estado una caducidad corta y lo rechacen después. La retirada se cuenta en lugar de hacerse en silencio. El pie del flujo muestra `N unlinked` y la exportación lleva `session.retired_exchanges`, porque un reintento que sí llega para una operación retirada se lee como su propia llamada, y un lector que compara recuentos merece que se le informe. Retirar una también permite que el almacén en vivo la libere. Una operación en pausa permanece pendiente a propósito, de modo que su duración abarca todo el intercambio, y el almacén se niega a olvidar una llamada pendiente porque aún puede llegar una respuesta. Una vez que el límite ha retirado una operación, nada puede responderla, así que mantenerla conserva una llamada viva a la que ningún lector puede acceder. Lo que informa la sesión no cambia. Sigue contada como pendiente y sigue contada en `N unlinked`, porque cuánta memoria ocupa un registro y qué dice el registro son preguntas distintas. Un intercambio abandonado no perturba el siguiente. MRTR indica a los servidores que no deben asumir que un cliente reintentará jamás, así que un usuario que rechaza una elicitación deja una operación que ningún marco posterior resolverá jamás. mcpsnoop busca primero entre las operaciones cuya presencia de `requestState` coincide con la del reintento, lo que la especificación convierte en regla en ambas direcciones, de modo que un reintento conforme encuentra la única operación que continúa incluso cuando un intercambio abandonado en la misma herramienta está a su lado. La comprobación que informa las tres violaciones anteriores solo se ejecuta cuando nada coincide, así que un reintento genuinamente no conforme sigue siendo señalado. ## Observar desde otra máquina Mantén la captura local en la máquina donde ocurre el tráfico y usa SSH para el salto de red, de modo que mcpsnoop nunca necesite un transporte remoto propio. ### Vista en vivo Ejecuta la TUI en tu estación de trabajo y reenvía el socket de mcpsnoop de la máquina remota de vuelta a ella. El túnel en vivo usa reenvío de sockets Unix por SSH, así que ambos extremos deben ejecutar Linux o macOS. En Windows, usa la copia del registro post-mortem que aparece a continuación.```bash # on your workstation, start the TUI mcpsnoop # create the remote socket directory once ssh remote-user@remote-host 'mkdir -p ~/.local/state/mcpsnoop' # print the tunnel command, then run the printed ssh -R line mcpsnoop remote remote-user@remote-host # on the remote host, wrap your server as usual mcpsnoop -- node build/index.js

## Seguridad mcpsnoop ejecuta el comando del servidor que envuelves, así que envuelve únicamente servidores en los que confíes, y ejecuta los que no sean de confianza en un contenedor. Nunca ejecuta nada que no hayas puesto en tu configuración de cliente. Para flujos de trabajo remotos, usa túneles SSH o transferencia de archivos por SSH para que la autenticación del transporte, el cifrado, la verificación del host, la rotación de claves y la política de auditoría permanezcan en tu configuración SSH existente. ### Redacción de lo que capturas Los frames capturados pueden incluir prompts, argumentos de herramientas, credenciales y resultados de herramientas. Si los payloads pueden contener secretos, opta por la redacción para limpiar las copias de la traza observada mientras los bytes proxyados siguen pasando sin cambios. La redacción basada en claves reemplaza valores completos bajo claves JSON de objetos coincidentes, y el mismo conjunto de claves se aplica con el mejor esfuerzo a los argumentos de línea de comandos del servidor envuelto, de modo que `--api-key=sk-x` y `--token sk-x` se limpian con `--redact-secrets`. Un argumento que lleva un secreto sin un nombre de flag reconocible no se puede detectar. El endpoint HTTP no forma parte de todo eso, porque no es un payload que hayas elegido enviar. `--target` es un flag que tienes que pasar para ejecutar el proxy en absoluto, por lo que su URL llegaría al registro de sesión independientemente de tu configuración de redacción. mcpsnoop lo registra con el userinfo, cada valor de query y el fragment ya eliminados, siempre, por construcción y no por patrón. Las claves de query sobreviven, ya que son lo que distingue dos endpoints de un mismo host, y el fragment se descarta porque nunca llegó al servidor para empezar. Lo que se registra identifica al servidor y no es una dirección para marcar. La redacción basada en rutas reemplaza solo los valores seleccionados por una expresión JSONPath, lo cual es útil cuando un nombre de clave común es sensible en una ubicación pero seguro en otra. Repite `--redact-path` para limpiar más de una ubicación. La redacción basada en valores aplica expresiones regulares a los valores de cadena observados, al texto de stderr y a los frames de texto que no son JSON. Las tres son de mejor esfuerzo. Las regex pueden omitir secretos, coincidir en exceso con texto inofensivo o no detectar valores transformados o codificados. La redacción nunca se convierte en una acusación. Cada comprobación que compara una cosa observada con otra, un encabezado de enrutamiento contra el cuerpo, un valor de `Mcp-Param` contra el argumento que refleja, el esquema de una herramienta contra lo que la revisión exige de uno, sabe cuándo mcpsnoop fue el lado que reescribió los bytes y permanece en silencio en lugar de informar sobre un servidor por la propia configuración de privacidad del usuario. La deriva de definición de herramientas es la excepción, y deliberadamente, ya que activar la redacción cambia lo que se registra y, por tanto, lo que contiene una línea base. Consulta [Detectar deriva de definición de herramientas](#detect-tool-definition-drift).```bash # built-in preset of common secret keys mcpsnoop --redact-secrets -- node build/index.js # or name your own keys mcpsnoop --redact-key token,api_key,password -- node build/index.js # scrub one location without redacting every field named password mcpsnoop --redact-path '$.params.arguments.password' -- node build/index.js # wildcards scrub every matching array element mcpsnoop --redact-path '$.params.arguments.accounts[*].password' -- node build/index.js # scrub obvious token-shaped values outside known keys mcpsnoop --redact-value 'sk-[A-Za-z0-9]+' -- node build/index.js # combine the layers in http mode mcpsnoop http --target http://localhost:3000/mcp --redact-secrets --redact-value 'Bearer\s+\S+'

Señal	Falla en
`error`	una llamada respondida con un error JSON-RPC, un resultado marcado como `isError`, o una tarea que terminó en un fallo
`invalid`	un frame en el canal de protocolo que no es JSON-RPC válido, normalmente un servidor registrando en stdout
`warn`	un frame que rompe una expectativa establecida por la especificación MCP o JSON-RPC
`mismatch`	un encabezado de enrutamiento que discrepa con el cuerpo, que monta un lote, o que falta donde la revisión lo requiere
`pending`	una solicitud aún abierta cuando terminó la captura, por lo que el llamador quedó esperando
`late-result`	una respuesta que llegó después de que su solicitud fuera cancelada
`drift`	una definición de herramienta anunciada que cambia después de que la línea base fue aprobada
`deprecated`	una característica que la especificación ha marcado como obsoleta
`incomplete`	frames descartados aguas arriba, lo que convierte cada otro conteo en un mínimo en lugar de un total
`schema`	un esquema anunciado que usa una construcción o un dialecto que viaja mal entre clientes

Bandera	Falla cuando
`--max-duration <dur>`	una o más llamadas de herramienta completadas superaron el presupuesto, informando su recuento y la peor llamada
`--expect-tool <name>`	la herramienta nombrada nunca fue llamada (repetible)
`--forbid-tool <name>`	la herramienta nombrada fue llamada (repetible)

Regla	Se informa como
el cliente DEBE enviar un `Accept` que liste tanto `application/json` como `text/event-stream`	`warn` en la solicitud
un servidor que responde a una solicitud JSON-RPC DEBE devolver `Content-Type: application/json` o `text/event-stream`	`warn` en la respuesta

mcpsnoop

Más Populares

En CI

Archivo de configuración

Go```bash

Completado de shell

Cómo funciona

Exportando sesiones

Redacción

Comparar sesiones

Afirmar lo que debe y no debe ocurrir

a contract for the run: search must run, delete must not, nothing over 2s

La GitHub Action

Detectar un encabezado de enrutamiento que no coincide con el cuerpo

Comprobar los encabezados de transporte que la especificación hace obligatorios

Detectar deriva en las definiciones de herramientas

Cómo funciona

Uso

Argumentos

Ejemplo

Marcar características de protocolo obsoletas

Reproducir una llamada capturada a través de HTTP

Encuentra la herramienta que falla una de cada cuatro ejecuciones

Ver qué servidores han ejecutado realmente aquí

Vea cuánto le cuesta el servidor en contexto

a non-Linux or custom home, macOS is /Users/ and root is /root

an explicit MCPSNOOP_HOME on the remote

an explicit XDG_STATE_HOME on the remote

copy the remote logs into your local sessions directory

open the TUI, it backfills the copied sessions

Contribución

Licencia