MCP 服务错误处理：我的经验教训
我以为在 MCP 服务第一次运行后我就大功告成了。它返回了工具列表，调用了一个工具。我感觉很成功。
我错了。
在生产环境中运行 MCP 服务让我明白，教程往往只关注理想路径（happy path）。它们忽略了出错时会发生什么。以下是我在为自己拥有 1,800 小时的知识库构建服务时学到的经验。
始终为空结果返回内容 大多数客户端在收到空响应时会卡死。如果你的搜索没有找到任何内容，不要返回“空”。返回一条文本消息。告诉用户为什么没有结果，以及你的数据库中存在多少项。
管理缓慢的连接启动 我托管在一个会进入休眠状态的免费层级上。当它唤醒时，需要 15 秒。许多 MCP 客户端在此之前就会超时。 • 发送早期响应头以保持连接活跃。 • 设置响应大小的硬限制。 截断大型结果，以免触发超时限制。
停止手动构建 JSON 标题中一个未转义的双引号就破坏了我的整个 JSON 响应。客户端在没有任何错误提示的情况下断开了连接。使用像 Jackson 这样的框架来处理序列化。让库来为你管理转义。
预见不一致的身份验证 不同的客户端处理 API 密钥的方式不同。有些使用请求头（headers），有些使用查询参数（query parameters），有些两者都不用。 • 支持多种发送密钥的方式。 • 如果身份验证失败，始终返回一个规范的 JSON 错误主体。
设置明确的 Content-Length 一些客户端在处理分块编码（chunked encoding）时会遇到困难。如果你的响应被截断，请停止使用压缩。预先计算响应大小并显式设置 Content-Length 响应头。
优点： • 隐私性：只有相关的片段会被发送给 AI。 • 互操作性：该服务器可在不同的客户端上运行。 • 简单性：我的服务器只有 150 行代码。
缺点： • 生态系统尚不成熟：文档缺失许多边缘情况。 • 托管：你必须自己管理端点和冷启动。 • 演进：协议经常发生变化。
MCP 将我那些闲置的笔记变成了一个实用的工具。它让我的数据变得触手可及，从而让 AI 可以承担繁重的工作。
你构建过 MCP 服务吗？你遇到了哪些错误？请在评论区告诉我。
Optional learning community: https://t.me/GyaanSetuAi