MCP Inspector: a web, CLI and TUI client for testing Model Context Protocol servers

What MCP Inspector is for, and who actually needs it

The Model Context Protocol defines how a client discovers and calls tools, resources and prompts on a server. That means an MCP server is only as useful as the surface it advertises, and until something connects to it and asks, that surface is invisible. MCP Inspector is the client that asks. It connects to an MCP server and lets you see and exercise what the server exposes, which makes it a debugging tool for server authors rather than a library you embed in an application.

The audience is narrow and specific. If you are writing an MCP server, you need a way to confirm that a tool you registered actually appears in the tool list, that its input schema is what you intended, and that calling it returns what you expect. If you are integrating someone else's server into an agent, you need a way to check the same things before you blame your own client code. The README describes the package as "a developer tool for inspecting Model Context Protocol (MCP) servers", and the three modes map to three working styles: a browser UI for clicking through a server, a CLI for scripting, and a terminal UI for staying in one window.

What it is not is equally worth stating. It is not a server implementation, not a proxy you leave running in front of production traffic, and not a test framework with assertions built in. The repository does ship test-servers/ with composable MCP test servers and fixtures, and docs/test-servers.md describes a showcase config for every feature, but those exist to exercise the Inspector itself, not to serve as your test harness.

One binary, three clients, and a shared core

The package declares a single bin entry, mcp-inspector, pointing at clients/launcher/build/index.js. The launcher is the dispatcher: the README's launcher-config-consolidation-plan doc explains that it runs a client in-process rather than spawning it. So --web, --cli and --tui are three front ends behind one command, and the mode you pick determines which front end the launcher loads.

The repository layout is unusual and worth understanding before you contribute. v2 is explicitly not an npm workspace. Each client under clients/ keeps its own package.json and its own node_modules, and shared code lives in core/, consumed through a build-time alias called @inspector/core. The README states the rule that follows from this: every runtime dependency that core/ imports is declared once, in the repo-root package.json, and each client declares only what that client alone consumes. The stated consequence is that clients/cli and clients/launcher end up with no runtime dependencies of their own.

The three clients differ in stack. The web client is a Vite + React + Mantine single-page app with a Node backend, split into src/ for the browser app and server/ for the Node side. The TUI is built with Ink. The CLI is a tsup bundle that also resolves the @inspector/core alias. Those choices are visible in what you can do with each: the web client is where you click through tools and read rendered output, the CLI is where you pipe JSON into jq, and the TUI is where you keep a session open without a browser.

Installing MCP Inspector and pointing it at a server

The README gives npx as the primary path, and the three invocations select the mode. Running the first command starts the web UI; the other two select the CLI and the terminal UI respectively.

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

If you are working on the Inspector itself rather than using it, the development quick start requires Node >=22.19.0 and runs two commands at the repo root. The first installs across every client through a postinstall cascade, and the second builds the four parts in a fixed order: web, then cli, then tui, then launcher.

npm install          # at the repo root; postinstall cascades into every client
npm run build        # web → cli → tui → launcher

For iteration on the web client specifically, the README recommends running Vite directly instead of going through the launcher, because that gives fast HMR and skips the launcher build.

cd clients/web && npm run dev

The launcher-driven scripts run the built launcher, so the README is explicit that you must build first. npm run web serves the production web launcher against clients/web/dist, and npm run web:dev runs the web launcher in --dev mode against Vite. Which server the Inspector connects to is governed by a config file, and docs/mcp-server-configuration.md is the document that covers the format. The v2 CLI splits --config from --catalog, a change the v1-to-v2 migration guide exists to explain.

Where the Inspector stops being the right tool

The most concrete limitation is the one the Dockerfile states outright. Binding to 0.0.0.0 is refused by default, because doing so exposes the process-spawning backend to the network. A container is treated as the sanctioned exception, and the image opts in explicitly by setting DANGEROUSLY_BIND_ALL_INTERFACES=true alongside HOST=0.0.0.0. The environment variable name is not decoration: the backend spawns processes, so putting it on a reachable interface is a real exposure, and the default refusal is the correct behaviour for a laptop.

A second boundary is versioning. The README describes main as the default branch holding the latest released v2, published to the npm latest tag, while active development happens on v2/main and merges into main at milestone releases. The legacy v1 line lives on v1/main and is described as security fixes only, published straight from that branch to the npm v1-latest tag. If your tooling pins the default npm tag, you are on v2 and subject to the migration guide's changes to CLI flags, the --config versus --catalog split, the Node engine bump, and env-var renames. That is a compatibility cliff, not a gradual deprecation.

Third, the project's own quality gate is heavy, and that matters if you plan to fork or contribute. The README states there is no aggregate root test script; each client self-validates from its own folder and the root scripts chain them. npm run local:gate is described as mandatory before pushing and as a strict superset of GitHub CI, chaining validate, coverage, the verify guards, the smokes and the Storybook tests. The coverage gate is per-file at >=90% for lines, statements, functions and branches. Anyone expecting to patch a small fix and push will meet that gate first. Finally, if what you need is a long-running monitoring probe for a production server, this is the wrong shape of tool: it is a client you run interactively or in CI, not an agent you deploy.

How this differs from calling the server from your own client

The obvious alternative is to skip the Inspector and write a small script against an MCP client SDK, then print the tool list and call the tools you care about. That approach is not wrong, and for a single server with a stable interface it may be less work than learning a config format. The difference in approach is where the knowledge lives. A hand-written script encodes your assumptions about the server: which tools exist, what arguments they take, what a valid response looks like. When the server changes, the script silently keeps passing or silently fails to find what it expected.

The Inspector inverts that. It connects, enumerates, and renders whatever the server advertises, so the discovery step is not something you write. The README's smoke-testing guide describes the workflow as connect, list, call, assert, with --format json for machine-readable output, jq for filtering, an exit-code map for interpreting results, and notes on keeping OAuth non-interactive. That is a thin layer over the same idea as a hand-written script, but the enumeration comes from the server rather than from your expectations.

A second alternative is the web UI alone, treating the CLI as redundant. The difference is repeatability. The web UI is the mode where you see rendered output and click through a server, which is what you want while developing. The CLI is the mode where the same sequence runs headless in CI with a defined exit code, which is what you want after the server is written. The README's mcp-app-review doc describes a CLI-first then one-shot-web recipe for automated App-tool review, which is a fair summary of how the two modes are meant to combine rather than compete.

Maintenance, versions and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-09. Releases have been frequent and close together: 2.4.0 on 2026-08-26, 2.5.0 on 2026-09-02, and 2.6.0 on 2026-09-09. The README's own description of the branch model explains why that cadence looks the way it does: development happens on v2/main, and that branch merges into main at milestone releases, so main is a release branch rather than a working branch.

The upgrade cost is the part to budget for. v1 is security-fixes only and publishes to a separate npm tag, so anyone still on v1 is receiving patches and nothing else. Moving to v2 means reading the migration guide for the CLI flag mapping, the --config versus --catalog split, the Node engine bump, and the env-var renames. The Node requirement of >=22.19.0 is stated in the README's development quick start and is enforced in the Dockerfile, which builds on node:22-slim in both stages. If your CI image is older, that is the first thing to change.

On licensing: the repository's package.json declares "license": "MIT", and the author field reads "The MCP Maintainers and Community". The README does not carry a separate licensing section, and the top-level repository does not list a LICENSE file among its entries, so the package.json field is the declaration available. MIT is permissive, which in practice means the constraints you are most likely to hit are practical rather than legal: the Node engine floor, the v1 versus v2 tag you are resolving, and the fact that the published tarball ships only each client's build output rather than sources. For anything beyond that, read the licence text itself rather than this summary.

Editorial conclusion

Adopt MCP Inspector if you are building or debugging an MCP server and need to see what it actually exposes: the CLI mode with --format json is the piece that fits CI, and the web UI is the piece that fits interactive exploration. Do not adopt it as a runtime component of your own product; it is a developer tool that spawns and connects to servers, and the Dockerfile only permits binding 0.0.0.0 because a container is treated as a sanctioned exception via DANGEROUSLY_BIND_ALL_INTERFACES. Before you commit to it, verify two things: whether you are on the v1 or v2 line, since v1 now receives security fixes only and publishes to the v1-latest npm tag, and whether your Node version satisfies the >=22.19.0 engine requirement that v2 introduced.

Frequently asked questions

Official sources

1. Issues
2. modelcontextprotocol/inspector on GitHub
3. Project website
4. README
5. Releases