MCP 端点检查器
把它指向一个远程 MCP 服务器。它会像 AI 客户端那样走一遍发现链，并指出失败的是哪一步。
这项检查从你的浏览器发起，因此会受 CORS 限制。不发送 Access-Control-Allow-Origin 的服务器会拦下请求，于是即使它本身是健康的，看起来也像不可达。这件事本身就是有用的信息——有些客户端同样需要这些响应头——但不要把 CORS 失败当成服务器有问题的证据。
它检查什么，以及每一步为什么重要
1. 未认证挑战
未经认证的请求必须返回 401，并带上携带 resource_metadata 的 WWW-Authenticate 响应头。没有这个响应头，客户端就无从得知该去哪里认证，只会以一个含糊的连接错误收场。这是连接器无声无息地拒绝工作的最常见原因。
2. 受保护资源元数据（RFC 9728）
resource 字段必须与服务器的规范 URI 完全一致。客户端是按字面比较的，所以多一个结尾斜杠，或者用了 http 而不是 https，都会直接失败，而且报错信息帮不上忙。
3. 授权服务器元数据（RFC 8414）
必须公布 authorization、token 和 registration 三个端点，并在 code_challenge_methods_supported 中列出 S256。OAuth 2.1 要求使用 PKCE，禁止 plain 方式；提供 plain 的服务器不符合规范，有些客户端会直接拒绝。
4. 传输方式
新的连接器应当使用 Streamable HTTP。旧的独立 HTTP+SSE 传输已经废弃，提交到目录时不再接受。
我们为什么做这个工具
Varven 本身就是一台远程 MCP 服务器，把 OAuth 握手调通花的时间比写检索引擎还长。它的失败方式很难受：客户端只报告连不上，完全不说七个步骤里是哪一步出了问题。这个工具按顺序走一遍，并指出坏掉的是哪一步。
常见问题
我的服务器在 Claude 里能用，在这里却失败。
几乎可以肯定是 CORS。浏览器会强制执行它，原生客户端不会。
我需要动态客户端注册吗？
如果你希望客户端不必由你逐个预先注册就能连上，那就需要。没有它，每个客户端都得靠手工发放凭据。
我该以哪个版本的规范为准？
按当前的授权规范来做，并做好它还会变的准备：这份规范已经改过好几版，而且从 SSE 迁移到 Streamable HTTP 的时间还很近，有些客户端仍然没跟上。