MCP 服务上架 Claude 前的自查要点

把 MCP server 接进 Claude，能调用成功只是第一步。作者有两个服务器正在等待 Connectors Directory 审核，于是把 Anthropic 公开的提交要求整理成了一张检查表：工具怎样拆、描述怎样写、上线材料怎样备，以及安全检查该看哪里。

最值得开发者带走的结论是：**提交前要检查的核心，是每个工具的权限边界和实际行为能否被清楚识别。**不过，作者没有审核内部信息，也没有通过审核的结果；这是一份依据公开文档整理的准备指南，不能当作过审保证。

一个万能请求工具，为什么可能卡在审核上

不少 API 封装会提供一个 api_request，让调用方通过 method 参数选择请求方式。实现省事，却把读取数据和修改数据放进了同一个入口。

按作者整理的标准，同时接受安全 HTTP 方法 GET、HEAD、OPTIONS，以及非安全方法 POST、PUT、PATCH、DELETE 的工具会被拒绝。在描述里解释哪些操作安全，也不能代替拆分。读操作和写操作需要成为不同工具，写操作最好继续拆成 create、update、delete。

这里的「安全」指 HTTP 方法语义，不代表接口没有数据泄露风险。拆分的作用，是让客户端能够在调用之前识别操作边界，不必等到解析参数时才知道它是否会修改数据。

每个工具还需要 title，以及 readOnlyHint: true 或 destructiveHint: true。作者将其与确认流程联系起来：只读工具可以免于逐次确认，破坏性工具则始终提示确认。这个行为是作者对标准的转述，原文没有展示具体客户端配置和验证过程。

工具名也有硬限制：最多 64 个字符。描述必须与实际行为一致。如果工具允许传入自由形式的路径、查询字符串或请求体，描述必须明确目标 API，不能只写「向 API 发起请求」。

工具描述要解释能力，不能偷偷指挥 Claude

作者列出的另一组要求，针对的是描述里的行为指令。

工具描述不能要求 Claude 调用用户没要求的工具，不能干扰其他工具，不能从外部来源拉取指令，也不能隐藏或编码指令、覆盖系统指令，或者夹带产品推广。

对写过 AI 工具的人来说，这里有个容易混淆的边界：说明工具接受什么参数、返回什么数据，是接口文档；要求模型无论用户问什么都先调用自己，则是在争夺执行流程。

工具描述应该帮助 Claude 判断是否适用，而不是替用户安排任务。

返回结果也要遵守这个边界。作者要求先校验输入，错误信息应说明哪里有问题、该改什么，不能只返回一句 Internal Server Error。用户要摘要，就不要返回整库数据。

数据收集同样需要克制：只收集完成工具功能所需的信息。作者列出的要求还包括，不要查询 Claude 的记忆、聊天历史或用户文件。原文没有进一步解释这条限制在不同连接器类型中的适用范围，不能自行补出例外。

进入审核队列前，还缺哪些交付材料

如果工具要操作用户账户，需要准备 OAuth 2.0；服务本身需要 HTTPS 远程 URL。除此之外，作者列出的提交材料还有：带有完整可测试数据的测试账户、最迟在发布时可公开访问的文档、隐私政策、支持联系方式和图标。

测试账户不是交一个能登录的空账号就结束了。按这份清单的要求，审核方需要有数据来验证工具的实际行为。

每个工具还要在两个环境里测试：先用 MCP Inspector，再作为 Claude 内的 custom connector 测试。作者说提交门户会要求确认这两项。前者用于检查工具接口，后者把工具放回实际使用场景；原文没有提供具体测试用例或测试结果。

安全检查也在同一张清单里。作者提醒了两类典型代码问题：

• 把调用方传入的 URL 直接交给 fetch，可能形成服务端请求伪造（SSRF），让服务器访问不该访问的目标。
• 把工具参数拼进 shell 命令，可能引入命令注入。

作者自己的静态扫描器 mcp-ssrf-scan 检查这两类模式，也检查泄露的密钥。但它寻找的是可疑代码模式，不是漏洞证明。作者在 36 个公开服务器上运行后，结果大多是噪声，因此明确要求逐条人工复核。

我的判断

这份清单最有价值的地方，是把工具设计和审核要求放在一起。对正在封装 MCP server 的团队，读写拆分、准确描述和可修复的错误信息，都适合在接口设计阶段处理。等接入完成再补，往往需要重新调整工具结构。

但要分清证据强度。作者的两个服务器仍在排队，原文没有通过案例，也没有比较拆分前后的审核结果。「这样准备有助于满足公开要求」是合理结论，「照做就能通过」则没有依据。

通用 API 请求工具在内部集成中可能更省维护成本，但这份清单指出，目录提交对它的边界有更明确的要求。不能把内部方便直接当作公开分发时的合适设计。

扫描器部分也要保留距离：作者既提供免费工具，也销售固定价格的人工审查服务。36 个服务器上「大多是噪声」的结果，支持把扫描器用作人工检查入口，无法证明它能有效覆盖漏洞。原文没有误报率、漏报率或对照数据，这部分仍是经验提醒。

能拿来做什么

• 如果正在用 Node 封装 MCP server，先检查是否存在带 method 参数的 api_request，把读写混用的入口拆开，再逐个核对工具注解。
• 给每个工具做一次描述审查：写清目标 API、输入和输出，删除强迫 Claude 调用工具或影响其他工具的指令。
• 在 MCP Inspector 和 Claude custom connector 中分别测试每个工具，检查错误输入能否得到可执行的修正提示，并提前填充测试账户的数据。
• 人工检查用户输入流向 fetch 和 shell 命令的位置；静态扫描命中后阅读具体代码，不把命中数量当作已确认漏洞数量。