基于 MCPMarkets 全量目录的一次数据分析 —— 2026 年 10 月 17 日快照
我们把 GitHub 上能找到的 MCP server 和 Agent Skill 公开数据全量采集、分类、再统计了一遍，想看清这个生态的真实形状，而不是发布稿里的形状。快照时刻目录共有 13,598 个已发布条目，本文分析的是其中去重后实际抓到的 12,534 个条目（5,945 个 MCP server，6,589 个 Agent Skill），覆盖率约 92%。
结论不是一条健康的「长尾」。它更像：一个极高但极窄的头部，一片宽阔而温吞的中下部，以及中间一条很深的缝隙。
先说三个主要发现：
- 头部比大多数人以为的更窄。 star 数前 1% 的仓库拿走了 server 侧全部 star 的 47.5%（skill 侧 41.7%）；前 10% 拿走约 83%。基尼系数 0.867（server 侧）与 0.882（skill 侧）。
- 「中产」几乎不存在。 62.8% 的 MCP server 不足 100 星，中位数只有 64；均值/中位数之比 8.4 倍。
- Skill 侧显著比 server 侧更热。 中位 star 160 对 64（2.5 倍）；84.6% 的 skill 仓库最近 6 个月有提交，server 侧为 64.2%；每五个 server 仓库就有一个已沉睡一两年。
关键数字
| 指标 | MCP server | Agent Skill |
|---|---|---|
| 分析条目数 | 5,945 | 6,589 |
| star 总量 | 3,211,236 | 14,168,570 |
| 中位 star | 64 | 160 |
| 不足 100 星占比 | 62.8% | 37.1% |
| 不足 1,000 星占比 | 93.1% | 78.1% |
| 最近 6 个月有提交 | 64.2% | 84.6% |
| star ≥ 10,000 的仓库 | 54 | 256 |
| 基尼系数 | 0.867 | 0.882 |
方法说明
数据来源为 MCPMarkets 目录（mcpmarkets.com），字段取自 GitHub 公开 API：stars、license、主语言、最近推送时间、README 内容。以下三点需要坦白，因为它们决定了结论的适用边界：
- 快照时间 2026-10-17。 采集窗口内目录本身仍在增长（约 3 小时新增约 690 个条目），对活跃数据集做分页拉取存在边界漂移。最终得到去重后的 12,534 个条目，对快照时刻 13,598 个已发布条目的覆盖率约 92%。分布型指标基本不受影响，绝对计数会小幅低估。
- server / skill 的划分是启发式的。 基于采集时的关键词与 README 特征判定。这个代价写在「局限」一节。
- star 是「关注度」的代理指标，不等于质量。 它更多反映 HN 帖、推文和 awesome 列表的互相推荐，而不是生产环境的使用。
发现一：10 个仓库，拿走了近两成的星
Server 侧 5,945 个仓库累计 3,211,236 个 star，分布极不均匀：
| 分位 | star 数 |
|---|---|
| p25 | 36 |
| 中位数 | 64 |
| p75 | 166 |
| p90 | 631 |
| p99 | 8,841 |
| 最大值 | 96,415 |
均值与中位数相差 8.4 倍，这通常意味着分布被少数极端值主导——事实正是如此：前 10 个仓库占了 server 侧全部 star 的 18.1%，前 1% 占了 47.5%。 基尼系数 0.867。
榜首需要单独说明：punkpeye/awesome-mcp-servers，96,415 个 star——它本质上是一份 awesome 列表，被我们的关键词规则归进了 server 类目（详见「局限」）。其后是 headroomlabs-ai/headroom（75,471）和 sansan0/trendradar（62,923）。
Skill 侧的头部更夸张。前 10 个 skill 仓库占全部 star 的 15.6%，而整个目录里 star 最高的仓库就是一个 skill 仓库——openclaw/openclaw，392,124 个 star，是 server 榜首的 4 倍。 其后是 vinta/awesome-python（327,970，同样是一份 awesome 列表）和 obra/superpowers（299,876）。
还有一条值得停下来看：anthropics/skills，181,394 个 star，license 字段为空。 制定协议的公司没有给自己的官方示例仓库标注许可证。这个问题我们在发现四里还会再遇到。
发现二：62.8% 的 server 活在一百星以下
头部故事的背面是长尾。Server 侧 star 分布直方图：
| star 区间 | 条目数 | 占比 |
|---|---|---|
| 0 | 229 | 3.9% |
| 1–5 | 122 | 2.1% |
| 6–10 | 27 | 0.5% |
| 11–50 | 2,072 | 34.8% |
| 51–100 | 1,301 | 21.9% |
| 101–500 | 1,490 | 25.1% |
| 501–1,000 | 296 | 5.0% |
| 1,001–5,000 | 292 | 4.9% |
| 5,001–10,000 | 62 | 1.0% |
| > 10,000 | 54 | 0.9% |
（各区间为闭区间，故「≤ 100」合计 63.1%；上文 62.8% 指严格不足 100。）
这不是一条平滑的长尾，而是一片宽阔的温吞平原加一条深谷：最大的一档在 11–50 星（占三分之一），第二档在 101–500 星，中间 51–100 星反而明显更窄，之后是一段很深的空档，对面才是四位数以上的头部。
93.1% 的 server 不足 1,000 星。不足 10 星的只占 6.3%，其中完全零星的 229 个（3.9%）。也就是说，「没人理会的仓库」是少数派；「有人用、但没人 star」才是这个生态的底色——它可能是某个团队的生产依赖，只是对其他人不可见。
Skill 侧形状相同，整体上移一档：37.1% 不足百星，78.1% 不足千星，中位数 160。
发现三：Skill 是全生态最拥挤的赛道
这是我们开工前没有预料到的一点：skill 仓库的热度明显高于 server 仓库。
- 中位 star：160（skill）对 64（server），相差 2.5 倍
- star 总量：14,168,570 对 3,211,236，4.4 倍
- 最近 6 个月有提交：84.6% 对 64.2%
- 沉睡 1–2 年：约 0% 对 20.4%
- star ≥ 10,000 的仓库：skill 256 个，server 54 个
有两种解释，大概率都成立：一是 skill 的创作门槛更低——一份 SKILL.md 就是交付物，不需要实现协议层；二是 skill 出现得更晚，正好赶上 agent 概念本身的热度。
对工具作者的含义有点反直觉：server 侧的入口看起来更空，但中位生存环境更冷。 如果你做 server，把「确实在维护」这件事做实，本身就是差异化（见发现六）。
发现四：许可证出奇地宽松，真正的问题是「没有许可证」
Server 侧 license 分布：
| License | 占比 |
|---|---|
| MIT | 58.4% |
| Apache-2.0 | 13.5% |
| 未标注（GitHub 未识别） | 16.1% |
| NOASSERTION（无法匹配） | 5.7% |
| AGPL-3.0 | 2.1% |
| GPL-3.0 | 1.8% |
| 其他 GPL/LGPL/MPL/EPL 变体 | 约 2% |
归并看：宽松系（MIT、Apache、BSD、ISC、CC0、Unlicense 等）在 server 侧占 73.2%；有传染性的 copyleft（AGPL + GPL）合计仅 5.0%。Skill 侧类似：MIT 53.5%、Apache-2.0 11.6%，宽松系 66.4%，copyleft 2.9%。
对使用者来说这是好消息：闭源商用、商业内嵌、二次分发，基本不会撞上许可证墙。
真正的风险是模糊：「未标注 + NOASSERTION」两项在 server 侧合计 21.8%，在 skill 侧合计 30.4%。「没有许可证」是每个使用者都得自己回答的问题——而多数人会答错。目录站把这一字段原样、逐条展示出来，本身就是一种服务。
发现五：安装方式是生态最薄弱的一环
这个发现来自对 README 的解析。我们尝试为每个 server 抽取一条可直接执行的安装命令（形如 npx -y @modelcontextprotocol/server-xxx），以及一段可复制的 mcpServers JSON 配置：
- 只有 28.7% 的 server 能抽出一条可执行安装命令
- 只有 34.5% 含可用的配置片段
换句话说，超过七成 MCP server 的安装路径是断的。 用户读完 README 仍然不知道那条唯一要跑的命令——要么只给了源码仓库地址，要么把配置示例埋在几百行散文里，要么用一句 npm install 带过。
对比之下，skill 侧的安装命令抽取率是 100%，因为安装路径天然统一：npx skillfish add owner/repo/path。一个约定，零歧义。
对维护者来说，这是成本最低的差异化：把安装命令和 JSON 配置提到 README 最前面，各自用独立的代码块。十分钟的工作，换的是「用户留下」还是「用户划走」。
发现六：三分之二在活跃开发，五分之一在沉睡
按最近一次推送时间衡量（截至 2026-10-17）：
| 时间段 | Server | Skill |
|---|---|---|
| 6 个月内 | 64.2% | 84.6% |
| 6–12 个月 | 15.3% | 13.6% |
| 1–2 年 | 20.4% | 约 0% |
| 无记录 | 0.1% | 1.7% |
每五个 server 就有一个已经一两年没动过。考虑到 MCP 的客户端配置格式与传输方式在这一窗口内变过不止一次，其中相当一部分大概率已经不可用——但它们仍然躺在各个目录的收录列表里，而且常常因为按 star 排序而排在前面。
「还在维护」比「star 多」更有用，而且展示成本很低：这就是我们在目录里给每个条目标注最近推送时间的原因。
如果你是这条赛道上的作者
三条行动建议，按投入产出排序：
- 不要把 star 当目标。 62.8% 的 server 不足百星，中位数 64。40 星的 server 不是失败，是常态。优化「那一个采用它的团队」，而不是时间线。
- 先修安装命令。 十个仓库里有七个是断的。一条可复制的命令加一段现成的
mcpServers配置，是这个生态里性价比最高的十分钟。 - 保持维护就够了。 五分之一的 server 仓库在沉睡。你只要真的在做、并且还在更新，就已经处在「下个季度仍然可用」的前 20%——而且这一点可以直接从你的提交时间看出来。
最后给读生态数据的人一个提醒：头部是列表，尾部才是市场。 star 最高的一批仓库里，有相当比例是 curated 列表和聚合器——server 榜首就是一份 awesome 列表，skill 第二名也是一份。真正在供货的软件，藏在 11–50 和 101–500 这两档里，也就是没人写发布稿的那部分。
局限
诚实交代，供读者判断结论的适用边界：
- 分类噪声。 条目按关键词规则入库，混入了一些明显是列表的仓库（punkpeye/awesome-mcp-servers 被归为 server，vinta/awesome-python 被归为 skill）。这会让头部数字偏高，但不影响长尾的分布形状。
- star 不等于质量。 star 受曝光驱动，与使用量并不等价；一个几十星的 server 可能是某个团队的生产依赖。
- 单一数据源。 没有纳入 npm/PyPI 下载量等行为数据，无法区分「被 star」与「被使用」。
- 快照漂移。 覆盖率约 92%（见方法一节），绝对计数偏保守。
- 我们的分类体系还早期。 server 侧 89% 的条目集中在 devtools 一个类目下，skill 侧还没有有效的类目划分，因此本文不做类目维度分析。
文中所有数字都可以从公开目录复现。如果发现问题，欢迎告诉我们——我们更愿意修正，而不是辩护。
探索数据
- 浏览目录：MCP server 与 Agent Skill
- 按分类浏览：例如 开发者工具，列表页带分类筛选
- 每个条目都带安装命令、质量分、最近推送时间与许可证
本文是 MCP Ecosystem Report 的第一期，计划按季度更新。下一期：类目维度分析与安装命令覆盖率的变化趋势。
关于 MCPMarkets。 我们采集、分类并维护一个多语言（中/英/日/韩/俄）的 MCP server 与 Agent Skill 目录，收录 13,000+ 条目，每条带安装命令、质量分与维护信号。目标不是把所有东西列出来，而是让那个真正有用的东西被找到——并附上真正影响选型的字段。
*数据：MCPMarkets 目录公开快照，2026-10-17。由 MCPMarkets 团队撰写。