MCP Inspector
About
A developer tool for testing and debugging MCP servers.
Explore
- Interactive web UI for testing MCP servers
- Supports stdio, SSE, and streamable-http transports
- Bearer token authentication with session tokens
- Export server launch configurations as mcp.json
- Real-time adjustable timeout settings
- Persists configuration across sessions
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
MCP InspectorCommand (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
From the repository
Run npx @modelcontextprotocol/inspector to start the UI at http://localhost:6274. To inspect a server from its repository, use npx @modelcontextprotocol/inspector node build/index.js with optional arguments and -e flags for environment variables. A Docker image is also available. Ports can be customized via CLIENT_PORT and SERVER_PORT environment variables.
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"mcp inspector": {
"inspector": {
"command": "npx",
"args": [
"@modelcontextprotocol/inspector"
]
}
}
}
}McpServers
{
"inspector": {
"command": "npx",
"args": [
"@modelcontextprotocol/inspector"
]
}
}A developer tool for inspectingModel Context Protocol(MCP) servers. It ships as a single package,@modelcontextprotocol/inspector, that provides three ways to inspect a server:
- Web— a Vite + React +Mantinesingle-page app with a Node backend.
- CLI— a scriptable command-line client for automation, CI, and fast agent feedback loops.
- TUI— an interactive terminal UI built withInk.
All three run through one globalmcp-inspectorbinary:
npx @modelcontextprotocol/inspector # web UI (default) npx @modelcontextprotocol/inspector --cli # CLI npx @modelcontextprotocol/inspector --tui # TUI
Upgrading from v1?Read thev1 → v2 migration guide— CLI flags, the new--configvs.--catalogsplit, the Node engine bump, and what no longer ships.
Repo status.This is thev2line of the Inspector. Active development happens onv2/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 legacyv1line 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.
v2 isnotan npm workspace. Each client underclients/*keeps its ownpackage.jsonandnode_modules; shared code lives incore/and is consumed via a@inspector/corebuild-time alias (nopackage.jsonof its own). A singlenpm installat the root cascades installs into every client (seeSetup).
inspector/ ├── clients/ │ ├── web/ # Web client (Vite + React + Mantine). src/ = browser app; server/ = Node dev/prod 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) │ ├── auth/ # OAuth: providers, discovery, storage, endpoint overrides, mid-session recovery (browser/node/remote backends) │ ├── client/ # Install-level client config (client.json): browser-safe parse/validate + Node load/save, remote backend, secrets │ ├── json/ # JSON + parameter/argument conversion utilities, and the nullable-union │ │ # schema collapse shared by the web and TUI form builders │ ├── logging/ # Silent pino logger singleton │ ├── mcp/ # InspectorClient runtime, state stores, transports, config import, │ │ # and the RFC 6570 URI-template helpers the web form and TUI expand through │ ├── node/ # Node-only shared helpers: version reader, hostUrl (host normalize/canonicalize + all-interfaces/loopback detection) │ ├── react/ # React hooks over the state stores │ └── storage/ # File I/O helpers for the OAuth persist backends ├── test-servers/ # Composable MCP test servers + fixtures used by integration tests ├── scripts/ # Root build/verify tooling (install cascade, smokes, verify-build-gate, verify-format-coverage, verify-dep-lockstep, pack:verify) ├── docs/ # Task-oriented guides (v1→v2 migration, server configuration, MCP App review, launcher/config plan) ├── specification/ # Design/build specifications ├── AGENTS.md # Contribution rules for agents AND humans (see below) └── README.md # You are here
Each client has its own README with client-specific detail:web·cli·tui·launcher.
- Migrating from v1 to v2— the v1 → v2 map: CLI flag mapping,--configvs.--catalogsemantics with before/after examples, the Node engine bump (>=22.7.5→>=22.19.0), env-var renames, and the sub-packages that no longer ship.
- MCP server configuration— which server(s) the Inspector connects to:--catalogvs.--config, ad-hoc targets, the--separator, the file format and its Inspector-specific per-server fields. Shared by all three clients; the cli and tui READMEs delegate their server-options sections to it.
- Reviewing an MCP App— the CLI-first → one-shot-web recipe for automated App-tool review:--app-infoprobe → deep-link navigate → rendered widget, plus OAuth handoff and proxy support.
- Launcher and config consolidation— why the launcher runs a client in-process rather than spawning it, and how the shared config processor fits in.
npm install # root install; postinstall cascades into every client
- Fresh clone:runnpm installat the repo root.
- After a pull that changes a client's dependencies:re-runnpm installat the root to re-sync every client.
The cascade (scripts/install-clients.mjs) is dev-only — it exits early when the package is installed as a dependency, and the published tarball ships only each client'sbuild/, so end users are unaffected. SetINSPECTOR_SKIP_CLIENT_INSTALL=1to skip it.
Where a dependency is declared.The MCP SDK packages (@modelcontextprotocol/client,core,server,server-legacy,ext-apps) live in therootpackage.jsononly — never in a client's. Node resolution walks up, so the root install is on every client's chain, and the root manifest is already what the published tarball resolves against. Declaring them per client installs a second copy that can drift from the root's, which is how two versions ofext-apps(and of the transitive v1@modelcontextprotocol/sdk) ended up in the tree before[#1970— and a second copy ofclient/coreis the failurevitest.shared.mtscarries adedupeworkaround for. The same root-only placement holds for anything reached solely through root-owned code with no manifest of its own (test-servers/src,core/), andvitest.shared.mtsaliases those to the repo root —expressandyaml, both reached throughtest-servers/src, are the two today.Whether such a package is adependencyor adevDependencyfollows from who consumes it at runtime, not from where it is declared:anythingcore/imports at runtime must be a rootdependency, because the client builds externalize npm packages and a published install resolves them from the root manifest, where devDependencies are absent.expressis test-only and is a devDependency;yamlcurrently sits independencies.viteand@vitejs/plugin-reactare rootdependenciesfor the same reason, not by mistake— they look like build tooling, butclients/web/server/start-vite-dev-server.tsimports them at runtime formcp-inspector --web --dev, andclients/web/tsup.runner.config.tslists both asexternal, so a published install resolves them from the root manifest. Moving them todevDependencieswould break--web --devfor consumers (and the on-demandvite buildinensure-web-build.ts) while passing every local check. It does mean they show up undernpm audit --omit=dev, which is a feature: they really are in the production tree.
For day-to-day web iteration, run Vite directly from the web client (fast HMR, no launcher build needed):
The launcher-driven scripts below run thebuiltlauncher, so build first (npm run build):
…
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
