来源：作者 2026-08-12 自研探针实测，数据可复现（方法见文末）。 样本：社区精选列表（awesome-mcp-servers，85K stars）提取的 103 个远程 MCP 端点，连续监控 6 轮 × 15 分钟 ≈ 1.5 小时。
先看结论（三句话）
- 社区精选列表里的远程 MCP 端点，只有 54% 是稳定可用的；
- 近 1/4（23%）的"端点"根本不是 MCP 端点------是文档页、目录页、PyPI 项目页，照抄配置必失败；
- 有 3 个端点在监控期间死过又活------单次探测（哪怕一次审计 2181 个端点）永远发现不了它们。
为什么做这件事
今年 4 月，Apigene 对 2,181 个远程 MCP 端点做了一次审计：52% 完全死亡、只有 9% 健康。
但那份审计只测了一次。MCP 生态里"静默失败"的传说很多------server 挂了 agent 不报错、schema 漂移客户端还在用旧签名调用------可几乎没人用时间维度看过这些端点：它们到底稳不稳定？有没有"诈尸"的？
所以我写了探针，把社区精选列表里的远程端点连续盯了一个半小时。
方法与样本
- 样本：awesome-mcp-servers（punkpeye，85K stars）README 中提取的 103 个远程端点
- 探测 ：JSON-RPC
initialize（MCP 2025-06-18 spec）→tools/list - 节奏：每 15 分钟一轮，共 6 轮（约 1.5 小时）；每端点 6 次探测，总计 618 次
- 细节：Streamable HTTP 用 POST（Accept: application/json, text/event-stream）；SSE 端点用 GET；失败自动重试 3 次防网络抖动；超时 8s
- 判定：握手成功 + 工具列表完整 = healthy；连上但非 JSON-RPC = handshake_fail；需认证 = auth_required；连接失败 = dead
bash
# 单端点手动握手（自检也可以用）
curl -X POST <端点URL> \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"0.1"}}}'结果：54% 稳定可用，27% 完全不可用
| 状态 | 数量 | 占比 | 说明 |
|---|---|---|---|
| 稳定健康（6 轮几乎全过） | 56 | 54.4% | initialize + tools/list 都通过 |
| 活着但要认证 | 19 | 18.4% | 无 token 用不了（appwrite、glif、avots、alphavantage 等） |
| 假端点（文档页/目录页/项目页） | ~22 | ~21% | 能连上、返回 200、永不握手成功 |
| 真死（DNS/TLS/410/404） | ~6 | ~6% | 含官方端点退役 |
| 波动（死过又活） | 3 | 2.9% | 间歇性故障，见下文 |
一句话：你在社区精选列表里找到的远程 MCP 端点，只有一半多一点真的稳定能用。
发现一：1/4 的"端点"是文档页（最反直觉）
从 README 提取的 103 个 URL 里，有 20 多个长这样：
text
https://pypi.org/project/mcp-agent-health/0.3.1/ ← PyPI 项目页
https://open-mcp.org ← 目录站主页
https://mcpqueen.com ← 目录站主页
https://paybond.ai/docs/kit/mcp-server ← 文档页
https://drwho.me/mcp/mcp ← 双重 /mcp，路径不存在它们能 ping 通、返回 HTTP 200 ------传统 uptime 监控会告诉你"一切正常"。但对 MCP 做 initialize 握手，100% 失败。
翻译一下：你在文档/列表里复制的端点 URL，大约每 4 个里就有 1 个照着配置必失败，而且你根本不知道------因为 HTTP 200 会骗过所有"只看能不能连上"的检查。你的 agent 只会"变笨"，不会报错。
这也是"能 ping 通 ≠ 能用"的最极端例子：协议级检查（握手成功）才是唯一可信信号。
发现二：3 个"诈尸"端点（持续监控的独特价值）
text
newmexicoliteracyproject.org/api/mcp healthy 83.3%（6 轮里 5 过 1 挂）
openaccountants.com/api/mcp healthy 83.3%
mcp.airtreks.com/mcp healthy 83.3%这 3 个端点在 1.5 小时里各"死"了至少一次又恢复。
这种间歇性故障才是最坑的 ：你测试的时候它活着，agent 生产调用时它刚好挂在那个窗口，静默失败一次，然后它又活了------你永远查不到原因。单次审计（哪怕 Apigene 测 2181 个）对此完全无能为力，只有持续监控能发现。
发现三：健康的端点也不快
56 个稳定健康端点的握手延迟：
text
p50 ≈ 2,955ms（中位数约 3 秒）
p90 ≈ 4,196ms
最慢 4,911ms（shiply.now）
没有 1 个低于 1 秒⚠️ 说明：我经代理（127.0.0.1:7897）中转测量，绝对值含代理 RTT，不能直接当真实网络延迟；但相对差可达 5 倍，这个结论是有效的。
agent 一次任务循环调用工具 10-50 次，慢端点意味着几十秒纯等待------延迟也是 MCP 生态被忽视的"隐性不可用"。
补充：大厂官方端点也在漂移（冒烟样本）
| 端点 | 结果 | 说明 |
|---|---|---|
mcp.sentry.dev/sse |
410 | 官方 SSE 端点已退役 |
observability.mcp.cloudflare.com/sse |
410 | 同上 |
mcp.linear.app/sse |
404 | 迁移后旧地址失效 |
mcp.paypal.com/sse |
401 | 活着，需认证 |
mcp.avots.ai/ |
401 | 活着，需认证 |
agentbodega.store/mcp |
healthy | 稳定可用（4 工具） |
连 Sentry、Cloudflare、Linear 的官方端点都在退役/漂移------文档里过时的 URL 是"静默炸弹"。
为什么这很重要
- 对开发者：23% 假端点 + 3 个诈尸端点 + 大量 3 秒级延迟 = 你"以为在用的" MCP server 实际可用率远低于直觉。排查"agent 变笨"问题时，先检查依赖端点的健康。
- 对生态 ：registry 收录 ≠ 可用，健康徽章（类似 npm 的维护状态）是缺失的信任基础设施。
- 对工具 ：传统 uptime（HTTP 200 检查）在这个生态里是失效的------握手成功才是唯一标准。协议级健康检查 + schema 漂移检测 + 持续监控（捕捉诈尸端点）是明确空档。
自检清单：你的 MCP 依赖健康吗
- 列出你配置的所有远程 MCP server URL（Claude Desktop / Cursor / Claude Code 的配置文件里）
- 逐个做 initialize 握手（用上面的 curl 命令，或工具）
- 能返回 JSON-RPC result 才算活着；返回 200 但非 JSON-RPC = 假端点
- 连续测 3 次以上（间隔几分钟）------识别诈尸端点
- 记录每次握手延迟------>3s 的端点考虑换托管
方法（可复现）
- 工具：纯 Python 标准库探针（initialize + tools/list，SSE 用 GET，失败重试 3 次）
- 数据：103 端点 × 6 轮 = 618 条探测记录（含逐轮分类与延迟）
- 口径：与 Apigene 4 月审计（目录全量 52% dead）样本性质不同，不能直接对比------但两者合起来说明：目录全量一半是死的，连社区精选也只有 54% 稳定可用，"能被列出 ≠ 能用"。
纯调研，无产品推广。评论区聊聊：
- 你自己托管/依赖远程 MCP server 吗？现在怎么确认它还活着？
- 遇到过"server 挂了但 agent 没报错"的静默失败吗？频率如何？
- 如果有个工具：填 URL 就能持续监控 MCP server 健康 + schema 漂移告警（支持飞书/钉钉/Slack），你会用吗？愿意付多少/月？