每 10 个公开的 MCP 端点里，有 3 个先要密钥

我们的探测器连接每个端点的方式都一样：不带凭据。它不携带任何令牌，也从不向任何人索要。所以一个 MCP 端点如果连握手都要先给密钥，探测器收到的就是一个认证质询，到此为止。

2026-09-30，我们在观测 2,282 个公开端点，它们最近一次运行分成三组：

最近一次观测	端点数
返回了工具列表并已存下	1,469
握手时回了认证质询	694
两者都不是：连不上，或以其他方式失败	119

第一组就是目录。第二组在单独的列表里。每个端点显示 server 名称、传输方式、端点地址（有记录时）、它给出的认证方式和我们最后一次观察的时间，并注明没有观测到工具列表。那个列表上没有任何检查结论，因为我们根本没走到能检查的那一步。它占我们观测的公开端点的 30%。

质询告诉我们什么

质询是一个带 WWW-Authenticate 头的 HTTP 401，这个头会写明认证方式。694 个里，690 个写的是 Bearer，另外 4 个写的是另外两种。

这个头还可以指向一份描述受保护资源的文档：由哪个授权服务器签发令牌，它认识哪些 scope。这份文档本来就应当不带令牌也能读，因为客户端在拿到令牌之前就需要它。我们的 auth_metadata 检查会不带凭据地顺着这个指向去取，只看取到的内容结构对不对：

最近一次运行的 auth_metadata	端点数
质询指向一份文档；我们取到了，它是 JSON 对象，质询里的 scope 与文档所列不矛盾	631
质询没有指向任何文档	57
文档取不到、不是 JSON 对象，或与质询的 scope 矛盾	4
那次运行没有检查：1 个被我们的连接策略拦下，1 个超时	2

也就是说，把我们挡在门外的端点里，91% 同时以我们读得懂的方式告诉了客户端下一步该去哪里。

这些说明不了什么

说明不了一个端点的认证有多强。我们从不持有令牌，所以从没见过真正的认证流程跑起来。结构正确的指向加上结构正确的文档，只说明这个端点对一个还没有密钥的客户端正确地描述了自己，并不说明出示密钥之后会发生什么。

也说明不了这些端点提供哪些工具、能不能用。对这 694 个端点，我们观测到的只有一次握手和一个质询。

为什么我们不要密钥

一个不带凭据观测的目录，可以对里面每个端点说同一句话：这就是互联网上任何人会看到的样子。一旦它为其中一部分端点持有密钥，这句话就不再成立，读者也分不清哪些观测用了他们没有的权限。所以探测器匿名观测，需要密钥的端点单独列出，只按它们对一个没有密钥的客户端呈现的样子来描述。

如果你的端点在那个列表上

质询和它指向的文档，是任何客户端从你这里看到的第一样东西。如果你的端点在那 57 个里，你的质询没有带指向；一个只从质询出发的客户端（我们的就是）无处可去。你可以自己看：不带令牌请求你的端点，读返回的 WWW-Authenticate 头。

数字从哪里来

2026-09-30 对生产数据库做的只读查询。公开端点是状态为未认领、认领中或已认领的 target。前两组分别是目录视图和需要凭据的视图，第三组是两个视图都不包含的公开 target。认证方式取自每个端点最近一次运行记录下的质询。auth_metadata 的计数是同一次运行里这项检查的结果。