inspector v2.6.0
Inspecciona, depura y prueba visualmente servidores del Model Context Protocol (MCP) desde una interfaz web, CLI o TUI, con exploración de herramientas/recursos, registro de solicitudes y soporte de OAuth.
MCP Inspector
Una herramienta de desarrollo para inspeccionar servidores Model Context Protocol (MCP). Se distribuye como un único paquete, @modelcontextprotocol/inspector, que ofrece tres formas de inspeccionar un servidor:
- Web — una aplicación de una sola página Vite + React + Mantine con un backend Node.
- CLI — un cliente de línea de comandos programable para automatización, CI y bucles rápidos de retroalimentación de agentes.
- TUI — una interfaz de terminal interactiva construida con Ink.
Las tres se ejecutan a través de un único binario global mcp-inspector:
npx @modelcontextprotocol/inspector # web UI (default)
npx @modelcontextprotocol/inspector --cli # CLI
npx @modelcontextprotocol/inspector --tui # TUI
¿Actualizando desde v1? Lee la guía de migración v1 → v2 — los flags de CLI, la nueva división
--configvs.--catalog, el aumento de la versión del motor Node y lo que ya no se incluye.
Estado del repositorio. Esta es la línea v2 del Inspector. El desarrollo activo ocurre en
v2/main(la rama de desarrollo — todos los PR de v2 apuntan a ella), que se fusiona enmainen los lanzamientos de hitos;maines la rama predeterminada y contiene la última v2 publicada, publicada en la etiqueta npmlatest. La línea heredada v1 vive env1/main— solo correcciones de seguridad, publicadas directamente desde esa rama a la etiqueta npmv1-latest(npx @modelcontextprotocol/inspector@v1-latest). ConsultaAGENTS.mdpara conocer las convenciones de ramas/tableros.
Inicio rápido (desarrollo)
Requiere Node >=22.19.0.
npm install # en la raíz del repositorio; postinstall se propaga a cada cliente
npm run build # web → cli → tui → launcher
Para la iteración diaria de web, ejecuta Vite directamente — HMR rápido, sin necesidad de compilar el launcher:
cd clients/web && npm run dev
Los scripts controlados por el launcher ejecutan el launcher compilado, así que compila primero:
npm run web # launcher web de producción contra clients/web/dist
npm run web:dev # launcher web en modo --dev (Vite)
v2 no es un workspace de npm — cada cliente bajo clients/* mantiene su propio package.json y node_modules, y el código compartido vive en core/, consumido mediante un alias de tiempo de compilación @inspector/core. Cada dependencia de tiempo de ejecución que core/ importa se declara una sola vez, en el package.json de la raíz del repositorio, y cada cliente declara solo lo que ese cliente consume individualmente — su stack de UI, sus paquetes integrados por el bundler, sus herramientas de desarrollo — lo que deja a clients/cli y clients/launcher sin dependencias de tiempo de ejecución propias. Lo que eso significa para añadir una dependencia (raíz vs. cliente, dependencies vs. devDependencies, y las listas external del bundler) está en la habilidad local-dev.
Estructura del proyecto
inspector/
├── clients/
│ ├── web/ Cliente web (Vite + React + Mantine). src/ = aplicación de navegador; server/ = backend Node
│ ├── cli/ Cliente CLI (bundle tsup, alias @inspector/core)
│ ├── tui/ Cliente TUI (Ink + React, bundle tsup)
│ └── launcher/ Launcher compartido — proporciona el bin `mcp-inspector`, despacha a web/cli/tui
├── core/ Código compartido consumido mediante el alias `@inspector/core` (sin package.json)
├── test-servers/ Servidores MCP de prueba componibles + fixtures usados por pruebas de integración y smoke
├── scripts/ Herramientas de compilación/verificación raíz (cascada de instalación, smokes, guards verify:*)
│ y automatización del repositorio ejecutada desde CI (los barridos de dependencias, alertas de Dependabot y SDK)
├── docs/ Guías orientadas a tareas — ver más abajo
├── specification/ Especificaciones de diseño/compilación
├── .claude/skills/ Habilidades de agente: los procedimientos del repositorio, invocables por nombre
├── AGENTS.md Reglas de contribución para agentes Y humanos
└── README.md Estás aquí
Cada cliente tiene su propio README con detalles específicos del cliente: web · cli · tui · launcher.
Documentación
| Guía | Cubre |
|---|---|
| Arquitectura | El paquete compartido @inspector/core, y el enfoque de "componentes tontos" + Storybook del cliente web |
| Pruebas y el control de calidad | Qué cubre cada script validate / coverage / smoke / verify:*, la división GitHub-CI-vs-puerta-local, y los navegadores compatibles |
| Escribir una habilidad | Cómo escribir una descripción de habilidad que realmente se active, y casos de evaluación que la miden — las formas de caso que funcionan, y el bucle de ajuste |
| Servidores de prueba | Los servidores de prueba componibles y la configuración de demostración para cada característica — qué ejecutar, qué hacer clic, y qué hizo la compilación rota |
| Publicación | Qué se incluye en el tarball, los invariantes de empaquetado, y pack:verify |
| Docker | Ejecutar la imagen de contenedor — puertos, volúmenes, y dónde van los secretos |
| Migración de v1 a v2 | Mapeo de flags de CLI, --config vs. --catalog, el aumento del motor Node, renombres de variables de entorno |
| Configuración del servidor MCP | A qué servidor(es) se conecta el Inspector, y el formato del archivo de configuración |
| Revisión de una App MCP | La receta CLI-primero → web-de-una-sola-vez para revisión automatizada de herramientas de App |
| Pruebas smoke de un servidor MCP | El flujo de trabajo conectar → listar → llamar → afirmar para un trabajo de shell o CI: --format json + jq, el mapa de códigos de salida, y mantener OAuth no interactivo |
| Consolidación del launcher y la configuración | Por qué el launcher ejecuta un cliente en proceso en lugar de generarlo |
Pruebas y el control de calidad
Cada cliente se autovalida desde su propia carpeta; los scripts raíz los encadenan. No existe un script raíz agregado test.
npm run validate # bucle interno rápido: format:check + lint + typecheck + build + pruebas unitarias
npm run coverage # la puerta por archivo ≥90% (líneas/sentencias/funciones/ramas)
npm run local:gate # OBLIGATORIO antes de hacer push — un superconjunto estricto de GitHub CI
npm run local:gate encadena cada verificación a continuación, además de los smokes y las pruebas de Storybook. Pruebas y el control de calidad es dueño de la lista de etapas y explica qué cubre cada una y por qué dos son solo locales; AGENTS.md contiene las reglas de prueba en sí.
Contribuir — AGENTS.md, CLAUDE.md, y las habilidades
AGENTS.md es el contrato para cambiar este código base, y se aplica tanto a humanos como a agentes de IA por igual. No es un texto genérico solo para agentes — contiene las reglas reales del proyecto: las convenciones de versión/etiquetas, los estándares de TypeScript y Mantine/React, los requisitos de prueba y cobertura, y la puerta obligatoria previa al push. Léelo antes de hacer cambios, y mantenlo actualizado cuando cambies estructura, herramientas o reglas.
Los procedimientos del repositorio — recetas de varios pasos con comandos e IDs en vivo — viven en .claude/skills/ en su lugar, un directorio por procedimiento, para que se carguen solo cuando la tarea los requiera. Son Markdown ordinario confirmado: un agente que no entiende habilidades puede leerlos, y AGENTS.md lleva un índice de lo que existe. Los usuarios de Claude Code los invocan por nombre (/release, /issue-triage, …).
CLAUDE.md es el punto de entrada que Claude Code carga automáticamente; incluye AGENTS.md, de modo que agentes y humanos trabajan desde la misma fuente de verdad. Si usas un agente diferente que lee AGENTS.md, obtienes las mismas reglas.
Una regla clave que vale la pena destacar aquí: todo el trabajo está impulsado por issues. Antes de comenzar, encuentra o crea un issue de seguimiento en el tablero del proyecto v2; abre PRs contra v2/main con Closes #<issue>. Las contribuciones externas se aceptan como issues, no pull requests — consulta CONTRIBUTING.md.
Licencia
MIT.