上个月写 MCP Server 的时候遇到一个让我抓狂的问题本地 stdio 模式跑得好好的一切换到 Streamable HTTP 模式就报错——工具调用返回的数据残缺不全。不是网络断连不是 JSON 格式错误就是少了一段数据。一开始我的调试方式很原始在代码里到处塞 console.log重启服务再调一次看日志。折腾了半个小时除了把代码搞得乱七八糟之外毫无进展。后来同事甩了一句「你用 MCP Inspector 了吗」我说那是什么东西。他说你连这个都不知道就敢写 MCP Server好今天就来聊聊这个被我严重低估的工具。MCP Inspector 到底是干嘛的官方文档的说法是「MCP 交互式调试工具」但我更愿意叫它 MCP Server 的 Postman。你不需要写客户端代码不需要启动 Claude Code直接在浏览器里就能对你的 MCP Server 发起各种调用——列工具、读资源、调方法全部可视化。安装就一行命令npx modelcontextprotocol/inspector node your-server.js它会启动一个 Web 界面默认http://localhost:5173背后自动连上你的 MCP Server。所有 JSON-RPC 交互在界面里一目了然。第一个用处验证 Server 能不能正常握手我刚写完一个 Server 的时候常犯的错误是忘记了在capabilities里声明支持的功能。比如写了 tools 但是没在 Server 初始化响应里加tools: {}标记——结果 Claude Code 加载了 Server 但永远不调用工具因为它以为这个 Server 没有工具。用 Inspector 连上之后看一眼Inspector 左侧的 Server 信息面板。如果能正常显示 Server 名称和 capabilities 列表说明初始化握手没问题。如果显示不出来——检查你的Server构造函数和connect调用。// 我踩过的坑capabilities 没声明 tools const server new Server({ name: my-db-server, version: 1.0.0, // ❌ 忘了加 capabilities }) // ✅ 正确写法 const server new Server({ name: my-db-server, version: 1.0.0, capabilities: { tools: {}, // 声明支持工具调用 resources: {}, // 声明支持资源读取 } })第二个用处直接看 tools/list 返回了啥Inspector 左侧有个ToolsTab点一下它会自动发送tools/list请求并把返回的工具列表渲染成可点击的卡片。每个工具的 name、description、inputSchema 都展示在上面。有次我写了一个数据库查询工具description 写得太简略tools: [{ name: query_database, description: 查询数据库, inputSchema: { type: object, properties: { sql: { type: string } } } }]结果 LLM 根本不知道怎么用——它不知道这个工具能查哪些表参数应该传什么格式。后来我把 inputSchema 的参数描述写得详细了效果立竿见影。Inspector 的好处是你写完工具定义后立刻能看到它在客户端眼里长什么样。不用等到集成测试才发现问题。第三个用处模拟工具调用看原始响应这是我最常用的功能。Inspector 的Tools → Call Tool面板里可以直接填参数发起tools/call请求返回的原始 JSON 响应全显示在右边。回到文章开头的问题——那个 Streamable HTTP 模式下数据残缺的 Bug我就是在 Inspector 里重现的// Inspector 里看到的响应 { jsonrpc: 2.0, id: 1, result: { content: [ { type: text, text: 部分数据... } ] } // isError 字段没有但数据就是不全 }反复试了几次后发现规律数据量大的时候才会丢。后来定位到是 HTTP 响应的Transfer-Encoding: chunked的 buffer 切割导致 JSON 解析不完整。加上Content-Length头之后问题消失。这个场景在 stdio 模式下永远不会出现因为管道通信的语义和 HTTP 不一样。第四个用处检查 Resources 和 Prompts如果你的 MCP Server 实现了 resources 或 prompts 能力Inspector 的对应 Tab 可以直接读取和测试。比如我写了一个读取日志文件的 resourceserver.setRequestHandler(ListResourcesRequestSchema, async () { return { resources: [ { uri: file:///logs/app.log, name: Application Log, mimeType: text/plain, } ] } })在 Inspector 的 Resources Tab 里能看到这个 resource 的 URI点击可以直接发起resources/read请求看内容。这个功能对调试 resource 模板中的动态 URI 特别有用——你可以在 Inspector 里手动构造 URI 参数验证模板解析对不对。第五个用处排查传输层问题MCP 支持 stdio、SSE、Streamable HTTP 三种传输方式。不同传输层的调试方式完全不同stdioInspector 通过子进程启动 Server日志和错误直接在 Inspector 的控制台面板显示SSE/Streamable HTTPInspector 连接远程 URL可以在 Network 面板里看到每个 HTTP 请求的完整往返前阵子帮同事排查一个 SSE 模式下的连接问题Server 启动后客户端能收到endpoint事件但后续的tools/list请求无响应。用 Inspector 的 Network 面板一看——Server 返回的是 HTTP/1.0 协议的响应不兼容 SSE 的 Keep-Alive 要求。查了一圈是 Server 前边挡了一层 Nginx 配置的问题。没有 Inspector这类问题排查的难度直接翻倍。你大概什么时候需要它如果你只是用现成的 MCP Server比如官方提供的 filesystem、sqlite 那些基本用不上 Inspector。但如果你在写自定义 Server或者在生产环境部署远程 MCP 服务Inspector 几乎必备。特别是在开发初期每写一个 tool 就用 Inspector 测一下能省掉后面至少一半的联调时间。对了Inspector 还支持--transport参数指定连接方式# stdio 模式默认 npx modelcontextprotocol/inspector node my-server.js # SSE 模式 npx modelcontextprotocol/inspector --transport sse http://localhost:3001/mcp # Streamable HTTP 模式v2 协议 npx modelcontextprotocol/inspector --transport streamable-http http://localhost:3001/mcp三种传输都支持覆盖了目前主流的 MCP 部署方式。工具本身不复杂但知道它存在和不知道怎么用之间差了好几个加班夜。你说呢。