切换主题
10000+ MCP 服务器生态全景：哪些品类已经成熟
MCP（Model Context Protocol）从 2024 年 11 月发布到现在，不到两年。但如果你最近打开任何一个 MCP 目录，数字已经让人不知道该信哪个：Glama 收了 66,000+（截至 2026 年 8 月），MCP.so 收了 20,000+，GitHub 上打 mcp-server 标签的仓库 15,900+。33 个注册表各自收录，彼此重叠但不完全一致，综合去重后大概 12,000 个可用服务器。
多，不等于都能用。我想搞清楚一件事：在这个已经膨胀到五位数的生态里，哪些品类真的成熟了，哪些还早。
文中的数据主要来自官方 Registry API、Glama/PulseMCP 等社区目录、Stacklok 2026 软件行业调查以及 arXiv 等公开安全研究报告，截止 2026 年 8 月。生态变得很快，过两个月数字会更新，但品类判断的逻辑不会变。
一、生态总规模
| 指标 | 数值 | 来源 |
|---|---|---|
| 官方 Registry 记录 | 9,652 | Registry API（2026-05） |
| Glama 索引服务器 | 66,701 | Glama（2026-08） |
| GitHub mcp-server 话题仓库 | 15,926 | GitHub Search API（2026-05） |
| 综合去重后可用服务器 | ≈12,000+ | 综合 33 个注册表 |
| 月度 SDK 下载量 | ≈5 亿（Tier1 口径） | Anthropic 2026-07 公告 |
| 组织生产环境采用率 | 41% | Stacklok 2026 调查 |
| 官方 Servers 仓库 Stars | 84,000+ | GitHub API / awesome-mcp.tools（2026-05） |
不同目录的数字有差异是因为口径不同。Glama 自动索引任何公开 GitHub 仓库（截至 2026 年 8 月已超 66,000），Smithery 这类平台收录约 5,000 个，有筛选但远非"精选到几百"。这个差距本身就是生态的一个特征：分布极不均匀，大量服务器的质量一言难尽。
二、五大品类的成熟度
按 learnagent.org 基于 Registry API 的工具分类统计（注：此处的百分比基数约为官方 Registry 的 ~9,600 条，与前述综合去重的 12,000+ 口径不同），全部服务器可以归入五个大类。各品类之间的成熟度差距很大。
品类一：Connectors / SaaS（约 38% | 约 3,500 个）
SaaS 连接器是体量最大的品类。Slack、GitHub、Notion、Linear、Jira、Gmail，这些日常工具都有成熟的 MCP Server。
为什么说这个品类成熟？看三点。
第一，厂商自己下场了。GitHub 的 MCP Server 是官方 Go 实现，29,000+ stars。Salesforce 的 MCP Server 已经包含了 OAuth 2.1 + 多租户 + 审计日志的完整企业级参考实现。Stripe 也发了官方 Server。厂商自建取代社区自建，是这个品类最大的成熟信号。它意味着接口稳定、安全合规有人负责，不是某个开发者周末的兴趣项目。
第二，覆盖够全。主流 SaaS 里我还没想到哪个缺 MCP Server 的。即使官方没出，社区版本也已经能用。Notion MCP、Slack MCP 的社区版本在多个目录里都是高星项目，维护了好几个版本，不算半成品。
第三，用户已经养成了习惯。在 Claude Desktop 或 Cursor 里配一个 GitHub Token 然后直接操作 Issue 和 PR，已经是很多开发者的日常。这种"默认就应该有"的心态，比任何数字都说明问题。
如果只挑一个品类来判断 MCP 整体成熟度，我会选 Connectors。
品类二：Developer Tooling（约 27% | 约 2,500 个）
这是 MCP 最早起跑的赛道，也占据着 GitHub Stars 榜单的主力。
Top 10 按星的 MCP Server 里，Developer Tooling 占了 7 席（其余 3 席分属 System、Data）：
| 排名 | Server | Stars | 品类 | 做什么 |
|---|---|---|---|---|
| 1 | microsoft/markitdown | 119K+ | Dev Tooling | PDF/Office/HTML → Markdown |
| 2 | modelcontextprotocol/servers | 84K+ | Dev Tooling | 官方参考实现集（filesystem/git/memory 等） |
| 3 | netdata/netdata | 78K+ | System | 基础设施实时监控 |
| 4 | upstash/context7 | 54K+ | Dev Tooling | 实时库文档注入 prompt |
| 5 | mindsdb/mindsdb | 39K+ | Data | 200+ 数据源聚合 |
| 6 | microsoft/playwright-mcp | 31K+ | Dev Tooling | 浏览器自动化 |
| 7 | bytedance/UI-TARS-desktop | 29K+ | System | GUI Agent 操控桌面 |
| 8 | github/github-mcp-server | 29K+ | Dev Tooling | GitHub 官方 |
| 9 | claude-task-master | 26K+ | Dev Tooling | PRD 驱动的任务编排 |
| 10 | jlowin/fastmcp | 24K+ | Dev Tooling | Python Server 开发框架 |
这个品类成熟的原因不复杂：MCP 的第一批用户就是开发者。filesystem + git + GitHub 是"每个开发者必装三件套"，使用频率最高，反馈迭代最快。Anthropic 官方维护的参考实现（Filesystem、Git、Memory、Sequential Thinking）都落在这个品类里，相当于给整个品类设了一条质量基线，其他项目会自然向它看齐。
目前这个品类还在往新方向扩展。bytedance/UI-TARS-desktop（29,000+ stars）把 GUI Agent 引入了 MCP，不只是 IDE 里操作代码，还能直接操控桌面软件。如果这块跑通了，Developer Tooling 的边界会大一圈。
品类三：Data & Search（约 18% | 约 1,700 个）
数据库连接是刚需，这没啥争议。PostgreSQL、SQLite 有 Anthropic 官方维护的参考实现，稳定性有保证。Brave Search 也有官方 Server。
但内部质量分化很严重。官方维护的 PostgreSQL 和 SQLite 是标杆，MongoDB、Redis、MySQL、BigQuery 这些长尾引擎主要靠社区。有的维护勤快，有的 README 已经和实现对不上了。你没法不看源码就信任它。
有一个趋势我比较关注：聚合网关。MindsDB（39,000+ stars）用一个 MCP 端点聚合了 200+ 数据源（Postgres、Snowflake、Salesforce、Slack），不需要为每个数据源单独装一个 Server。这个模式比"一个数据库一个 Server"高效得多，在数据品类里有可能成为主流。
搜索子类里，Firecrawl 和 GPT Researcher 等网页抓取工具增长很快，但 Brave Search 之外还没有第二个厂商官建的搜索 Server。
数据品类算"接近成熟"。核心引擎稳了，长尾覆盖和搜索子类还有缺口。
品类四：System & Browser（约 11% | 约 1,000 个）
赛道窄，但玩家强。
浏览器自动化由 Playwright MCP（31,000+ stars）和 Puppeteer 统治，没有争议。微软官方维护的 Playwright MCP 已经是事实标准。本地系统操作由 filesystem 和 shell 两个官方 Server 覆盖。Netdata（78,000+ stars）把基础设施监控接入了 MCP，你可以直接问 AI"Host X 上为什么 CPU 飙升"，它从 Netdata 拉数据回答。
比较有意思的新方向是 Agent 操控 GUI。UI-TARS-desktop 和 Computer Use Agent（CUA）正在把 MCP 从操作 API 扩展到直接操作屏幕。这块目前还早，但如果成熟，System 品类的范围会大很多。
品类五：Creative & Content（约 6% | 约 560 个）
内容创作和设计是 AI 最直观的应用场景，却是 MCP 生态里最弱的品类。
Figma MCP 是目前唯一有厂商背书的选项。Image generation 和 video generation 类 MCP Server 数量少、维护不稳定，基本就是把已有的生成 API 简单包装一层，没有深度集成。Slide 和 design 工具更接近空白。
说实话，这个品类有点反直觉。按道理创意工具应该最先被 AI 改造，但在 MCP 生态里它进度最慢。可能的原因是创意工具本身就很复杂，简单的 API 包装不够用，需要更深的产品集成——而大部分工具厂商还没开始认真对待 MCP。现在先关注 Figma MCP 的进展就够了，其他方向还需要时间。
三、15 个细分品类一览
五个大类往下拆分出 15 个细分品类，按成熟度排列：
| 品类 | 数量 | 成熟度 | 代表 Server | 备注 |
|---|---|---|---|---|
| Developer Tools | 150+ | ★★★★★ | Filesystem, GitHub, Playwright | 最早最成熟 |
| Databases | 100+ | ★★★★☆ | PostgreSQL, SQLite, MongoDB | 主流引擎全覆盖 |
| Productivity | 100+ | ★★★★☆ | Slack, Notion, Linear, Gmail | 厂商自建加速 |
| Cloud Providers | 80+ | ★★★★☆ | AWS, Cloudflare, GCP | 三大云已入局 |
| Enterprise Systems | 60+ | ★★★☆☆ | Salesforce, SAP, Jira | Salesforce 已有企业级实现 |
| Search & Knowledge | 50+ | ★★★☆☆ | Brave Search, Wikipedia | 搜索品类偏弱 |
| Document Processing | 50+ | ★★★☆☆ | markitdown, PDF parsers | markitdown 119K stars 独大 |
| Vector DB / RAG | 40+ | ★★★☆☆ | Chroma, Pinecone, Qdrant | RAG 刚需但实现分散 |
| Data & Analytics | 40+ | ★★★☆☆ | BigQuery, Snowflake | 分析类工具偏少 |
| Browser Automation | 30+ | ★★★★★ | Playwright, Puppeteer | 窄但极成熟 |
| Monitoring | 25+ | ★★☆☆☆ | Datadog, Sentry | 可观测性起步中 |
| Code Execution | 20+ | ★★★☆☆ | E2B, Jupyter, sandboxes | 安全敏感，发展谨慎 |
| Finance | 20+ | ★★☆☆☆ | Stripe | 刚起步 |
| Design & Creative | 15+ | ★★☆☆☆ | Figma | Figma 独苗 |
| IoT & Hardware | 10+ | ★☆☆☆☆ | Smart home | 几乎空白 |
四、怎么判断一个品类是否成熟：四个信号
信号一：厂商自建比例
最直接的指标。厂商自己出的 Server 意味着接口稳定、安全合规、长期维护。Connectors 品类厂商自建比例最高（GitHub、Slack、Salesforce、Stripe），Developer Tooling 次之（Anthropic 官方 + 微软 Playwright），Data 品类以官方 PG/SQLite 为锚，往后大量依靠社区。
如果一个品类厂商都还没下场，它就不能算成熟。
信号二：独立目录生态
成熟品类的 Server 会在多个目录里出现，而且有评分、星级等质量信号。Glama 的 A-F 质量评级和安全评分卡是目前最有区分度的指标。BlueRock 对 7,000 个 MCP Server 的扫描发现 36.7% 的远程服务器存在潜在 SSRF 风险，用户已经开始按安全评分过滤了——这个行为本身就是生态成熟的标志。
信号三：GitHub Stars 集中度
Top 10 榜单中 Developer Tooling 占 7 席不是巧合。Stars 反映的是"有多少人用过"，间接说明该品类的使用频率。一个品类里如果有多个月下载过百万的项目，说明它已经是日常高频使用的工具。
信号四：企业级参考实现存在
AWS Bedrock AgentCore 贡献了 Tasks 扩展，Cloudflare Agents SDK Day 0 支持 MCP，Salesforce MCP Server 有完整的多租户审计日志实现。这些不是 demo，是给企业用户参考的生产级方案。Connectors 和 Developer Tooling 是唯二有完整企业参考实现的品类。
五、数量背后的质量隐忧
这部分结论不太好看，但不能跳过。
2026 年 7 月，一篇发表在 arXiv 上的论文（《Exposed by Design》，arxiv:2608.00150）对 414 个公网 MCP Server 做了动态安全审计，发现：
91.8% 没有启用 OAuth 认证。绝大多数公网 MCP Server 对任何请求来者不拒。
共发现 68 个可报告漏洞，包括 SQL 注入、SSRF 攻击云 metadata 服务、prompt 模板注入、路径穿越。
41.6% 的已确认服务器在三天内离线——快速部署，用完就扔，没有安全审查。
另一组来自 BlueRock 对 7,000 个 MCP Server 的分析：36.7% 的远程服务器存在潜在 SSRF 风险，可以被利用发起内部网络请求。
MCP Server 在你的机器上本地运行，它能读文件、发网络请求、访问凭据。91.8% 没有 OAuth，等于把敏感权限交给了一个黑盒。
这也解释了为什么"10000+ 服务器"这个数字实际含金量没那么高。大量仓库是 demo、fork、或者已经停更的项目。按"有安全文档 + 认证清晰 + 近期活跃维护"三个条件过滤，真正值得在生产环境用的可能不到 1000 个。
文中数据来源：learnagent.org / awesome-mcp.tools / mcpserverspot.com / dev.to / webmcpguide.com / Stacklok 2026 软件行业调查 / BlueRock MCP 安全分析 / arXiv:2608.00150。截止 2026 年 8 月。