MCP Inspector: debug and verify an MCP server

By Stuart · 11 Aug 2026 · 9 min read

The MCP Inspector is the reference tool for testing a Model Context Protocol server by hand. You run npx @modelcontextprotocol/inspector against a server, and it connects, negotiates the protocol, and lets you list and call the server’s tools, resources and prompts while watching the raw JSON-RPC traffic. It is the fastest way to answer “does my server actually do what I think it does” without wiring it into an AI client first.

It ships as one npm package, @modelcontextprotocol/inspector, maintained in the modelcontextprotocol GitHub organisation, with three clients behind one binary: a browser UI, a scriptable CLI, and a terminal UI. All three share the same core, so a connection behaves the same way whichever you pick. The current release is 2.1.0, published on 5 August 2026.

VerifyMCP runs automated checks against every server in the official registry that exposes a component. The registry figures later in this post come from those runs, and they mark where automated checking stops and an Inspector session takes over.

What are the three MCP Inspector clients?

Client	Command	Use it for
Web	`npx @modelcontextprotocol/inspector`	The full graphical inspector. The default, and the richest surface.
CLI	`npx @modelcontextprotocol/inspector --cli`	Scripting, CI pipelines, and fast feedback loops for coding agents.
TUI	`npx @modelcontextprotocol/inspector --tui`	An interactive terminal UI, when a browser is unavailable or unwanted.

The binary itself is a thin launcher that owns only the mode flag and --help. Everything else, including --server-url, --transport and --method, belongs to the individual client, and the clients do not all define the same set. Mode flags are recognised only at the front of the command line, which is what lets a literal --cli appear later as one of your own server’s arguments.

The Inspector requires Node 22.19.0 or newer.

How do you run the MCP Inspector against a server?

Point it at the command that launches your server, and the Inspector runs it as a stdio child process:

# A local stdio server
npx @modelcontextprotocol/inspector node path/to/server/index.js

# A published npm server
npx -y @modelcontextprotocol/inspector npx @modelcontextprotocol/server-filesystem ~/Desktop

# A published PyPI server
npx @modelcontextprotocol/inspector uvx mcp-server-git --repository ~/code/mcp/servers.git

# A remote HTTP server
npx @modelcontextprotocol/inspector --server-url https://api.example.com/mcp --transport http

--transport accepts stdio, sse or http. Launching with no target at all is also valid; you then add servers from within the UI.

Two flags decide where the server list comes from, and the difference matters. --catalog <path> is the Inspector’s own writable server list, defaulting to ~/.mcp-inspector/mcp.json, created and seeded if it does not exist. --config <path> is read-only: it is served as-is, never written or migrated, and errors rather than seeding if the file is missing. Use --config when pointing the Inspector at a file you did not write, such as one checked into a repository, because it guarantees the Inspector will not touch it.

How do you use the MCP Inspector in CI?

The CLI client is the scriptable surface, and it is the one worth wiring into a pipeline. It takes a --method and prints machine-readable output:

# List a server's tools and exit
npx @modelcontextprotocol/inspector --cli node path/to/server/index.js --method tools/list

# Call a tool and pipe the result into jq
npx @modelcontextprotocol/inspector --cli https://api.example.com/mcp --transport http \
  --method tools/call --tool-name get_weather --tool-arg city=Boston --format json | jq .result

The main invocation flags are --method, --tool-name, --tool-arg, --tool-args-json, --uri, --prompt-name, --prompt-args and --log-level, with --connect-timeout and --format controlling how the call runs. The CLI reference has the full set, including the stored-auth flags.

A tools/list in CI is a cheap regression test: it fails when your server stops starting, stops negotiating, or drops a tool you meant to keep. It is not a substitute for testing the tools themselves. For where that fits in a wider pipeline, see how to test MCP servers.

Is the MCP Inspector safe to run?

Run 0.16.6 or newer and you clear both of the advisories filed against it. The current 2.1.0 release is well past that floor. The two advisories are worth knowing about anyway, because they explain why the tool behaves the way it does today.

CVE-2025-49596, published 13 June 2025, carried a CVSS 4.0 base score of 9.4, critical (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H). Every version below 0.14.1 was affected. In the advisory’s own words, those versions were “vulnerable to remote code execution due to lack of authentication between the Inspector client and proxy, allowing unauthenticated requests to launch MCP commands over stdio.”

The practical consequence was that a developer merely visiting a malicious web page, while an Inspector session was running locally, could have arbitrary commands executed on their machine. The UI:P in that vector is passive user interaction: no click on anything suspicious was required. Per Oligo’s write-up of the disclosure, the 0.14.1 fix added origin validation against DNS rebinding and a session token check on the proxy. The GitHub advisory is GHSA-7f8r-222p-6f5g.

CVE-2025-58444, published 8 September 2025, is the one more likely to matter to you, and it is the reason 0.14.1 is not a sufficient floor. Rated 8.6, high (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N), it is titled “MCP Inspector is Vulnerable to Potential Command Execution via XSS When Connecting to an Untrusted MCP Server”, and it affected everything below 0.16.6.

The trigger is pointing the Inspector at a server you do not trust, which is a common reason to reach for it in the first place. Until 0.16.6, evaluating an unknown server exposed the machine running the evaluation.

That history is why the modern Inspector prints a URL containing a one-time session token rather than a bare localhost address, and why several environment variables are named the way they are:

Variable	Effect
`MCP_INSPECTOR_API_TOKEN`	Pin the session token instead of generating a random one per launch.
`DANGEROUSLY_OMIT_AUTH`	Disable the `/api/*` token check entirely.
`DANGEROUSLY_BIND_ALL_INTERFACES`	Required opt-in before the backend will bind a wildcard host such as `0.0.0.0`.
`HOST`	Bind host. Defaults to `localhost`.
`CLIENT_PORT`	Web UI port. Defaults to `6274`.
`ALLOWED_ORIGINS`	Comma-separated origin allow-list. Replaces the default list rather than merging with it.

Two related questions come up often enough to answer directly:

Is there an online MCP Inspector? There is no official hosted one. The Inspector launches processes and holds credentials on the machine it runs on, which is the same exposure CVE-2025-49596 described, so a hosted instance carries that exposure by design. It is meant to run locally.

Is there an MCP Inspector VS Code extension? Not an official one. The Inspector maintained in the modelcontextprotocol organisation is an npm package you invoke with npx. Third-party extensions using the same name do exist on the VS Code marketplace, published by unaffiliated vendors, so check the publisher before installing one and do not assume it is the reference tool. What the official Inspector’s web client can do is import an existing client configuration from VS Code, Claude Desktop, Cursor or Cline, or from a registry server.json, so you do not have to hand-write a catalogue entry for a server you already have configured.

Can you run the MCP Inspector in Docker? Yes, and the environment variables above are what make it work. A container needs HOST set to a wildcard so the UI is reachable from outside the container, which in turn requires the explicit DANGEROUSLY_BIND_ALL_INTERFACES opt-in. Keep the token check on and pin it with MCP_INSPECTOR_API_TOKEN rather than reaching for DANGEROUSLY_OMIT_AUTH, publish the port only to 127.0.0.1 on the host, and set ALLOWED_ORIGINS deliberately, remembering that it replaces the default allow-list rather than adding to it. A container is not a security boundary here: the backend still spawns processes and holds tokens, so binding it wide on a shared network gives you the CVE-2025-49596 exposure back by configuration.

What can the Inspector not tell you?

The Inspector answers one question: what does this server do when I talk to it right now? Provenance questions sit outside that scope.

It does not tell you who published the package, whether the artefact you installed was built from the source you read, whether the version you pulled carries a known vulnerability, whether an install script runs on npm install, or whether the maintainer has been absent for two years. Those are supply-chain properties, and talking to a running process does not reveal them. A server can present a clean Inspector session and still fail every one of them.

The second limit runs the other way, and it is where an Inspector session beats an automated probe. An automated probe stops at the login screen. A human with credentials does not.

As of 18 August 2026, 1,487 of the registry’s 12,682 remote components declared a required secret header in their registry entry, and the real auth-gated population is larger, because an endpoint can demand OAuth without declaring a header. From outside, those are close to opaque: we can confirm an endpoint exists and that it challenges properly, and very little else about the tools behind it. The maintainer of one of those servers can point the Inspector at it with a real token and see the entire surface in seconds. That asymmetry does not close, so an inconclusive signal on your own server is a prompt to go and look rather than a verdict.

Spec adoption is worth checking on your own server for the same reason. Of the 13,439 components whose declared revision we could observe on 18 August 2026, 9,148 declared 2025-11-25, one revision behind the current 2026-07-28. Adoption of 2026-07-28 itself stood at 777 components, real but early for a revision published three weeks earlier. The Inspector distinguishes legacy from modern operation, so it reports which revision your server is actually speaking.

Where to go next

Debugging your own server: run the CLI in CI as described above, then read how to test MCP servers for the layers around it.
Shipping it: build a secure MCP server from day one, and claim it with an owners.json.
Evaluating someone else’s: the Inspector shows you behaviour, and the MCP security checklist covers the provenance and supply-chain questions it cannot. You can also look up any registry server in the directory to see how its signals scored.

Running the Inspector against your own server before you publish is cheap, and it answers the behavioural question well. A clean session and a verified server remain separate claims: the first covers what the server does on the wire, the second covers the code and the artefact behind it.

Where to go next

How we score Fix guides Build a secure MCP server