Home » MCP Servers » Debug with Inspector

How to Debug MCP Servers with the Inspector Tool

The MCP Inspector is a standalone debugging tool that connects to your MCP server and lets you browse registered capabilities, invoke tools with test parameters, and inspect the raw protocol messages. It isolates your server from the AI client, so you can verify that tools work correctly before debugging the full integration chain.

Before You Start

You need Node.js installed (for running the Inspector via npx) and a working MCP server. The Inspector works with both stdio and HTTP servers. No installation is required beyond Node.js; npx downloads and runs the Inspector on demand.

Step-by-Step Debugging

Step 1: Install and run the Inspector.
Launch the Inspector against your server. For stdio servers, pass the command that starts your server. For HTTP servers, pass the URL. The Inspector opens a web interface in your browser where you can interact with the server.

For a stdio server:

npx @modelcontextprotocol/inspector python server.py

For an HTTP server:

npx @modelcontextprotocol/inspector --url https://mcp.example.com/mcp

The Inspector starts and displays a URL (typically http://localhost:6274) that opens the debugging interface. If the connection succeeds, you see the server name, version, and a summary of registered capabilities. If the connection fails, the Inspector shows the error, which is your first debugging clue.

Step 2: Verify tool registration.
Navigate to the Tools tab. Each registered tool appears with its name, description, and parameter schema. Check that every tool you expect to see is listed. Missing tools usually mean one of three things: the tool registration code has a bug (syntax error or exception during registration), the tool function was not imported or decorated correctly, or the server crashed during initialization before reaching that tool's registration.

For each tool, verify:

Step 3: Test tool invocations.
Click on a tool to open the invocation panel. Enter test parameters in the form fields and click Invoke. The Inspector sends the request to your server and displays the raw response, including the content blocks, any error flags, and the response time. Test each tool with valid parameters first, then test with edge cases: missing optional parameters, empty strings, very large inputs, and invalid values.

Pay attention to the response format. Each tool should return content as an array of typed blocks (usually text). If the response is empty, check your tool handler for early returns or exception handling that swallows the result. If the response contains an error, the error message should be descriptive enough for the AI model to understand what went wrong and try a different approach.

Step 4: Check resources and prompts.
Switch to the Resources tab to verify that your resource URIs resolve correctly and return the expected data. Each resource should have a MIME type, and the content should be readable and useful for an AI model. Then check the Prompts tab to verify that prompt templates expand correctly with test parameters.
Step 5: Diagnose common issues.
If a tool works in the Inspector but fails when called from an AI client, the problem is not in your server. It is in the client configuration, the transport connection, or the model's tool selection logic. This isolation is the Inspector's primary value: it eliminates the server as a variable so you can focus debugging efforts on the right component.

Common Issues and Solutions

Inspector cannot connect to stdio server: The command to start the server is wrong. Try running the exact command from your terminal. Common causes: wrong Python version (python vs python3), missing virtual environment activation, or the script path is relative and the working directory is wrong.

Tools list is empty: The server starts but no tools register. Check for exceptions during startup by adding print statements or logging before and after each tool registration. A single exception can prevent all subsequent registrations.

Tool returns empty response: Your handler function returns None or an empty string. Make sure every code path in the handler returns a value, including error paths. The MCP SDK expects the handler to return content; returning nothing produces an empty response that confuses the model.

Schema does not match expected parameters: The JSON schema generated from your type hints or Zod schema does not match what you intended. In Python, check that your type hints are specific (use str not Any, use int not Union[int, str]). In TypeScript, check that your Zod definitions include .describe() calls for each field.

Tool works with simple inputs but fails with complex ones: Your handler does not handle edge cases. Test with empty strings, very long strings, special characters, and Unicode. If your tool processes JSON, test with nested objects, arrays, and null values. The AI model will eventually send unexpected inputs, so your handlers need to be robust.

Protocol-Level Debugging

The Inspector has a Messages tab that shows the raw JSON-RPC messages exchanged between the Inspector and your server. This is useful for debugging protocol-level issues: malformed responses, incorrect JSON-RPC IDs, missing required fields in the response, or encoding problems. Most developers never need this tab, but when the higher-level debugging does not reveal the problem, the raw messages always do.

Look for: responses with the wrong ID (they do not match the request), responses missing the "result" field, responses with non-standard error formats, and responses that take unusually long (indicating a timeout or blocking operation in your handler).

Integrating Debugging into Development

Keep the Inspector as part of your development workflow. Before committing changes to your MCP server, run the Inspector and verify that all tools still register correctly and return expected results for a quick set of test cases. This takes thirty seconds and catches registration bugs, schema changes, and handler regressions before they reach your AI clients.

For automated testing, you can use the MCP SDK's client library to write unit tests that connect to your server programmatically and invoke tools with known inputs. This provides the same verification as the Inspector but runs in CI/CD pipelines without a browser.

Skip the debugging. Adaptive Recall is a production MCP server that is already tested, monitored, and maintained. Connect and start using memory tools immediately.

Get Started Free