MCP Inspector: connect servers and test their tools

Your editor offers no useful diagnostic even though an MCP server is configured? A separate protocol client can establish how far the connection actually gets. The MCP Inspector provides an additional checkpoint. Keep the comparison narrow: use the same endpoint or command and record differences in account, environment and arguments. Otherwise you are testing two different setups and producing results that only appear to contradict each other. Start with a small operation that can be repeated.

Start the Inspector and record its version

Current Inspector documentation specifies Node 22.19.0 or newer. It describes browser, command-line and terminal clients. Check node --version and read the requirements for the package version you choose. The following command retrieves or starts the package through npx; it is an instruction, not a test executed by this page.

npx @modelcontextprotocol/inspector

Open the browser address printed by the process on your computer. Current documentation describes a one-time session token in that address; do not publish it as error evidence. Record the Inspector release used for the attempt. The vendor source distinguishes the current v2 line from v1, so older walkthroughs may show different flags and configuration shapes. Keep that version information alongside the server version in your notes.

Match HTTP or stdio to the original client setup

For a public HTTP test, use https://api.tracevero.com/mcp. The command below requests the tool list; it does not call any of the listed operations. tracevero’s interface documentation describes its functions. For your own server, use that provider’s documented address and authentication method.

npx @modelcontextprotocol/inspector --cli https://api.tracevero.com/mcp --transport http --method tools/list

For a local server, the Inspector is another process launcher. Success from your terminal does not prove that an editor sees the same executable path or variables. The ENOENT guide and transport comparison help document those differences. Do not switch transport merely because another option is available in the interface. Match the server’s actual deployment.

Move from tools/list to a verified result

1. Connect the server and record whether initialization succeeds. If it stops, retain a sanitized error message and the last successful stage.

2. Request tools/list. Inspect current tool names and input schemas instead of copying names from an old screenshot.

3. Choose one read operation with an independently known result. For tracevero, use a term from the registry search and fill the arguments specified in the tool schema.

4. Compare the response with your expectation. Then repeat the same operation in the original client. Record both outcomes with endpoint, timestamp and software versions.

Write an actionable failure report

A useful report contains the chosen operation, sanitized input, expected response and observed difference. “The server does not work” leaves it unclear whether the connection failed or a single tool failed. Explicitly state when the tool list was already visible. That saves someone else from repeating every earlier check and provides a clear acceptance condition for a future fix. Limit the example to the smallest input that still shows the problem.

If the inventory is empty, use the missing tools diagnosis. For rejected HTTP requests, follow the 401 and 403 guide. Keep tokens, personal data and local session URLs out of the report. A successful protocol exchange does not establish that every offered operation is suitable, or that every client release supports the same capabilities. Confirm your intended operation in its actual client.

Is a visible tool list already a functional test?

It confirms that the list request succeeded. A specific tool call and its substantive result need separate checks.

Do I have to publish my server?

No. You can inspect a local stdio process on your own machine. Obtain the correct launch instructions from that server.

Why do the Inspector and editor behave differently?

Compare their actual startup conditions first. A different environment or account may explain the result before a client defect is involved.

Does tracevero perform these tests for me automatically?

No. This page is a guide. Registry declarations and published verification reports have separate sources and explicitly stated limits.

Vendor sources checked on 1 October 2026. Test workflows are editorial suggestions.

1. MCP: Inspector reference
   Show retrieval command

   curl -s https://modelcontextprotocol.io/docs/2026-07-28/tools/inspector
2. MCP Inspector: source and version information
   Show retrieval command

   curl -s https://github.com/modelcontextprotocol/inspector

All posts