Inspecione, depure e teste visualmente servidores Model Context Protocol (MCP) a partir de uma interface web, CLI ou TUI, com exploração de ferramentas/recursos, registro de requisições e suporte a OAuth.
Uma ferramenta de desenvolvimento para inspecionar servidores Model Context Protocol (MCP). Ela é distribuída como um único pacote, @modelcontextprotocol/inspector, que oferece três formas de inspecionar um servidor:
Todos os três são executados por meio de um único binário global mcp-inspector:
npx @modelcontextprotocol/inspector # web UI (padrão)
npx @modelcontextprotocol/inspector --cli # CLI
npx @modelcontextprotocol/inspector --tui # TUI
Atualizando da v1? Leia o guia de migração v1 → v2 — flags da CLI, a nova divisão
--configvs.--catalog, o aumento da versão do Node engine e o que não é mais incluído.
Status do repositório. Esta é a linha v2 do Inspector. O desenvolvimento ativo acontece em
v2/main(o branch de desenvolvimento — todos os PRs da v2 têm como alvo ele), que é mesclado emmainnos lançamentos de marcos;mainé o branch padrão e contém a v2 mais recente lançada, publicada na tag npmlatest. A linha legada v1 vive emv1/main— apenas correções de segurança, publicadas diretamente desse branch para a tag npmv1-latest(npx @modelcontextprotocol/inspector@v1-latest). ConsulteAGENTS.mdpara convenções de branch/quadro.
Requer Node >=22.19.0.
npm install # na raiz do repositório; o postinstall propaga para todos os clientes
npm run build # web → cli → tui → launcher
Para iteração diária na web, execute o Vite diretamente — HMR rápido, sem necessidade de build do launcher:
cd clients/web && npm run dev
Os scripts orientados pelo launcher executam o launcher compilado, então compile primeiro:
npm run web # launcher web de produção contra clients/web/dist
npm run web:dev # launcher web em modo --dev (Vite)
A v2 não é um workspace npm — cada cliente em clients/* mantém seu próprio package.json e node_modules, e o código compartilhado vive em core/, consumido por meio de um alias de build @inspector/core. Cada dependência de runtime que core/ importa é declarada uma única vez, no package.json da raiz do repositório, e cada cliente declara apenas o que aquele cliente consome isoladamente — sua stack de UI, seus pacotes embutidos pelo bundler, suas ferramentas de desenvolvimento — o que deixa clients/cli e clients/launcher sem dependências de runtime próprias. O que isso significa para adicionar uma dependência (raiz vs. cliente, dependencies vs. devDependencies e as listas external do bundler) está na skill local-dev.
inspector/
├── clients/
│ ├── web/ Cliente web (Vite + React + Mantine). src/ = aplicativo do navegador; server/ = backend Node
│ ├── cli/ Cliente CLI (bundle tsup, alias @inspector/core)
│ ├── tui/ Cliente TUI (Ink + React, bundle tsup)
│ └── launcher/ Launcher compartilhado — fornece o bin `mcp-inspector`, despacha para web/cli/tui
├── core/ Código compartilhado consumido por meio do alias `@inspector/core` (sem package.json)
├── test-servers/ Servidores de teste MCP componíveis + fixtures usados por testes de integração e smoke
├── scripts/ Ferramentas de build/verificação da raiz (cascata de instalação, smokes, guards verify:*)
│ e automação do repositório executada no CI (varreduras de dependências, alertas Dependabot e SDK)
├── docs/ Guias orientados a tarefas — veja abaixo
├── specification/ Especificações de design/build
├── .claude/skills/ Skills de agente: os procedimentos do repositório, invocáveis por nome
├── AGENTS.md Regras de contribuição para agentes E humanos
└── README.md Você está aqui
Cada cliente tem seu próprio README com detalhes específicos do cliente: web · cli · tui · launcher.
| Guia | Abrange |
|---|---|
| Arquitetura | O pacote compartilhado @inspector/core e a abordagem de "componentes burros" + Storybook do cliente web |
| Testes e o portão de qualidade | O que cada script validate / coverage / smoke / verify:* cobre, a divisão GitHub-CI-vs-portão-local e os navegadores suportados |
| Escrevendo uma skill | Como escrever uma descrição de skill que realmente dispara, e casos de avaliação que a medem — os formatos de caso que funcionam e o ciclo de ajuste |
| Servidores de teste | Os servidores de teste componíveis e a configuração de demonstração para cada recurso — o que executar, o que clicar e o que o build quebrado fez |
| Publicação | O que é incluído no tarball, os invariantes de empacotamento e pack:verify |
| Docker | Executando a imagem do contêiner — portas, volumes e onde os segredos vão |
| Migrando da v1 para a v2 | Mapeamento de flags da CLI, --config vs. --catalog, o aumento da versão do Node engine, renomeações de variáveis de ambiente |
| Configuração do servidor MCP | A qual(is) servidor(es) o Inspector se conecta e o formato do arquivo de configuração |
| Revisando um aplicativo MCP | A receita CLI-primeiro → web-de-uma-vez para revisão automatizada de ferramentas de aplicativos |
Cada cliente se autovalida a partir de sua própria pasta; os scripts da raiz os encadeiam. Não existe um script test agregado na raiz.
npm run validate # loop interno rápido: format:check + lint + typecheck + build + testes unitários
npm run coverage # o portão por arquivo de ≥90% (linhas/declarações/funções/ramos)
npm run local:gate # OBRIGATÓRIO antes de enviar — um superconjunto estrito do GitHub CI
npm run local:gate encadeia todas as verificações abaixo, além dos smokes e dos testes Storybook. Testes e o portão de qualidade é o dono da lista de etapas e explica o que cada uma cobre e por que duas são apenas locais; AGENTS.md contém as próprias regras de teste.
AGENTS.md, CLAUDE.md e as skillsAGENTS.md é o contrato para alterar este código-base, e se aplica igualmente a humanos e agentes de IA. Não é um boilerplate apenas para agentes — contém as regras reais do projeto: as convenções de versão/rótulo, os padrões TypeScript e Mantine/React, os requisitos de teste e cobertura e o portão obrigatório antes do push. Leia-o antes de fazer alterações e mantenha-o atualizado quando mudar estrutura, ferramentas ou regras.
Os procedimentos do repositório — receitas de várias etapas com comandos e IDs ativos — vivem em .claude/skills/ em vez disso, um diretório por procedimento, para que sejam carregados apenas quando a tarefa os exigir. São Markdown comum versionado: um agente que não entende skills pode lê-los, e AGENTS.md carrega um índice do que existe. Usuários do Claude Code os invocam por nome (/release, /issue-triage, …).
CLAUDE.md é o ponto de entrada que o Claude Code carrega automaticamente; ele inclui AGENTS.md, então agentes e humanos trabalham a partir da mesma fonte de verdade. Se você usa um agente diferente que lê AGENTS.md, obtém as mesmas regras.
Uma regra importante que vale destacar aqui: todo trabalho é orientado por issues. Antes de começar, encontre ou crie uma issue de rastreamento no quadro do projeto v2; abra PRs contra v2/main com Closes #<issue>. Contribuições externas são aceitas como issues, não pull requests — veja CONTRIBUTING.md.
MIT.
| Teste smoke de um servidor MCP | O fluxo de trabalho conectar → listar → chamar → afirmar para um shell ou job de CI: --format json + jq, o mapa de códigos de saída e como manter o OAuth não interativo |
| Consolidação do launcher e da configuração | Por que o launcher executa um cliente em processo em vez de gerá-lo |