通过公开握手方法优化 MCP 服务可见性

如何通过优化 MCP 服务握手机制，解决开发者工具的“隐身”难题

在当前的 AI 开发生态中，MCP（Model Context Protocol）正迅速成为连接大模型与外部工具的标准协议。对于开发者而言，开发出一个功能强大的 MCP 服务并将其发布到各类目录或平台，本应是获取流量和用户的重要手段。然而，许多开发者在投入大量精力进行API设计和软件架构优化后，却发现自己陷入了一个尴尬的境地：明明服务已经上线并注册到了各大平台，但在搜索结果中，工具列表显示的却是“零工具”。

这种现象并非由于功能实现错误，也不是因为数据同步延迟，而是一个深层的架构逻辑冲突：身份验证机制与服务发现机制的矛盾。

看似完美的架构：OAuth 带来的安全陷阱

为了保障用户数据安全和防止资源滥用，很多开发者在构建远程 MCP 服务时，会采用标准的 OAuth 2.1 协议。这种设计在逻辑上是非常严密的：每一个工具调用（tools/call）都会消耗计算资源或涉及敏感数据，因此必须要求用户通过身份验证。其代码逻辑通常如下：

• 检查请求头中是否包含有效的身份令牌（Token）。
• 如果令牌缺失，直接返回 401 Unauthorized 状态码。
• 只有通过验证的请求，才会进入实际的业务逻辑处理函数。

这种做法在保护用户隐私方面无可挑剔，但在开发者工具的推广过程中，它却成了一个致命的“盲点”。

当各类 MCP 目录或扫描器（类似于国内的插件市场或开发者服务聚合平台）尝试抓取你的服务信息时，它们本质上是一个“匿名访客”。它们会尝试调用 tools/list 方法来获取你的服务究竟能做什么。然而，由于扫描器没有经过用户的 OAuth 授权，它在进行握手时会直接撞上 401 错误。结果就是，虽然你的服务在运行，但在所有的公开目录中，你的工具列表看起来都是空的。

破局之道：引入公开握手方法

解决这个问题的核心思路在于：描述服务的功能不应该是受限的操作，而执行具体的功能才是。

在设计软件架构时，我们需要将“查询元数据”与“执行业务逻辑”进行解耦。我们需要允许扫描器在无需登录的情况下，通过特定的“公开握手方法”获取服务的基本能力。这些方法包括但不限于：

• initialize：初始化连接。
• notifications/initialized：通知初始化完成。
• ping：心跳检测。
• tools/list：获取工具列表。

通过允许这些特定的方法在没有授权头的情况下通过验证，你可以让目录爬虫顺利读取到你的服务能力，从而在平台上展示出正确的工具列表，吸引潜在用户。而对于真正涉及资源消耗或数据操作的 tools/call 方法，依然保持严格的身份验证。

实战代码逻辑：如何实现安全的公开访问

要在现有的身份验证中间件中实现这一功能，开发者需要构建一个智能的分流逻辑。以下是实现这一目标的关键步骤：

1. 定义白名单集合
首先，创建一个包含所有允许公开访问的方法名的集合。这确保了只有特定的、低风险的查询操作可以绕过身份验证。

2. 实现请求校验函数
在处理请求时，需要满足以下三个硬性条件，才能判定该请求为“公开握手”：

• 无授权头：如果请求头中携带了 Authorization，说明用户试图进行受保护的操作，必须走严格的验证流程。
• 请求方法限制：在基于流的 HTTP 协议中，握手请求通常应限制为 POST 方法。
• 全量消息校验：由于 JSON-RPC 支持批量处理（Batching），必须确保请求包中的每一个方法都在白名单内。如果一个包中同时包含了 tools/list 和 tools/call，则必须视为受保护请求，不能放行。

3. 构建分流中间件
在路由层，通过一个逻辑判断来决定调用 handler（处理公开请求）还是 authed（处理授权请求）。这种设计不仅提升了服务的可见性，同时也通过严格的校验逻辑保证了安全性，不会因为权限放开而导致资源被恶意消耗。

总结

对于想要通过提供 AI 插件或 MCP 服务来变现的开发者来说，可见性就是生命线。如果你的服务在闲鱼、猪八戒或各类开发者社区的搜索结果中显示为“无可用工具”，那么你可能需要重新审视你的API设计。通过在软件架构中合理地分离“元数据查询”与“业务执行”，你可以在不牺牲安全性的前提下，让你的工具被全世界看到。