给 AI 接上文件、知识库或业务系统时，第一步常常是配置一个 MCP 服务。工具列表没有出现，原因可能在启动方式、协议连接或权限配置。把这些问题拆开检查，通常比反复重装更容易定位。
本文以 MCP 2025-11-25 版传输规范为基线，资料核对日期为 2026 年 10 月 19 日。这里不宣称该版本是所有客户端当前使用的版本；接入前仍须核对客户端与服务端的支持范围。[1]
两种方式，各自解决什么问题
规范定义了 stdio 与 Streamable HTTP 两种标准传输。[1]
方式 | 通信方式 | 本文建议的起点 |
|---|---|---|
stdio | 客户端启动子进程，通过标准输入、输出交换协议消息 | 运行在自己电脑上的工具 |
Streamable HTTP | 客户端通过 HTTP 与独立服务通信 | 需要远程部署或集中维护的服务 |
使用 stdio 时，配置重点是“启动哪个程序、传什么参数、提供什么环境”。使用 HTTP 时，重点转为“访问哪个端点、如何认证、双方如何处理请求和响应”。
这张表是选型起点。最终仍取决于现有客户端与服务端实际支持什么，不应仅按本地或远程位置机械选择。
stdio 最容易忽略的是日志
stdio 服务端从标准输入读取协议消息，并把协议消息写到标准输出。规范允许把诊断日志写到标准错误；标准输出不能混入非协议内容。[1]
因此，如果一个服务启动后先打印一段欢迎语，再输出 JSON-RPC，客户端可能无法把这段输出当作有效协议消息解析。
本文建议按下面的顺序排查：
- 对照客户端配置确认程序路径、参数和环境变量名称。
- 查看客户端捕获的服务端标准错误。
- 检查是否把普通日志写进标准输出。
- 先运行不产生业务写入的工具调用，再检查其返回结构。
不要把“终端中程序没有退出”当作接入成功。它只说明进程暂时存在，还没有证明双方已经完成协议交互。
HTTP 能访问，也不等于 MCP 已接通
该版规范要求客户端把每条 JSON-RPC 消息作为新的 HTTP POST 发往 MCP 端点。服务端针对请求可以返回 JSON，也可以建立 SSE 流；客户端需要支持这两类响应。[1]
因此，看到网页返回 200、首页能打开，或者用浏览器访问某个 URL 没有报错，都不能单独证明 MCP 可用。应使用支持相应协议的客户端检查初始化、能力协商以及后续消息。
还要区分两个概念：旧式 HTTP+SSE 传输与 Streamable HTTP 不是同一个名称；而 SSE 仍可作为 Streamable HTTP 中的流式响应机制。[1] 发现教程写“SSE”时，先确认它具体指哪一种实现。
把传输验证和业务验证分开
下面是本文设计的验收顺序。它适用于常见的工具接入，具体操作名称以客户端提供的功能为准。
层次 | 要验证的事 | 建议保留的证据 |
|---|---|---|
启动与连接 | 进程能启动，或 HTTP 端点可到达 | 脱敏后的启动信息与错误 |
MCP 协议 | 初始化成功，预期能力可见 | 客户端状态、工具名称与参数定义 |
业务行为 | 小范围读取返回正确数据 | 输入参数与预期结果的对照 |
写入行为 | 已授权的变更符合预期 | 明确目标、实际结果与恢复办法 |
例如，连接文章系统时，先列出文章，再读取一篇已知文章。需要创建内容时，先写入一篇可检查的草稿。这样的顺序能把连接故障与业务校验错误区分开。
本地 HTTP 服务也需要访问边界
规范对 Streamable HTTP 明确提出 Origin 校验要求；本地运行时建议绑定 localhost，并为连接实施适当认证。[1] 监听地址、Origin 校验与认证分别处理不同问题，不能互相替代。
本文建议默认保留已有访问边界。排查连接失败时，先看日志和配置，不要直接把监听地址改成所有网卡，或关闭认证来“试一下”。如果确实需要远程访问，应先明确使用者、认证方式与允许调用的能力。
可以交给 Agent 的检查提示词
检查这个 MCP 接入的传输类型与客户端兼容性。先说明将读取哪些配置，再执行初始化和小范围只读验证。输出错误所在层次、脱敏证据及建议修复。涉及业务写入、开放网络监听或改变认证时，先确认这些操作是否已获授权。
提示词中的目标是让 Agent 形成可复查的结论：哪个阶段成功、哪个阶段失败，以及下一步需要改变什么。
参考来源
本文为原创整理；选型建议、分层检查表及示例提示词为作者建议。未在读者的客户端与服务端进行联调。