MCP Inspector

Ein Entwicklerwerkzeug zur Inspektion von Model Context Protocol (MCP)-Servern. Es wird als ein einziges Paket, @modelcontextprotocol/inspector, ausgeliefert und bietet drei Möglichkeiten, einen Server zu inspizieren:

• Web — eine Vite + React + Mantine-Single-Page-App mit einem Node-Backend.
• CLI — ein skriptbarer Kommandozeilen-Client für Automatisierung, CI und schnelle Agent-Feedback-Schleifen.
• TUI — eine interaktive Terminal-UI, erstellt mit Ink.

Alle drei laufen über eine einzige globale mcp-inspector-Binärdatei:

npx @modelcontextprotocol/inspector          # web UI (default)
npx @modelcontextprotocol/inspector --cli    # CLI
npx @modelcontextprotocol/inspector --tui    # TUI

Upgrade von v1? Lies den v1 → v2-Migrationsleitfaden — CLI-Flags, die neue --config- vs. --catalog-Aufteilung, die Node-Engine-Anhebung und was nicht mehr mitgeliefert wird.

Repo-Status. Dies ist die v2-Linie des Inspectors. Die aktive Entwicklung findet auf v2/main statt (dem Develop-Branch — alle v2-PRs zielen darauf), der bei Meilenstein-Releases in main gemerged wird; main ist der Standard-Branch und enthält das neueste veröffentlichte v2, veröffentlicht auf dem npm-latest-Tag. Die ältere v1-Linie lebt auf v1/main — nur Sicherheitsfixes, direkt von diesem Branch auf den npm-v1-latest-Tag veröffentlicht (npx @modelcontextprotocol/inspector@v1-latest). Siehe AGENTS.md für Branch-/Board-Konventionen.

Schnellstart (Entwicklung)

Erfordert Node >=22.19.0.

npm install          # im Repo-Root; postinstall kaskadiert in jeden Client
npm run build        # web → cli → tui → launcher

Für die tägliche Web-Iteration führe Vite direkt aus — schnelles HMR, kein Launcher-Build nötig:

cd clients/web && npm run dev

Die Launcher-gesteuerten Skripte führen den gebauten Launcher aus, also zuerst bauen:

npm run web        # prod web launcher gegen clients/web/dist
npm run web:dev    # web launcher im --dev-Modus (Vite)

v2 ist kein npm-Workspace — jeder Client unter clients/* hat seine eigene package.json und node_modules, und gemeinsamer Code lebt in core/, konsumiert über einen @inspector/core-Buildzeit-Alias. Jede Laufzeit-Abhängigkeit, die core/ importiert, wird einmal deklariert, in der package.json im Repo-Root, und jeder Client deklariert nur das, was dieser Client allein konsumiert — seinen UI-Stack, seine bundler-inline-Pakete, seine Dev-Tools — wodurch clients/cli und clients/launcher keine eigenen Laufzeit-Abhängigkeiten haben. Was das für das Hinzufügen einer Abhängigkeit bedeutet (Root vs. Client, dependencies vs. devDependencies und die Bundler-external-Listen), steht im local-dev-Skill.

Projektstruktur

inspector/
├── clients/
│   ├── web/          Web-Client (Vite + React + Mantine). src/ = Browser-App; server/ = Node-Backend
│   ├── cli/          CLI-Client (tsup-Bundle, @inspector/core-Alias)
│   ├── tui/          TUI-Client (Ink + React, tsup-Bundle)
│   └── launcher/     Gemeinsamer Launcher — stellt die `mcp-inspector`-Bin bereit, leitet an web/cli/tui weiter
├── core/             Gemeinsamer Code, konsumiert über den `@inspector/core`-Alias (keine package.json)
├── test-servers/     Komponierbare MCP-Testserver + Fixtures, die von Integrations- und Smoke-Tests verwendet werden
├── scripts/          Root-Build-/Verify-Tooling (Install-Kaskade, Smokes, die verify:* Guards)
│                     und Repo-Automatisierung, die von CI ausgeführt wird (die Dependency-, Dependabot-Alert- und SDK-Sweeps)
├── docs/             Aufgabenorientierte Leitfäden — siehe unten
├── specification/    Design-/Build-Spezifikationen
├── .claude/skills/   Agent-Skills: die Prozeduren des Repos, per Name aufrufbar
├── AGENTS.md         Beitragsregeln für Agenten UND Menschen
└── README.md         Du bist hier

Jeder Client hat sein eigenes README mit client-spezifischen Details: web · cli · tui · launcher.

Dokumentation

Testen und das Qualitätsgate

Jeder Client validiert sich selbst aus seinem eigenen Ordner; die Root-Skripte verketten sie. Es gibt kein aggregiertes Root-test-Skript.

npm run validate     # schnelle innere Schleife: format:check + lint + typecheck + build + Unit-Tests
npm run coverage     # das Pro-Datei-≥90%-Gate (lines/statements/functions/branches)
npm run local:gate   # PFLICHT vor dem Pushen — eine strikte Obermenge von GitHub CI

npm run local:gate verkettet jede der untenstehenden Prüfungen, plus die Smokes und die Storybook-Tests. Testen und das Qualitätsgate besitzt die Stufenliste und erklärt, was jede abdeckt und warum zwei nur lokal sind; AGENTS.md enthält die Testregeln selbst.

Beitragen — AGENTS.md, CLAUDE.md und die Skills

AGENTS.md ist der Vertrag für Änderungen an dieser Codebasis und gilt gleichermaßen für Menschen und KI-Agenten. Es ist kein reiner Agent-Boilerplate — es enthält die echten Regeln des Projekts: die Versions-/Label-Konventionen, die TypeScript- und Mantine/React-Standards, die Test- und Coverage-Anforderungen und das obligatorische Pre-Push-Gate. Lies es, bevor du Änderungen vornimmst, und halte es aktuell, wenn du Struktur, Tooling oder Regeln änderst.

Die Prozeduren des Repos — mehrstufige Rezepte mit Befehlen und Live-IDs — leben stattdessen in .claude/skills/, ein Verzeichnis pro Prozedur, sodass sie nur geladen werden, wenn die Aufgabe sie erfordert. Es sind gewöhnliches, committetes Markdown: Ein Agent, der Skills nicht versteht, kann sie lesen, und AGENTS.md führt einen Index dessen, was existiert. Claude-Code-Nutzer rufen einen per Namen auf (/release, /issue-triage, …).

CLAUDE.md ist der Einstiegspunkt, den Claude Code automatisch lädt; es bindet AGENTS.md ein, sodass Agenten und Menschen aus derselben Quelle der Wahrheit arbeiten. Wenn du einen anderen Agenten verwendest, der AGENTS.md liest, erhältst du dieselben Regeln.

Eine Schlüsselregel, die hier erwähnenswert ist: Alle Arbeit ist issue-getrieben. Bevor du beginnst, finde oder erstelle ein Tracking-Issue auf dem v2-Projektboard; öffne PRs gegen v2/main mit Closes #<issue>. Externe Beiträge werden als Issues, nicht Pull Requests akzeptiert — siehe CONTRIBUTING.md.

Lizenz

MIT.