MCP协议现状：14家代码托管平台无一达到Level 2成熟度

Cursor 于 8 月 17 日发布了 Origin，称其为面向 Agent 时代的 Git forge。8 月 22 日，我用一个独立的 agent-readiness 扫描器扫描了它的公开表面以及另外 13 个代码托管平台，没有一个达到 5 级中的第 2 级。

2026-08-22，用 isitagentready 扫描器扫描了 14 个代码托管平台的公开表面，每个平台各运行一次。

最高读数是 5 级中的第 1 级。六个平台达到了这一级别，分别是 Cursor Origin、GitLab、SourceForge、Forgejo 和 Azure DevOps。其余八个读数为第 0 级。

扫描器中名为"API、Auth、MCP & A2A Discovery"的检查组包含 9 项检查。在整个样本中，它运行了 124 次，只通过了 2 次。

14 个平台中，零个 MCP server card、零个 API catalog、零个 agent skills index、零个 ARD manifest，以及零个 auth.md 文件。GitLab 在大多数这些路径上都返回了 403 而不是 404。A2A card 和 WebMCP 检查在 13 个平台上完成，两者读数都为零。

两次通过的都是 OpenID Connect metadata，这是公开发布的，供人们登录使用，而不是供 Agent 发现任何东西。

测量了什么，没有测量什么

扫描器读取的是一个公开的 Web 表面。它不登录，也不查看仓库。Origin 本身在 Cursor 付费计划之后，因此读取描述的是 cursor.com 及其 Origin 营销页面，而不是 forge。四个目标重定向到了其他地方，GitLab 重定向到其营销网站，Azure DevOps 重定向到 Microsoft 产品页面，因此 GitLab 从 gitlab.com/explore 上的应用重新测量了一次。两次读数都落在第 1 级，但各自通过的项目不同。

有一个主机在计数中缺失了。savannah.gnu.org 两次尝试都没有响应，一次是网络错误，一次是 502，一个无法访问的站点不是零。

作为参考，我自己的网站在同一扫描器上、在同一天读到了 5 级中的第 5 级。这个比较不是一场公平的战斗，我没有把它作为一个来呈现。turva.dev 是一个单人咨询网站，有 60 个规范页面，而代码托管平台承载着多租户负载，还要处理像我这样的网站永远不需要解决的访问模型。这确实说明，发布这些 manifest 并不昂贵。

对于几乎每个主机来说，通过的检查都是相同的两个：一个 robots.txt 被扫描器读取为有效，以及一个 robots.txt 的规则覆盖了 AI 爬虫，要么是命名了它们，要么是让通配符覆盖了它们。这是一个普通网站无需努力就能达到的底线。Gerrit 在它之下，因为它的 robots.txt 根本没有 User-agent 行，所以文件被读取为无效，AI 规则检查也随之失败。

GitHub 运行着一个 MCP server。github.com 上没有任何说明。

这是我一直在回顾的发现。GitHub 运营着一个生产级 MCP server，我在运行这些扫描的同一天使用了它。它能工作。但是 github.com 没有提供任何 MCP server card、API catalog，也没有指向这两者的 Link header，所以一个没有被告知 server 存在的 Agent 到达后没有办法发现它。能力存在，但 announcement 不存在。

同样的模式在整个样本中重复出现。以下是对这些产品如何销售的一种解读，扫描并不测量这些。其中一些被宣传为 Agent 处理代码的地方，但在它们每一个上面，入口都是一个为人类编写的文档页面。

扫描没有证明的三件事

GitLab 对大多数已知路径（包括 API catalog、auth.md、MCP card、A2A card、skills index 和 ARD manifest）返回了 HTTP 403。403 是拒绝，而不是文件不存在的证据，我只是因为检查没有得到答案才将这些记录为失败。

两个检查在 Gitee 上没有完成，原因各不相同。A2A card 获取中止，WebMCP 检查在 8 秒后超时。因此，它的 discovery 组只按 9 项中的 7 项评分。

样本是我手动挑选的 14 个表面。这不是随机抽样，也没有覆盖每个代码托管平台。把它当作一天的快照来读。

为什么这些很重要

一个 Agent 今天登录代码托管平台，可以读取营销文案。它不能询问该站点能做什么，因为站点上没有任何东西以 Agent 解析的格式回答这个问题。因此每个集成都必须由一个已经知道端点存在的人类硬编码。

修复都很小，而且大部分是机械性的。一个 server card 是一个位于已知路径的 JSON 文件。一个 API catalog 是一个 linkset。一个 Link header 是一行响应配置。这些都不需要重建 forge，而且在我测量的 14 个表面上都没有完成。

如果你想自己检查一个站点，扫描器是公开的，免费的 llms.txt 验证器在 turva.dev/llms-txt-validator。审计和咨询工作在 turva.dev。

这是否意味着 GitHub 坏了？

不。GitHub 能工作，它的 MCP server 也能工作，我在运行扫描的同一天使用了它。读数只描述了一件事：网站是否以一种 Agent 无需告知就能找到的格式宣布了它能做什么。在这一点上 github.com 读数为零，样本中的每个其他主机也是零。

为什么代码托管平台要发布 MCP server card？

这样到达该域名的 Agent 就能了解存在一个 server、它在哪里、它做什么，而不需要人类先将端点粘贴到配置文件中。card 是一个位于已知路径的 JSON 文件。它不会改变 forge，也不会暴露文档中没有说过的东西。

如何自己检查一个主机？

对目标域运行相同的公开扫描器，读取名为"API、Auth、MCP & A2A Discovery"的组。结果是那一天的快照，包括我的，因为这些规范每月都在变化。

---