Test an MCP server without an AI: the MCP Inspector command line
When an MCP server misbehaves in Claude Code, Claude Desktop or Cursor, the AI is the worst place to debug it. You can talk to the server directly instead. The MCP project publishes an official tool for this, the Inspector, and its command-line mode can start a server, list its tools, call one, and, most usefully, show the real error when a server fails. We tested it on Windows in September 2026 (Inspector 2.7.0) against the same configs this site generates.
The command that worked every time: point the Inspector at your .mcp.json and name the server. It reads Claude Code's own file as it is.
npx -y @modelcontextprotocol/inspector --cli --config .mcp.json --server context7 --method tools/list
List a server's tools
Replace context7 with the name of any server in your file. The Inspector starts the server, does the MCP handshake and prints the answer as JSON: each tool's name, description, the arguments it accepts, and its read-only hints. That is a quick way to see what an AI will be allowed to do before you connect one.
We ran this against a .mcp.json written by claude mcp add, including its "type": "stdio" and empty "env" fields, with no editing. See the claude mcp add guide for that command.
Call a tool yourself
Add the tool name and its arguments. This asks the Time server to convert 18:30 in Tokyo to Paris time:
npx -y @modelcontextprotocol/inspector --cli --config .mcp.json --server time --method tools/call --tool-name convert_time --tool-arg source_timezone=Asia/Tokyo --tool-arg time=18:30 --tool-arg target_timezone=Europe/Paris
The reply comes back as JSON with "isError": false and the converted time inside. Testing a tool this way separates two questions: does the server work, and does the AI use it well?
See the real error behind "Connection closed"
Claude Code often reports a broken local server as Connection closed, which tells you nothing (see fixing connection errors). The Inspector prints the server's own error output first, then its own summary. We broke four servers on purpose:
| What was wrong | What the Inspector printed |
|---|---|
| Filesystem server, folder doesn't exist | Warning: Cannot access directory C:\path\to\your\project, skipping and Error: None of the specified directories are accessible |
| Package name doesn't exist | npm's own 404 Not Found error for the package |
| Program isn't installed | 'not-a-real-command-xyz' is not recognized as an internal or external command |
| Git server, folder isn't a repository | ERROR:mcp_server_git.server: ... is not a valid Git repository |
All four ended with {"error":{"code":"error","message":"Connection closed"}}, the same vague message, but the lines above it name the cause. You can get the same lines by running the server's command by hand, as the connection guide suggests. The Inspector adds the parts you can't see that way: whether the server completes a handshake, what tools it offers, and what a call returns.
Windows: use the config file, not the command line
You can also write the server command straight after --cli instead of using a config file. On our Windows machine that worked only when the command had no dash-flags. uvx mcp-server-time was fine. npx -y @modelcontextprotocol/server-memory failed, even though the server is healthy, with "The filename, directory name, or volume label syntax is incorrect" and then a 15-second timeout. Adding -- before the command changed the failure to "No servers found in config file". The config-file form avoided all of it. We did not test macOS or Linux, so it may behave differently there.
Limits of what we tested
- We tested servers that need no API key. If a server needs one, set the variable in your terminal first. We did not test whether the Inspector expands
${VAR}references the way Claude Code does. - The Inspector also has a browser interface (run it without
--cli). We only tested the command-line mode. - An AI client can still behave differently from the Inspector, for example in how it asks for permission. A server that works here is proven to start and answer, not proven to be used well.