Skip to main content
The MCP Inspector is the reference developer tool for testing and debugging MCP servers. It ships as a single package, @modelcontextprotocol/inspector, providing three clients behind one binary: All three are built on the same shared core, so a connection behaves identically across them: the same transports, the same configuration files, the same OAuth state on disk, and the same protocol-era negotiation (legacy vs. modern 2026-07-28). The package also installs mcpdo, an experimental connection client that connects to a server once and keeps it open across many commands, on the same core.

The MCP Inspector web client after a tool call, with the monitoring sidebar pinned and widened so the JSON-RPC exchange stays readable while you work.

​
Quickstart

The Inspector requires Node 22.19.0 or newer and runs directly through npx. No installation is required:
The command prints a URL carrying a per-launch API token and opens it in your browser (set MCP_AUTO_OPEN_ENABLED=false to stop it opening). See Web client.

​
Inspecting published servers

Pass the command that launches the server as the Inspector’s arguments, or point it at a remote server with --server-url:
Always read a server’s own README first, since every server requires different commands and arguments.
The Inspector stores secrets (OAuth tokens, OAuth client secrets, and stdio env: values) in the OS keychain when one is available. On a machine with no keychain (Linux without libsecret or a Secret Service, headless and SSH sessions, Termux, and containers with a mounted volume) they are saved to ~/.mcp-inspector/secrets.json instead, unencrypted unless you supply a key. See Where secrets are stored for how to get a keychain back, encrypt the file, or keep secrets in memory only.

​
Launcher flags vs. client flags

mcp-inspector, the binary that npx @modelcontextprotocol/inspector runs, is a thin launcher. It owns only two things:
  1. The mode flag: --web (default), --cli, or --tui. At most one; passing two errors with Specify at most one of --web, --cli, or --tui.
  2. -h / --help.
Everything else (--catalog, --config, --server-url, --transport, --method, the OAuth flags) is defined by the client, not the launcher, and the clients do not all define the same set. The Configuration and flags page is organized that way, by owner.
Mode flags are recognized only at the front of the command line: the first token that isn’t --web / --cli / --tui ends launcher parsing, and everything after it is forwarded to the client unchanged. That’s what lets a literal --cli appear later as one of your server’s own arguments:
--help behaves differently with and without a mode flag. Without one, -h/--help anywhere on the command line (even after a server command) prints the launcher’s help and exits. With a mode flag it is forwarded, so mcp-inspector --cli --help prints the CLI’s full flag reference instead.

​
Where to go next

Web client

A tab-by-tab walkthrough of the graphical inspector.

CLI client

Method reference, output formats, exit codes, and CI recipes.

TUI client

Terminal navigation and keyboard reference.

Configuration and flags

Catalog vs. config files, the full per-client flag reference, and environment variables.

Authorization

The OAuth flow end to end, mid-session re-authorization, and loopback callbacks.

Protocol eras

Legacy vs. modern (2026-07-28) operation, and how every tab changes between protocol eras.

mcpdo connection client

Connect once, then run many commands against a named connection.

Security

The threat model: the web backend’s token, Docker, secret storage, stdio servers, and the mcpdo daemon.

Recipes

Importing client configs, reviewing MCP Apps, Docker, and network hosting.

Debugging guide

Broader debugging strategies beyond the Inspector.