MCP Inspector

Un outil de développement pour inspecter les serveurs Model Context Protocol (MCP). Il est fourni sous la forme d'un paquet unique, @modelcontextprotocol/inspector, qui propose trois façons d'inspecter un serveur :

• Web — une application monopage Vite + React + Mantine avec un backend Node.
• CLI — un client en ligne de commande scriptable pour l'automatisation, l'intégration continue et les boucles de retour rapides pour les agents.
• TUI — une interface terminal interactive construite avec Ink.

Les trois s'exécutent via un seul binaire global mcp-inspector :

npx @modelcontextprotocol/inspector          # interface web (par défaut)
npx @modelcontextprotocol/inspector --cli    # CLI
npx @modelcontextprotocol/inspector --tui    # TUI

Mise à niveau depuis v1 ? Lisez le guide de migration v1 → v2 — les options CLI, la nouvelle répartition --config vs. --catalog, le changement de version du moteur Node et ce qui n'est plus fourni.

État du dépôt. Il s'agit de la ligne v2 de l'Inspector. Le développement actif se fait sur v2/main (la branche de développement — toutes les PR v2 la ciblent), qui est fusionnée dans main lors des versions jalons ; main est la branche par défaut et contient la dernière v2 publiée, diffusée sur le tag npm latest. L'ancienne ligne v1 vit sur v1/main — corrections de sécurité uniquement, publiées directement depuis cette branche sur le tag npm v1-latest (npx @modelcontextprotocol/inspector@v1-latest). Voir AGENTS.md pour les conventions de branches/tableaux.

Démarrage rapide (développement)

Nécessite Node >=22.19.0.

npm install          # à la racine du dépôt ; le postinstall se propage dans chaque client
npm run build        # web → cli → tui → launcher

Pour l'itération quotidienne sur le web, exécutez Vite directement — HMR rapide, aucune compilation du launcher nécessaire :

cd clients/web && npm run dev

Les scripts pilotés par le launcher exécutent le launcher compilé, donc compilez d'abord :

npm run web        # launcher web de production contre clients/web/dist
npm run web:dev    # launcher web en mode --dev (Vite)

v2 n'est pas un workspace npm — chaque client sous clients/* conserve son propre package.json et node_modules, et le code partagé vit dans core/, consommé via un alias de compilation @inspector/core. Chaque dépendance d'exécution importée par core/ est déclarée une seule fois, dans le package.json à la racine du dépôt, et chaque client ne déclare que ce que ce client consomme seul — sa pile d'interface, ses paquets intégrés au bundler, ses outils de développement — ce qui laisse clients/cli et clients/launcher sans dépendances d'exécution propres. Ce que cela implique pour ajouter une dépendance (racine vs. client, dependencies vs. devDependencies, et les listes external du bundler) est décrit dans la compétence local-dev.

Structure du projet

inspector/
├── clients/
│   ├── web/          Client web (Vite + React + Mantine). src/ = application navigateur ; server/ = backend Node
│   ├── cli/          Client CLI (bundle tsup, alias @inspector/core)
│   ├── tui/          Client TUI (Ink + React, bundle tsup)
│   └── launcher/     Lanceur partagé — fournit le binaire `mcp-inspector`, répartit vers web/cli/tui
├── core/             Code partagé consommé via l'alias `@inspector/core` (pas de package.json)
├── test-servers/     Serveurs MCP de test composables + fixtures utilisés par les tests d'intégration et de fumée
├── scripts/          Outillage racine de compilation/vérification (cascade d'installation, tests de fumée, gardes verify:*)
│                     et automatisation du dépôt exécutée depuis CI (les balayages de dépendances, alertes Dependabot et SDK)
├── docs/             Guides orientés tâches — voir ci-dessous
├── specification/    Spécifications de conception/compilation
├── .claude/skills/   Compétences d'agent : les procédures du dépôt, invocables par nom
├── AGENTS.md         Règles de contribution pour les agents ET les humains
└── README.md         Vous êtes ici

Chaque client a son propre README avec des détails spécifiques au client : web · cli · tui · launcher.

Documentation

Tests et porte de qualité

Chaque client s'auto-valide depuis son propre dossier ; les scripts racine les enchaînent. Il n'existe pas de script test racine agrégé.

npm run validate     # boucle interne rapide : format:check + lint + typecheck + build + tests unitaires
npm run coverage     # la porte par fichier ≥90 % (lignes/instructions/fonctions/branches)
npm run local:gate   # OBLIGATOIRE avant de pousser — un sur-ensemble strict du CI GitHub

npm run local:gate enchaîne chaque vérification ci-dessous, plus les tests de fumée et les tests Storybook. Tests et porte de qualité détient la liste des étapes et explique ce que chacune couvre et pourquoi deux sont locales uniquement ; AGENTS.md contient les règles de test elles-mêmes.

Contribution — AGENTS.md, CLAUDE.md et les compétences

AGENTS.md est le contrat pour modifier cette base de code, et il s'applique aussi bien aux humains qu'aux agents IA. Ce n'est pas un simple gabarit réservé aux agents — il contient les véritables règles du projet : les conventions de versions/étiquettes, les normes TypeScript et Mantine/React, les exigences de test et de couverture, et la porte obligatoire avant poussée. Lisez-le avant d'apporter des modifications, et tenez-le à jour lorsque vous changez la structure, l'outillage ou les règles.

Les procédures du dépôt — recettes en plusieurs étapes avec commandes et identifiants vivants — vivent dans .claude/skills/ à la place, un répertoire par procédure, afin qu'elles ne soient chargées que lorsque la tâche les requiert. Ce sont des Markdown ordinaires validés : un agent qui ne comprend pas les compétences peut les lire, et AGENTS.md porte un index de ce qui existe. Les utilisateurs de Claude Code les invoquent par nom (/release, /issue-triage, …).

CLAUDE.md est le point d'entrée que Claude Code charge automatiquement ; il inclut AGENTS.md, de sorte que les agents et les humains travaillent à partir de la même source de vérité. Si vous utilisez un autre agent qui lit AGENTS.md, vous obtenez les mêmes règles.

Une règle clé mérite d'être soulignée ici : tout travail est piloté par les issues. Avant de commencer, trouvez ou créez une issue de suivi sur le tableau du projet v2 ; ouvrez les PR contre v2/main avec Closes #<issue>. Les contributions externes sont acceptées sous forme d'issues, et non de pull requests — voir CONTRIBUTING.md.

Licence

MIT.