The server inspector

You just defined two tools on your MCP server. Are they working? The slow way to find out is to wire the server into a client, wire the client into a chatbot, feed the chatbot a prompt, and hope. The fast way is the MCP Inspector — a browser-based UI that launches your server, lists everything it exposes, and lets you invoke tools directly with a form. Use this any time you're iterating on a server without wanting to rebuild the whole client-Claude loop.

Starting the inspector

With your Python environment activated (check the project README for the exact command if you're using UV or a virtualenv), run:

mcp dev mcp_server.py

The mcp dev command comes with the MCP Python SDK. It:

• Starts your server in development mode.
• Opens a local web server on port 6277.
• Prints a URL you can open in a browser to reach the dashboard.

Open the URL and you'll see the MCP Inspector dashboard — a split-pane interface with a "Connect" button on one side and a navigation bar on the other.

A note on the interface. The inspector is actively developed, so the exact look of the UI may drift from any screenshots. The names of the sections — Resources, Prompts, Tools — and the general flow (list things, click one, fill in a form, run it) stay consistent.

Connecting and listing tools

Click Connect in the inspector. This starts your MCP server as a subprocess and establishes the MCP session. Once connected, you'll see navigation for:

• Tools
• Resources
• Prompts
• (and any other features your SDK version supports)

Navigate to Tools, then click List Tools. The inspector sends a ListToolsRequest to your server and renders the result as a list. For the document project you should see two tools:

• read_doc_contents
• edit_document

Each one, when clicked, opens an interactive test form with inputs for every parameter the tool's schema declares. The inspector is literally showing you what Claude would see when it asked your server for a tool list.

Running a tool

Click read_doc_contents. The form shows a single text input for doc_id — labelled with the description you wrote in the Field(description=...) annotation. Type a real document ID from your in-memory store (for example, deposition.md) and click Run Tool.

The inspector sends a CallToolRequest to the server, which executes your function, and the result comes back. You'll see:

• The arguments you supplied.
• The raw result from the tool (the document content, or an error message).
• Any logs the server emitted.

This is the fastest way to verify a tool works. No client, no Claude, no chat loop — just you, the form, and the server.

Chaining tools to verify edits

The real value of the inspector shows up when you chain operations to verify end-to-end behaviour. For the document project:

1. Run read_doc_contents with doc_id=deposition.md. Note the current content.
2. Run edit_document with:
   • doc_id=deposition.md
   • old_str=Angela Smith
   • new_str=Jordan Rivera
3. Run read_doc_contents again with doc_id=deposition.md.

If the edit worked, the content in step 3 shows the replacement. If it didn't, you know exactly where to look — the problem is inside edit_document, not in the client, not in Claude, not anywhere else.

Being able to bisect the bug this cleanly is the entire point of the inspector. Server tools are the hardest to debug when they're wired into a full chat loop because failures there could be caused by the client, the protocol, the prompt, or the tool itself. The inspector removes everything except the tool.

The development loop

With the inspector running, your workflow becomes:

1. Edit your server code in your editor.
2. Restart the inspector (or let hot reloading handle it, depending on SDK version).
3. Re-run the affected tool in the inspector UI.
4. Confirm the result matches expectations.
5. Repeat.

No chatbot restarts. No prompt iteration. No cost of Claude API calls. You can go from "changed the tool function" to "verified the new behaviour" in seconds.

Use the inspector as your primary development loop for MCP servers and only wire up the full client-plus-Claude flow when you need to test how the tool behaves in a real conversation context. Most bugs surface at the server level, and those are the ones the inspector catches cheapest.

Beyond tools

The inspector also covers:

• Resources — the data-access endpoints you'll define in a couple of lessons. Browse direct resources, fill in URI parameters for templated ones, and see the data the server returns.
• Prompts — pre-authored prompt templates, also covered shortly. Select a prompt, fill in its parameters, and see the rendered text.

Whatever you add to your MCP server, the inspector exposes it with minimal ceremony. As your server grows from two tools to ten tools plus resources plus prompts, the inspector scales with it — still just a list of things you can click on and test in isolation.

The next lesson starts implementing the MCP client on the application side, so you can move from inspector-based testing to actually using the server from your CLI chatbot.