MCP100 verdict
Recommended official testing and debugging tool for inspecting MCP server capabilities and exercising requests during development.
MCP100 Assessment
Editorial verdict
Reviewed September 11, 2026
Task Fit
Mapped
Specialized workflows
Trust
Reviewed
A dated editorial review is published on the MCP detail page.
Maintenance
Activity observed
A dated repository or package update is available; editorial maintenance review is still pending.
Popularity
Signals available
Visible usage signals are shown for discovery only, not as proof of safety.
Evidence scope
10.9k MCP repository stars
No MCP-specific package metric is stored
Stars observed September 11, 2026 · Downloads observation date unavailable
Publisher activity observed September 11, 2026
Current source snapshot
Source relationship: First-party MCP
Reviewed September 11, 2026
Evidence-backed setup
This profile has type-appropriate, source-backed setup rather than an MCP-server client connector configuration.
Type-appropriate, source-backed setup for this testing debugging profile.
npx @modelcontextprotocol/inspectorCapability
Recommended official testing and debugging tool for inspecting MCP server capabilities and exercising requests during development.
Interactively inspect and exercise server tools, resources, prompts, auth, and Apps.
Scriptable MCP inspection for CI and automated checks.
Interactive terminal interface for MCP server inspection.
Inspector is a testing/debugging client, not a fixed server tool catalog.
Not measured yet
Estimated token footprint of the MCP tool schemas exposed to the agent.
Reviewed access
Review the exact access boundary before connecting this MCP to accounts, credentials, or sensitive data.
Related reviewed MCPs
The solution:** CVE MCP Server gives Claude direct access to 28 security tools across 24 APIs — fronted by the **triage_cve** one-call orchestrator.
Choose this instead if
Choose CVE MCP Server instead if aggregating CVE, exploit, KEV, EPSS, and related security context from the project's supported sources.
Useful as a vulnerability-intelligence triage assistant, but every match and remediation decision should be verified against authoritative advisories.
A Model Context Protocol server for Windows crash dump analysis using WinDbg/CDB
Choose this instead if
Choose MCP Server for WinDbg Crash Analysis instead if opening crash dumps and querying debugger analysis, stacks, modules, and symbols through WinDbg/CDB.
Useful for supervised Windows crash-dump triage where WinDbg/CDB is already part of the debugging workflow.
Investigate Sentry errors, issues, projects, and telemetry.
Choose this instead if
Choose Sentry MCP instead if human-in-the-loop issue, event, trace, and performance investigation.
Investigate Sentry errors, issues, projects, and telemetry.
Model Context Protocol project is listed as First-party MCP in MCP100’s current evidence.
Current official resources:
Original product, capability, tool, and usage documentation from the MCP publisher. Installation sections appear under Install & Agents.
A developer tool for inspecting Model Context Protocol (MCP) servers. It ships as a single package, @modelcontextprotocol/inspector, that provides three ways to inspect a server:
All three run through one global mcp-inspector binary:
npx @modelcontextprotocol/inspector # web UI (default)
npx @modelcontextprotocol/inspector --cli # CLI
npx @modelcontextprotocol/inspector --tui # TUI
Upgrading from v1? Read the v1 → v2 migration guide — CLI flags, the new
--configvs.--catalogsplit, the Node engine bump, and what no longer ships.
Repo status. This is the v2 line of the Inspector. Active development happens on
v2/main(the develop branch — all v2 PRs target it), which is merged intomainat milestone releases;mainis the default branch and holds the latest released v2, published to the npmlatesttag. The legacy v1 line lives onv1/main— security fixes only, published straight from that branch to the npmv1-latesttag (npx @modelcontextprotocol/inspector@v1-latest). SeeAGENTS.mdfor branch/board conventions.
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/ Shared launcher — provides the `mcp-inspector` bin, dispatches to web/cli/tui
├── core/ Shared code consumed via the `@inspector/core` alias (no package.json)
├── test-servers/ Composable MCP test servers + fixtures used by integration and smoke tests
├── scripts/ Root build/verify tooling (install cascade, smokes, the verify:* guards)
│ and repo automation run from CI (the dependency, Dependabot-alert and SDK sweeps)
├── docs/ Task-oriented guides — see below
├── specification/ Design/build specifications
├── .claude/skills/ Agent skills: the repo's procedures, invokable by name
├── AGENTS.md Contribution rules for agents AND humans
└── README.md You are here
Each client has its own README with client-specific detail: web · cli · tui · launcher.
| Guide | Covers |
|---|---|
| Architecture | The @inspector/core shared package, and the web client's "dumb components" + Storybook approach |
| Testing and the quality gate | What each validate / coverage / smoke / verify:* script covers, the GitHub-CI-vs-local-gate split, and the supported browsers |
| Writing a skill | How to write a skill description that actually fires, and eval cases that measure it — the case shapes that work, and the tuning loop |
| Test servers | The composable test servers and the showcase config for every feature — what to run, what to click, and what the broken build did |
| Publishing |
Each client self-validates from its own folder; the root scripts chain them. There is no aggregate root test script.
npm run validate # fast inner loop: format:check + lint + typecheck + build + unit tests
npm run coverage # the per-file ≥90% gate (lines/statements/functions/branches)
npm run local:gate # MANDATORY before pushing — a strict superset of GitHub CI
npm run local:gate chains every check below, plus the smokes and the Storybook tests. Testing and the quality gate owns the stage list and says what each one covers and why two are local-only; AGENTS.md holds the testing rules themselves.
AGENTS.md, CLAUDE.md, and the skillsAGENTS.md is the contract for changing this codebase, and it applies to humans and AI agents alike. It is not agent-only boilerplate — it holds the project's real rules: the version/label conventions, the TypeScript and Mantine/React standards, the testing and coverage requirements, and the mandatory pre-push gate. Read it before making changes, and keep it up to date when you change structure, tooling, or rules.
The repo's procedures — multi-step recipes with commands and live IDs — live in .claude/skills/ instead, one directory per procedure, so they are loaded only when the task calls for them. They are ordinary committed Markdown: an agent that doesn't understand skills can read them, and AGENTS.md carries an index of what exists. Claude Code users invoke one by name (/release, /issue-triage, …).
CLAUDE.md is the entry point Claude Code loads automatically; it includes AGENTS.md, so agents and humans work from the same source of truth. If you use a different agent that reads AGENTS.md, you get the same rules.
A key rule worth surfacing here: all work is issue-driven. Before starting, find or create a tracking issue on the v2 project board; open PRs against v2/main with Closes #<issue>. External contributions are accepted as issues, not pull requests — see CONTRIBUTING.md.
MIT.
What ships in the tarball, the packaging invariants, and pack:verify |
| Docker | Running the container image — ports, volumes, and where secrets go |
| Migrating from v1 to v2 | CLI flag mapping, --config vs. --catalog, the Node engine bump, env-var renames |
| MCP server configuration | Which server(s) the Inspector connects to, and the config file format |
| Reviewing an MCP App | The CLI-first → one-shot-web recipe for automated App-tool review |
| Smoke-testing an MCP server | The connect → list → call → assert workflow for a shell or CI job: --format json + jq, the exit-code map, and keeping OAuth non-interactive |
| Launcher and config consolidation | Why the launcher runs a client in-process rather than spawning it |