六个站：Awesome MCP Server、Smithery、MCP.so、MCP Run、官方站点、MCP Hub。 它们的通病只有一句：收录的是快照，不是实时状态。 谁先抓的，谁就旧。 所以判断顺序是：源码 > 最新那条记录 > 谁都不信，自己跑一遍。
上一节那五个入口收录量有限但整齐，这一节这六个反过来：量大、杂乱、版本对不上。 同一个 Server 在三个站上有三个版本号，这不是异常，是常态。 所以这一节的重点是「怎么用一分钟验证版本」，不是「哪个站更全」。
一、六个站，三种形态
Awesome 那个是一份清单，纯 markdown，按分类列链接。 它的价值是人工筛过一遍，缺点是更新靠提交 PR，容易积压。 Smithery 和 MCP.so 是正经的目录站：有搜索、有分类、有安装命令，能直接复制一段配置。 MCP Run 偏「在线试」，能把一个 Server 跑起来看看返回什么。
官方站点给的是规范文档和参考实现，不是目录。它是唯一该当准的地方，但它不告诉你有啥现成的。 MCP Hub 这类聚合站，本质上是在别人的目录上再做一层索引，所以更容易旧。 形态决定了它有多旧：人工清单最容易积压，自动抓取的相对新，二次聚合的最旧。
二、同一个名字，三个版本
演示里三个目录站各有一条记录：1.0.0 收录于 2025 年 6 月、1.3.0 收录于 2026 年 2 月、 还有一条把传输写成 http。 名字一样，版本从 1.0.0 到 1.3.0，传输方式一个说 stdio 一个说 http。 这三个都可能是真的，只是抓取时间不同。目录站抓一次就存下来，下次抓可能是半年后。
最坑的是传输方式那条：stdio 和 http 的配置写法完全不同，照着错的写，连不上还查不出原因。 所以看到「传输方式」这一栏，先当它可能过期。配置写完连不上，先怀疑这一栏。
三、该信哪条：源码 > 最新记录 > 自己跑
演示里补了第三条记录：源码仓库里是 1.4.0，三个工具。 三个工具和两个工具的差别，直接影响模型能不能答「有没有预警」这类问题。 【版本号差一个小数位，能力可能差一整块。】 所以顺序是：先看源码仓库的 tag 和 release，再看目录站里最新的那条， 最后——也是最可靠的——自己跑一遍。
自己跑一遍只要一条命令：发 initialize，看回来的 serverInfo.version。对不上，就是目录站旧了。 这一步花十秒，能省掉后面半小时排查——【因为你排查的是旧版的行为】。
四、装之前问三句话
第一句：它真的是这个版本吗？看 initialize 回应里的 serverInfo，版本号要对得上。 第二句：它真的有这些工具吗？看 tools/list，名字和个数都要对。 第三句：它真的能跑通吗？随便调一个最轻的工具，返回不是 error。
三句话问完，心里就有底了，加起来不到一分钟。 目录站的价值是「发现」，不是「保证」。 它帮你找到名字，剩下的得自己验。 把这句话记住，能省很多火气。
五、国外站的两个额外门槛
第一是网络。这些站大多在墙外，配置里的 Server 也要去拉依赖，装到一半卡住是常事。 国内平台的第一个优势就在这里。 第二是许可与合规。 国外仓库的许可写得清楚，但「写得清楚」不等于「你能用」——有的许可禁止商用，有的要求开源你的修改。 这两条都不在六格体检卡里，但它们是真实门槛。打分之前先确认能不能访问、能不能用。
顺带一句：国外站的工具描述大多是英文。这对模型不是问题——英文描述通常更准确，反而少见歧义。
六、动手 Demo：同一个名字，三个版本
同一个 Server 在三个目录站上各有一条记录，版本、日期、传输方式都不一样。 再把源码仓库那条补上，看该信哪个。最后真发一次 initialize，看回来的版本号。 initialize 那一段是真跑的，用的是第 1 章那个最小 Server 顶替。
RECS = [('目录站 A', '1.0.0', '2025-06-01', 1, 'stdio'),
('目录站 B', '1.3.0', '2026-02-14', 2, 'stdio'),
('目录站 C', '1.0.0', '2025-06-01', 1, 'http'),
('源码仓库', '1.4.0', '2026-10-11', 3, 'stdio')]
for src, ver, day, n, trans in RECS:
print('%-8s %-6s %s %d 个工具 %s' % (src, ver, day, n, trans))
# 自己跑一遍最省事：看 serverInfo.version
c = Stdio('.../srv/mini.py')
info = c.init()
print('serverInfo.version =', info['serverInfo']['version'])
print('tools =', [t['name'] for t in c.tools()])
实跑输出：
--------------------------------------------------------------------
同一个名字，三个版本
--------------------------------------------------------------------
① 三个目录站，三条记录
--------------------------------------------------------------------
| 来源 | 版本 | 收录日期 | 工具数 | 传输 |
|---|---|---|---:|---|
| 目录站 A | 1.0.0 | 2025-06-01 | 1 | stdio |
| 目录站 B | 1.3.0 | 2026-02-14 | 2 | stdio |
| 目录站 C | 1.0.0 | 2025-06-01 | 1 | http |
名字一样，版本从 1.0.0 到 1.3.0，传输方式一个说 stdio 一个说 http。
【目录站收录的是快照，不是实时状态。】谁先抓的，谁就旧。
② 该信哪条
--------------------------------------------------------------------
按这个顺序：源码 > 最新那条记录 > 谁都不信，自己跑一遍。
| 来源 | 版本 | 工具数 | 能不能当准 |
|---|---|---:|---|
| 目录站 A | 1.0.0 | 1 | 不能，一年前的 |
| 目录站 B | 1.3.0 | 2 | 比较新，但不全 |
| 源码仓库 | 1.4.0 | 3 | 以它为准 |
三个工具和两个工具的差别，直接影响模型能不能答「有没有预警」这类问题。
【版本号差一个小数位，能力可能差一整块。】
③ 自己跑一遍最省事
--------------------------------------------------------------------
一条命令就能验证版本对不对。这里用第 1 章那个最小 Server 顶替——
真机上换成一个你要验的 Server 就行，动作一模一样：
>> {"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05",
"capabilities":{},"clientInfo":{"name":"demo-client","version":"0.1.0"}},"id":1}
<< {"jsonrpc": "2.0", "id": 1, "result": {"protocolVersion": "2024-11-05",
"capabilities": {"tools": {}}, "serverInfo": {"name": "mini", "version": "0.1.0"}}}
serverInfo.version = 0.1.0
回来看 serverInfo.version。和目录站对不上，就是目录站旧了。
这一步花十秒，能省掉后面排查半小时——【因为你排查的是旧版的行为】。
④ 装之前的三句话
--------------------------------------------------------------------
| 问题 | 在哪看 | 判据 |
|---|---|---|
| 它真的是这个版本吗 | initialize 回应里的 serverInfo | 版本号对得上 |
| 它真的有这些工具吗 | tools/list | 名字和个数都对得上 |
| 它真的能跑通吗 | 随便调一个最轻的工具 | 返回不是 error |
三句话问完，心里就有底了。加起来不到一分钟。
! 目录站的价值是「发现」，不是「保证」。它帮你找到名字，剩下的得自己验。
①第一张表四行，两个目录站给了同一个版本号 1.0.0，但传输方式一个写 stdio 一个写 http。 照着错的那个写配置，连不上还查不出原因。 ②第二行那条 1.3.0 是「比较新但不全」。目录站 B 抓得晚，但抓的时候源码已经到 1.4.0 了。 ③第三段是源码仓库那条：1.4.0，三个工具。三个和两个的差别，直接决定模型能不能答某一类问题。 ④最后两行是真跑出来的。serverInfo.version 这一行是本节最值钱的一行——十秒能验完，省半小时排查。 ⑤记住那句：目录站的价值是发现，不是保证。它帮你找到名字，剩下的自己验。
30 秒实验
- 随便找一个 Server，在三个目录站上搜它的名字。看版本号是不是一样。
- 发一次 initialize，把 serverInfo.version 和你看到的目录站版本对一下。
- 查一个国外仓库的许可，看它是不是允许商用。这一条比功能重要。
常见误区
- 「目录站写的就是最新的。」收录的是抓取那天的快照。越靠后的聚合站越旧。
- 「传输方式不会变。」stdio 和 http 都出现过在同一个项目的不同阶段。配置连不上，先怀疑这一栏。
- 「源码太麻烦，看目录站就够了。」源码是唯一能当准的地方，而且它只多花你一次点击。
自测三问（点开对答案）
1. 为什么同一个 Server 在三个站上会有三个版本号？ —— 目录站抓一次就存下来，抓取时间不同。收录的是快照，不是实时状态。 2. 验证版本最省事的办法是什么？ —— 发一次 initialize，看回来的 serverInfo.version。十秒，比翻文档快。 3. 国外目录站的两个额外门槛是什么？ —— 网络能不能访问，许可能不能商用。这两条不在六格体检卡里，但很实际。目录站看完了，下一节看最后一个渠道：社区。它不解决「有没有」，解决「坏了我该去问谁」。
- ☐ （本篇完，下一篇 5.3 社区）