Test and debug with the MCP Inspector

Testing and debugging with the MCP Inspector

When you write your first MCP server, the immediate question is: does it work? Do the tools I defined show up? Do they return what I expect? Before plugging it into a real client like Claude Desktop —where an error is hard to see—, there's a tool designed for exactly this: the MCP Inspector. It's the oscilloscope of your server: you connect it, look inside, and confirm that everything responds correctly.

What you'll learn

• What the MCP Inspector is and why it's used before connecting the server to a client.
• How to launch it with npx in a single line, without installing anything permanently.
• What you can do inside it: list tools/resources/prompts, run a tool with input data and see the result, read notifications, and choose the transport.
• The beginner's debugging loop: change code → re-launch → verify.

What the MCP Inspector is, in one sentence

The MCP Inspector is the official visual tool for testing and debugging an MCP server. It opens an interface in your browser where you see —and trigger— everything your server exposes, without needing a full host. Debugging is simply finding out why something isn't doing what you expected; the Inspector puts it right in front of your eyes.

How to launch it (a single line)

No need to install it: npx downloads it and runs it on the fly. The pattern is always the same —you pass it the command that starts your server as if you were typing it yourself:

npx @modelcontextprotocol/inspector <command-to-start-your-server>

For a Python server that uses the stdio transport (the most common when you're starting out):

npx @modelcontextprotocol/inspector python server.py

The Inspector starts your server for you as a subprocess, connects, and opens the interface in your browser (an address like http://localhost:...). If your server lives on the network over HTTP, you don't pass it a command: you choose the HTTP transport in the interface and paste the URL.

What you can do inside it

Once open, the interface has clear panels:

• Tools: you list all the ones your server declares, pick one, fill in its inputs in a form, and run it to see the exact result it returns.
• Resources: you see the data the server exposes and can read it.
• Prompts: you review the prompt templates the server offers.
• Notifications: you read the messages and logs the server emits while it works — key to understanding what happened when something fails.
• Transport: you choose stdio or HTTP depending on where your server runs.

The debugging loop (memorize this rhythm)

This is how you really work when building a server:

1. You change the code of your server (add a tool, fix a piece of data).
2. You re-launch the Inspector (or reconnect) to load the new version.
3. You verify: you list, run with test inputs, and confirm the result.

You repeat that cycle —change → re-launch → verify— until everything responds as you expect. Only then do you connect the server to a real client. Testing first in the Inspector saves you hours of guessing why it "doesn't work" inside Claude.

Key moments in the video

• 9
  — The MCP Inspector in action: how it's launched and how it's used to inspect a server. As you watch, keep the idea of the loop in mind: it's not a one-off demo, it's the daily way of working. Pause and try the same npx command yourself with your own server.

Quick glossary

• MCP Inspector: the official visual tool for testing and debugging an MCP server.
• Debug: finding and fixing why something isn't doing what's expected.
• npx: a Node command that downloads and runs a tool on the fly, without installing it.
• stdio / HTTP: the two transports the Inspector can connect to your server over.
• Tool / Resource / Prompt: the three primitives the server exposes and that you test here.
• Notification: a message or log the server emits while it works.
• Subprocess: a program that another program starts for you (this is how your stdio server runs).

To download

• 📄 Inspector guide — MCP Inspector: quick guide (a 1-page PDF with the launch commands, the panel table, and the debugging loop to keep beside you while you test).

Before you move on

If you take away one idea, let it be this: never connect a server to a client without having tested it first in the Inspector. In the next lesson we build the same type of server in TypeScript (with the official SDK) — and you'll test it again right here, in the Inspector, with your own inputs.