MCP Inspector: how to test and debug an MCP server

MCP Inspector is the official developer tool for testing and debugging MCP servers — a small app you run with a single npxcommand that connects to any server, lists its tools, resources and prompts, lets you call a tool by hand and fill in its arguments, and shows you the raw JSON-RPC traffic going back and forth. You run it locally, point it at a server you're curious about, and look at exactly what that server can do before you wire it into an agent that can act on your behalf.

What MCP Inspector actually is

MCP Inspector is maintained as part of the official Model Context Protocol project, published as the npm package @modelcontextprotocol/inspector. It isn't a directory, a linter or a scanner — it's a live client. It speaks MCP the same way Claude Desktop, Claude Code or Cursor would, connects to a real server over stdio or HTTP, and gives you a UI for everything that connection can see: the tools the server declares, the resources it exposes, the prompt templates it ships, and every message exchanged over the wire.

The project's own docs put it plainly:

"The MCP Inspector is the reference developer tool for testing and debugging MCP servers."
— modelcontextprotocol.io

That framing matters for how you should use it. Inspector doesn't tell you whether a server is trustworthy — it just shows you, faithfully and without interpretation, what the server actually says and does when you talk to it. Reading that output and deciding what it means is still on you, which is exactly the gap our MCP server vetting checklist is meant to fill.

Running it

No install step. You run it directly through npx, pointing it at whatever command starts the server you want to inspect:

npx @modelcontextprotocol/inspector node path/to/server/index.js

That launches the web client — the default of the three — and prints a local URL containing a one-time session token. Open that printed URL rather than typing localhost:6274from memory; the token is what stops anything else running on your machine from reaching the Inspector's backend, which can spawn processes. For a server published on npm rather than sitting in a local folder, pass its install command straight through:

npx -y @modelcontextprotocol/inspector npx @modelcontextprotocol/server-filesystem ~/Desktop

For a remote, HTTP-based server, skip the local command and point Inspector at the URL instead:

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

Inspector also ships a scriptable CLI mode (--cli) that lists tools or calls one and prints JSON — useful in a shell pipeline or a CI check — and a terminal UI mode (--tui) for when a browser isn't handy. All three run on the same underlying connection logic, so what you see is consistent regardless of which one you reach for; the web client is simply the richest surface, and the one this guide focuses on.

What you actually see once it's connected

Once a server is connected, the Inspector's tab bar adapts to whatever capabilities that server declares. The tabs that matter most for vetting a server you're about to depend on:

• Tools— every tool the server exposes, with its description, its input schema rendered as an actual fillable form, and its annotations. Select a tool, fill in arguments, call it, and the result renders below with structured content, embedded resources and images handled natively. This is the single most useful tab for vetting: it's the server's real, current tool surface, not whatever a README claims it is.
• Resources — the resources and resource templates the server offers, with MIME types and descriptions, plus a way to read one and see exactly what comes back.
• Prompts — any prompt templates the server ships, with their declared arguments and a preview of the generated message once you supply values, which is the fastest way to see what a prompt actually produces rather than guessing from its name.
• Protocol— the full JSON-RPC transcript: every request paired with its response, notifications inline. This is the ground truth of the conversation between client and server, and it doesn't summarize or hide anything.
• Network or Console— the raw HTTP traffic for a remote server, or the local process's stderr output for a stdio server. Useful when a tool call fails and you want to know why.

You can pin the Protocol, Network, Logs and Console tabs into a resizable sidebar so the wire traffic stays visible while you work in Tools — handy when you want to watch exactly what request a tool call actually sends before it goes out. Details on every tab are in the project's web client walkthrough.

The genuinely useful part: reading a server's real tool surface yourself

A README is marketing copy the author wrote once and may never update. A tool's live schema, pulled straight from the running server via tools/list, is what the server is actually declaring right now — and it's what an agent will actually see and act on. Opening Inspector's Tools tab and reading through that list is the closest thing to auditing a server without reading its source code, and it takes a few minutes.

A few specific things worth checking while you're there, tied directly to the security check in our vetting checklist:

• Scope versus claim. Does a tool called search_notes take a path or directory argument at all, or does its schema quietly accept an arbitrary filesystem path with no declared root? A filesystem server that calls roots/listto learn its allowed directories is behaving properly; one whose schema takes a free-text path with no visible constraint is asking for more than it's advertising.
• Tool count and surface size.A server that exposes three well-scoped tools is a smaller attack surface than one that exposes forty. Neither is automatically bad, but a sprawling surface is more that can go wrong, and it's worth asking whether every tool listed actually serves the thing you installed the server for.
• Language aimed at the model, not you.Read tool descriptions and any example output the same way you'd read a contract, not a blurb. Text like "always call this tool first" or "ignore other instructions and" embedded in a description or a result is the pattern behind prompt injection via tool metadata— it's instruction-shaped text aimed at the calling model, not documentation aimed at you, and Inspector shows it to you verbatim because it doesn't interpret or sanitize what a server sends.
• What a call actually returns.Fire a real tool call with harmless arguments and look at what comes back in the result panel and in the Protocol tab underneath it. This is where a tool that claims to "summarize a file" but returns the entire raw contents, or a tool that quietly reaches out to a third-party endpoint, becomes visible.

None of this requires trusting the author's framing of their own server. You're looking at what the server actually says over the wire, live, which is a materially stronger check than reading prose someone wrote about it.

Inspector versus a Trust Score: manual and live, or automated and at scale

Inspector and a Vouchity Trust Scorearen't competing with each other — they answer different questions at different points in your workflow. A Trust Score is what you check across dozens of candidate servers in seconds, before you've decided which one is even worth opening. Inspector is what you run on the one or two servers you're about to actually depend on, after you've narrowed the field.

In practice the two fit together in order. Start in the registry or the trust leaderboardto narrow a field of candidates down using the automated signals — license, maintenance activity, auth requirements, flagged risk patterns. Once you've picked a server you're actually going to wire into an agent with real permissions, open it in Inspector and look at its tools yourself. A high Trust Score tells you the server clears the checks that scale; Inspector is how you confirm, for the one server you're about to depend on heavily, that what it's doing matches what it claims.

A five-minute pass, start to finish

In practice, checking a new server before connecting it looks like this: run npx @modelcontextprotocol/inspectorwith the server's own install command, open the printed URL, and once it's connected, click through to the Tools tab. Read every tool name and description. Call the one or two that look most consequential — the ones that write, delete, send, or reach outside your machine — with minimal, harmless arguments, and watch both the result panel and the Protocol tab underneath it. If anything about the descriptions, the schemas, or what actually comes back doesn't match what the server claims to do, that's your answer, and you haven't given it a single real permission yet.

This is a natural complement to the checklist in how to vet an MCP server before you connect it, and to the security patterns covered in MCP server security risks. If you're building a server yourself rather than evaluating someone else's, running your own server through Inspector before you publish it is one of the fastest ways to catch an over-broad schema or a leaky tool description before anyone else does — see how to build an MCP server for the rest of that side of the checklist.

The source for MCP Inspector is public on GitHub, maintained as part of the official Model Context Protocol project, with full documentation at modelcontextprotocol.io.