接入 MCP 工具前 我会先用 Inspector 跑完本地验收
导语：MCP 服务一旦接到 Agent 或桌面客户端，就会变成能读资源、跑工具、触发外部 API 的执行入口。我的习惯是先把它放进 MCP Inspector 里跑一轮本地验收，确认连接、能力声明、输入 schema、样例输出和权限边界都清楚，再写进正式客户端配置。官方文档把 Inspector 定位为交互式开发工具，可直接用 npx @modelcontextprotocol/inspector 启动，并支持检查 npm、PyPI 或本地开发中的服务。
MCP Inspector 验收流程示意图：先启动服务，再检查握手、schema、样例调用和安全边界 来源：Codex image generation
从连接到能力清单
第一步只看服务能否稳定启动。对本地 stdio 服务，我会把命令、参数、工作目录和环境变量写成一份临时启动说明，再在 Inspector 的连接面板里复现。MCP 调试文档提醒，stdio 服务不要把普通日志写到 stdout，因为 stdout 会参与协议通信；日志应走 stderr 或协议里的 log message notification。这个细节能提前暴露很多“命令行能跑，客户端一接就断”的问题。
第二步看能力协商。Inspector 能列出 resources、prompts、tools，并显示工具 schema、描述和执行结果。上线前我会逐个点开高风险工具，检查名称是否具体、描述是否包含副作用、必填参数是否够少、默认值是否合理。JSON schema 里如果有模糊的 object 或无限制字符串，就补枚举、长度、格式或示例，减少模型把自然语言猜成危险参数的机会。
样例调用要留证据
我会把本地验收拆成五项：启动命令可复制，初始化交换成功，能力列表符合预期，至少一次样例调用返回可解释结果，安全边界有书面记录。样例调用不只测成功路径，还要测空参数、越界参数、权限不足和外部 API 超时。官方调试指南也建议在开发周期里用 Inspector 做快速迭代，再到目标客户端里做集成测试。
这里最值得保留的是一份“可复现样例”。例如文件搜索工具可以固定一个只读测试目录，数据库查询工具可以固定一张演示表，云服务工具可以使用低权限测试 token。每次改工具实现或升级 SDK 后，先在 Inspector 里重跑这些样例，再进入 Agent 流程，排障范围会小很多。
安全边界同步看
MCP 安全最佳实践把本地 MCP 服务视为高风险面：启动命令可能执行任意代码，本地服务也可能访问文件、网络和凭据。因此我会在验收记录里写清三件事：服务从哪里安装，启动命令完整长什么样，默认能访问哪些目录和外部域名。需要写文件、发请求或调用云资源的工具，还要给用户确认点、沙箱目录和速率限制。
如果服务使用 HTTP transport，检查项还要增加授权、回环地址限制、会话标识和日志脱敏。对只在桌面本机使用的服务，优先用 stdio 可以缩小暴露面；确实需要 HTTP 时，至少不要把无鉴权端口长期开放在本机。Inspector 的价值在于把这些决定提前变成看得见的连接、schema、样例输出和日志。
落地建议
把 Inspector 当成上线前的小门禁：新服务第一次接入、工具 schema 变化、权限范围变化、传输方式变化、依赖版本升级，都重跑一次验收清单。验收记录可以很轻量，只保留启动命令、测试输入、返回摘要、已知限制和安全备注。等这些信息稳定后，再把客户端配置、README 和回归脚本补齐。
对团队来说，这个流程不要求引入复杂平台，只需要把 MCP 官方工具和一套固定检查项放进日常开发。每个工具在进入 Agent 工作流前都先被单独看过、跑过、记录过，后续排查就能聚焦在编排逻辑、模型选择和用户确认策略上。