打造收录 28,577 个 MCP 服务的导航站：大规模发现工程实践

Model Context Protocol (MCP) 的兴起从根本上改变了我们将 LLM 连接到本地和远程数据源的方式。然而，随着生态系统的扩张，一个显著的问题出现了：发现（Discovery）。寻找一个可靠的 MCP 服务通常意味着要翻遍 GitHub 上过时的 awesome-list，或者依赖那些只涵盖一小部分内容的各种聚合网站。为了解决这个问题，我构建了一个包含 28,577 个经过验证的 MCP 服务的综合目录。这个项目不仅仅是关于数据收集，更是一次在保持基础设施成本接近于零的同时，大规模扩展技术索引的实践。为了驱动这类高实用性的 AI 应用，开发者们越来越多地依赖像 n1n.ai 这样高速、稳定的 API 聚合器，以确保他们的智能体保持敏捷响应。

痛点分析：MCP 生态的碎片化

目前 MCP 服务的发现机制处于一种混乱状态。大多数开发者通过 GitHub 上的“精选列表”寻找服务，但这些列表往往维护不善。许多聚合站只显示实际存在的一小部分服务，且通常基于人工筛选进行过滤。此外，目前还缺乏一种标准化的、按功能浏览的方式。如果你需要一个 PostgreSQL-MCP 封装器，你可能会找到一打选项，但无法得知哪一个真正正确实现了协议，或者哪一个最近有更新。

我想要一个扁平化的、可搜索的所有公开 MCP 服务索引，并按意图分类。目标很简单：提供一个单一的真相来源，将信号与噪声分离。为此，我编写了一个扫描器，从 GitHub 代码搜索、GitHub API 以及几个发布列表的聚合站点抓取候选者。然后通过所有者/名称对数据进行去重，并进入严格的分类流水线。

分类流水线：Gemini 与 Claude 的权衡

面对超过 30,000 个候选对象，人工分类是不可能的。每个候选仓库都会通过一个分类器执行两项任务：

1. 验证：确认该仓库确实实现了 MCP 协议，而不仅仅是在 README 中提到了它。
2. 分类：从 95 个特定类别中分配一个，并提取简明描述。

在分类器的选择上，我通过 OpenRouter 使用了 Gemini Flash。虽然我使用 Claude 3.5 Sonnet 和 GPT-4o 进行了抽样检查，但发现 Gemini Flash 的准确率足以胜任批量处理，且成本极低。分类整个候选池的总支出约为 8 美元。这种效率在构建开发者工具时至关重要；同样，使用 n1n.ai 允许开发者通过一个成本效益极高的接口访问 OpenAI o3 或 DeepSeek-V3 等多种高端模型。

架构设计：攻克 20,000 个静态资产限制

在部署一个拥有 28,000 多个独立页面的站点时，标准的部署策略往往会失效。我考虑了三种架构方案：

• 纯静态 (Pure Static)：加载速度最快，托管费用为 0。但 Cloudflare Workers 免费版有 20,000 个静态资产限制，项目还没上线就会超限。
• 纯服务端渲染 (Pure SSR)：没有构建时的限制，数据动态。但每次访问都会触发 Worker 调用，增加了成本和延迟。
• 混合模式 (Hybrid)：这是我最终选择的方案。利用 Astro 的混合模式，将流量最高的约 100 个页面（首页、浏览页、搜索页、分类页）预渲染为静态 HTML。而 28,000 多个具体的服务器详情页则是动态的。

在混合模式下，详情页在首次请求时会查询 Cloudflare D1（边缘侧的 Serverless SQLite 数据库）。渲染后的 HTML 会由 Cloudflare 的 CDN 缓存 24 小时。这意味着热门页面的访问速度与静态资产一样快，同时完美规避了资产数量限制。在测试这些海量数据时，n1n.ai 提供的稳定 API 支持确保了分类脚本的高并发运行。

突破 Cloudflare D1 的限制

实现 Cloudflare D1 的过程中也遇到了不少挑战。在最初的数据导出脚本中，我尝试每条语句批量插入 500 行数据。这立即触发了 SQLITE_TOOBIG 错误。

专家提示：Cloudflare D1 将单个 SQL 语句的大小限制在 100KB 以内。这个限制在官方主文档中并不容易找到。为了解决这个问题，我将每条 INSERT 的批量大小降低到 50 行。这使得生成的 SQL 文件增加到约 570 条语句，Wrangler CLI 随后顺利完成了同步。

.assetsignore 避坑指南

Astro 的 Cloudflare 适配器有一个容易让人困惑的行为：它会将 _worker.js（SSR 入口点）和预渲染的 HTML 输出到同一个 /dist 目录。Wrangler 随后会尝试将 _worker.js 作为静态资产上传。这不仅占用了一个资产名额，还经常因为文件过大而导致上传失败。

修复方法是在 public/ 目录下创建一个 .assetsignore 文件，列出以下内容：

_worker.js
_routes.json

这确保了 Cloudflare 将 Worker 视为功能脚本而非静态文件。这个小小的配置花费了我一个小时才排查出来，因为错误信息并没有直接指向这里。

成果与性能表现

该目录（safemcp.info）上线时共收录了 28,577 个经过验证的服务，涵盖 95 个类别。在上线后的 24 小时内，它就在 Reddit 的 MCP 板块冲到了第一名。

一个有趣的发现是，约 20% 的服务器被归类为“其他（Other）”。由于 MCP 协议非常新，许多开发者正在构建极其小众的工具，无法放入传统的分类桶中。我选择在首页公开展示这一点，而不是将其隐藏，以体现该协议的多样性。

当你构建利用这些服务器的智能体时，瓶颈往往在于底层 LLM 的 API 延迟。通过使用 n1n.ai 这样的服务商，你可以确保对 Claude 3.5 Sonnet 或其他模型的调用通过最快的路径进行路由，从而与边缘托管的目录速度相匹配。

安全性与发现信号

目录中的每个服务器都有一个 0-100 的“发现评分”，这是基于元数据（GitHub Star 数、描述质量、多源存在感）计算的。需要强调的是，这只是一个发现信号，而非全面的安全审计。在将任何 MCP 服务器连接到你的本地环境或敏感数据之前，请务必亲自审查源代码。

这个项目证明了，结合边缘计算与 LLM 辅助分类，我们可以为即使是最碎片化的技术生态系统带来秩序。如果你需要稳定且快速的 API 来运行这些 MCP 插件，n1n.ai 是你的理想选择。

Get a free API key at n1n.ai