一个 MCP server，八套规则：各宿主对 MCP 服务器的要求差异梳理

2026年10月2日

一个遵循规范的模型上下文协议（MCP）服务器仍可能被 Claude 连接器目录拒绝，因缺少注解而被 ChatGPT 应用商店拒之门外，或者其工具名称被 Gemini CLI 悄悄截断。每个运行 MCP 服务器的主机都发布自己的规则，而这些规则彼此并不一致。在审查测试 MCP 服务器的工具时，我收集了截至 2026 年 10 月 1 日的规则。这就是那本规则手册，包括它在哪里自相矛盾、其中有多少机器可以检查，以及今天有什么在尝试检查它。

简而言之

1. 八本规则手册，一个服务器。规范、Claude 连接器目录、Claude 应用和 Claude Code、ChatGPT 应用、Codex、带 Copilot 的 VS Code、Windsurf、Kiro 和 Gemini CLI 各自都添加了自己的约束。
2. 它们相互冲突。根据规范，工具名称可以长达 128 个字符，而 Claude 目录和 Kiro 限制为 64 个字符，超过 63 个字符的名称会被 Gemini CLI 截断。规范允许名称中包含连字符和点号；Kiro 则拒绝它们。注解在规范中是可选的，而对 Claude 和 ChatGPT 则是强制性的。
3. 大约一半的规则可以静态检查，四分之一需要实时调用，而审查者实际拒绝的大部分内容需要判断：描述是否与行为相符、注解是否诚实、描述是否带有注入模式。
4. 规则会变动，因此验证器必须将它们作为带来源和日期的版本化数据来承载，而不是作为代码。
5. 如今能依据这些规则进行验证的工具是闭源的、付费的或部分的：Alpic Beacon、Manufact 的发布检查和 MCPJam 的托管就绪运行。没有任何开源工具覆盖 IDE 和命令行主机。

规则，逐主机列出

规则手册分歧之处

名称长度。规范允许最多 128 个字符。Claude 目录和 Kiro 限制为 64 个字符，而 Kiro 还计入服务器前缀。Gemini CLI 不会拒绝较长的名称；它会在 63 个字符处截断，这更糟，因为服务器永远不会发现。

字符。规范允许字母、数字、下划线、连字符和点。Kiro 的模式 ^[a-zA-Z][a-zA-Z0-9_]*$ 不允许连字符和点，且要求首字符为字母。一个在其他所有地方都有效的名称在这里会失败。

注解。readOnlyHint、destructiveHint 和 openWorldHint 在规范中是可选的。Claude 目录要求 title 加上每个工具上的只读或破坏性提示，并要求将读和写操作拆分为单独的工具。ChatGPT 要求每个工具上都有全部三个提示，并称缺少它们是常见的拒绝原因。

预算。不同宿主限制不同的东西。VS Code 按每个聊天请求计算工具数（128），Windsurf 按工具总数（100），Codex 按秒数（启动 10 秒，每次调用 60 秒），Claude 按结果大小（应用中约 150,000 个字符，Claude Code 中默认 25,000 个 token）。为其中某一个构建的服务器可能无需改动一行代码就会超出另一个的限制。

机器能检查什么

大约一半的规则可以从 tools/list 静态检查：名称长度和字符、注解和标题的存在、有效的输入 schema、工具数量。大约四分之一需要实时测试调用：每个工具在有效输入下都能成功，错误以 isError 结果而非通用失败返回，响应保持在宿主的大小限制内，服务器在 Codex 的十秒内启动。

审查者实际拒绝的大多数内容需要判断而非规则：描述是否与工具所做之事相符，readOnlyHint 是否诚实，描述是否带有推销性质，其中是否有任何内容读起来像提示注入。这是带有评分标准的语言模型的工作，其裁决需要有人类在背后把关。

宿主文档经常变动，上述规则每一条都只是在某一天读过一次。硬编码这些规则的验证器会腐烂。规则必须是数据：带版本，每条都有其来源和读取日期，这样某个宿主文档的变化就是一条记录，而不是一次发布。

描述是服务器失败之处

最重要的规则是正则表达式无法检查的那一条：描述。“工具描述有异味”在其检查的 856 条工具描述中，至少发现 97.1% 存在一处缺陷，而糟糕的描述会降低智能体选择正确工具的概率。

衡量描述最成熟的标尺是 Glama 的 工具定义质量评分（TDQS）。每个工具一次模型调用，从 1 到 5 分对六个维度评分（目的清晰度、使用指南、行为透明度、参数语义、简洁性和完整性），服务器级评分则涵盖工具间的消歧、命名一致性、工具数量和完整性。评分标准和提示词已公开，tdqs lint 无需密钥即可确定性运行，tdqs score 可针对任何 OpenAI 兼容端点运行，并带有用于 CI 的 --fail-under 门禁，Glama 在其注册表中持续运行它（据该仓库，截至 2026 年 6 月已评分 15,036 个服务器），因此维护者无论是否知情，都已在被它评分。它只对定义评分，从不评估行为，且给出的是理由而非改写后的文本。

Anthropic 自己的指南 为智能体编写有效的工具 是至少一个 linter 规则的基础，而 ChatGPT 指南要求描述不带推销性质、输入保持最小化。

两个协议时代

当前规范 2026-07-28 是一次无状态重新设计。根据其 更新日志，它移除了 initialize 握手、协议级会话和 ping，强制要求新的 server/discover 调用，将 elicitation、sampling 和 roots 变为多轮往返结果，弃用 Dynamic Client Registration 转而采用 Client ID Metadata Documents，并将 Roots、Sampling、Logging 和 HTTP+SSE 置于弃用窗口期。宿主落后于规范，因此服务器必须长期同时应对旧时代（2025-11-25 及更早）和现代时代，任何对其进行验证的东西也是如此。

如今依据规则进行验证的工具

Alpic Beacon（2026 年 5 月；闭源；Alpic 平台的一部分）是针对 ChatGPT 商店和 Claude 连接器目录的提交前审计工具。它通过仪表盘或 alpic audit CLI 检查协议管道、工具质量和注解、小组件渲染、CSP 以及 LLM 驱动的边缘用例输入。它基于真实的提交经验构建，覆盖实时行为，而不仅仅是元数据。它仅覆盖两个商店，不是开源，其确切成本和计量方式未经核实。

Manufact 的发布检查在免费层级提供发布清单，从每月 25 美元起提供在模拟 ChatGPT 和 Claude 中的端到端检查以及提交包。仅限云端，且专注于这两个应用商店。

MCPJam 的宿主兼容性针对 Claude、ChatGPT、Cursor、Copilot 和 Codex Desktop 给出静态的 Works、Degraded、Blocked 或 Unknown 判定，其托管的目录就绪性运行会依据 Anthropic 和 OpenAI 的目录要求对服务器进行评分，并可选提供消耗积分的 LLM 观察结果。确定性评分是免费的，客户端配置文件也很多，但兼容性功能自称是静态检查的原型，忽略了传输和认证方面的阻碍，就绪性运行需要托管后端，且规则列表未公开。

厂商自带的辅助工具是指令，而非验证器。OpenAI 发布了一个 chatgpt-app-submission skill，编码代理可遵循它来检查提示并生成测试用例。Anthropic 会自动扫描提交内容，但该扫描器不对开发者开放；其 mcp-server-dev 插件带有一份手动清单。mcpb validate 仅依据其 schema 检查桌面扩展清单。sunpeak（MIT，约 217 颗星）为 MCP Apps 模拟 ChatGPT 和 Claude 运行时，开发者需手动编写注解断言。

未找到：一个开放的、由规则包驱动、同时覆盖 Claude、ChatGPT 以及 IDE 和命令行宿主（Cursor、VS Code、Codex、Gemini CLI、Kiro、Windsurf）的验证器，也没有任何工具将规则作为带来源的版本化数据发布。

方法与注意事项

• 这些规则于 2026 年 10 月 1 日从各厂商的文档中读取。Codex 和 Windsurf 的限制来自对各自厂商文档的单次阅读，在任何人将其编码为规则之前应重新核实。
• Cursor 的 40 个工具限制无法在当前文档中确认，因此未列入表中。
• 未安装或运行任何工具。对 Beacon、Manufact 和 MCPJam 的描述反映的是各自文档所述内容。

我是 Amir Pournasserian。我以构建 AI 和平台系统为生，维护 FluentCMS 和 YeSvelte，并在这里写下我一路上的发现。