AllMCPs：轻松发现和筛选MCP Server的目录站

这次我们来看一个 MCP 生态里的项目AllMCPs。它的定位不是模型不是推理框架也不是又一个大模型应用而是一个 MCP Server 的目录站。项目上线后就上了 Hacker News 的 Show HN说明 MCP 这个方向确实到了“需要整理和检索”的阶段。如果你最近的注意力都在 MCP 协议、Claude 接入、Dify 里配 MCP、Playwright MCP 这类话题上那你一定遇到过同一个问题MCP Server 太多了不知道哪个能用、哪个维护得勤、哪个适合自己。AllMCPs 想解决的就是这个发现和筛选问题。这篇文章会把它拆开讲它是什么、能解决什么问题、怎么用来查 MCP Server、自己的 MCP Server 怎么提交收录、以及拿到一个 MCP Server 之后怎么接入 Claude 或其他客户端并验证效果。适合的读者也很明确正在做 Agent 工作流、想给 Claude 或 Dify 接外部工具、自己开发 MCP Server 想被更多人看到或者只是在 MCP 信息流里找不到入手点的朋友。看完这篇文章你至少能搞清楚两条完整路径一条是怎么找一个能用的 MCP Server另一条是怎么把自己的 MCP Server 挂出去。1. 核心能力速览先给一张速览表从项目定位、交互方式到适合场景一次性看清。能力项说明项目类型MCP Server 目录 / 导航站主要功能收录、展示、检索 MCP Server提供项目地址、读我、简介等信息解决的问题MCP Server 分散在 GitHub、博客、社交媒体缺少集中发现入口交互方式网页浏览为主通常支持按分类或关键词筛选需要硬件部署不需要它是在线站点不是本地推理程序是否需要 GPU不需要是否支持本地接入本身不是 MCP Server不提供工具调用能力是否支持提交收录支持通常通过 GitHub 提交或站点表单提交是否支持 API从项目定位看未提及按目录站常见设计不一定提供开放 API适合场景找 MCP Server、做选型对比、发布自己的 MCP Server不适合场景直接做工具调用、搭建本地 MCP 代理、做协议解析这里有一个要提前说清楚的边界AllMCPs 是“发现层”工具不是“运行层”工具。它帮你找到 MCP Server但真正跑起来还是要在客户端里配置。后面第 6 节我会给接入示例。2. MCP 协议和 MCP Server 是什么为什么需要目录MCP 全称 Model Context Protocol它的作用是让大模型应用通过一套标准协议去访问外部工具和数据源。没有 MCP 的时候每个 Agent 要接数据库、接浏览器、接设计稿工具都得写各自适配的插件。有了 MCP 之后客户端、MCP Server、工具提供方三者之间有了统一的交互方式。现在的 MCP 生态其实已经非常热闹了。从最近的热度看大家都在搜这些方向Claude 怎么配置 MCP、Codex 怎么装 MCP、Dify 怎么添加本地 MCP 服务、Playwright MCP 怎么用、Figma MCP 能不能接到设计工作流里、支付宝 MCP 怎么开通。这说明 MCP Server 已经不是极客玩具而是真在往工具型、生产型方向发展。但问题也来了MCP Server 散落在 GitHub 仓库、个人博客、技术社区、甚至评论区里。你想找一个能读取本地数据库的 Server不知道该搜什么关键词你想找一个能操作浏览器的看到好几个同名项目不知道哪个在用、哪个有人维护你费了半天劲找到项目地址发现 README 不够清楚或者项目已经几个月没更新。AllMCPs 这类目录站的价值就在这里。它把所有 MCP Server 集中到同一个页面上给出标题、简介、链接、分类。你不需要在搜索引擎里来回跳可以先在目录里浏览一版再从里面挑几个点进 GitHub 看细节。对项目作者来说提交一个目录入口比自己到处发帖更持久。从目录站的角度看它更重要的是扮演“入口”角色把 MCP 的新用户和已有 Server 连接起来。对刚接触 MCP 的人最大的痛点不是不会配置而是不知道配什么。先有目录再有配置这个路径会更顺。3. AllMCPs 适用场景与使用边界3.1 适合谁正在给 Claude、Codex、Dify 等工具选 MCP Server 的集成工程师。想快速了解某个领域的 MCP Server 有哪些可选方案的开发者。自己开发了 MCP Server想增加曝光、让更多人试用和反馈的项目作者。做 Agent 自动化工作流需要在文件、数据库、浏览器、设计工具之间选择连接器的个人开发者和团队。3.2 不适合什么不适合想直接调用工具能力的场景。AllMCPs 只是目录不是 MCP 运行环境。不适合做深度功能对比。目录站通常只提供简介和链接具体能力还是要看 README 和源码。不适合拿来做协议层面的性能测试。MCP Server 的能力好坏与目录站无关。3.3 使用边界与合规提醒这里要多说一句。MCP Server 的本质是让 AI 客户端能够读取数据、操作工具、访问服务。权限一旦给大了风险也跟着变大。使用任何 MCP Server 之前有三件事必须确认数据访问范围这个 Server 会读取什么数据是本地文件、数据库、还是云端服务。操作权限边界这个 Server 是否能执行写操作、删除操作、支付操作。授权合规如果 Server 要访问设计稿、数据库、企业文档必须确认相关数据和资源的授权范围。涉及人脸、声音、版权素材、企业数据库和个人隐私数据时要尤其谨慎。安装一个 MCP Server 之前先看一下它请求哪些权限、有没有鉴权机制、数据是否回传。后面第 9 节我会给出更详细的检查清单。4. 使用 AllMCPs 查 MCP Server操作流程这是最基础的使用方式。虽然 AllMCPs 的具体界面细节会变但目录站的通用操作流程是稳定的。4.1 打开目录站并浏览分类打开 AllMCPs 后页面上通常会有项目列表和分类。建议先不要急着搜索花几分钟从分类看起。看一眼当前收录的 Server 集中在哪些领域大致就能判断目录的更新频率和维护情况。举例来说如果你在找浏览器自动化相关的 Server可以在分类里找 Browser、Web 或 Automation 相关标签。如果你在找数据库相关的 Server可以找 Database、SQL、Data 相关分类。4.2 用关键词筛选候选目录站一般支持关键词搜索。搜索时建议先不要用太具体的词比如直接搜 “database” 会比搜 “postgresql query tool” 更容易返回足够多的候选。对于 AllMCPs 这类目录建议这样搜索先搜大类database、browser、file、design、cloud。再看小类按项目简介中的详细描述进一步判断。最后点进 GitHub 看 README。如果你在找热门的 Playwright MCP、Figma MCP、蓝湖 MCP 这类设计协作相关的服务在目录里先看 Design 或 UI 分类能明显减少筛选时间。操作步骤汇总打开 AllMCPs 站点首页。查看总收录数量和最近更新时间判断活跃度。按分类浏览收集候选项目 3 到 5 个。进入项目详情页查看简介、GitHub 地址、维护状态。复制项目地址跳转到 GitHub 或官方文档确认安装方式。在客户端中按对应方式配置并验证。判断目录是否可用的一个标准找到的 Server 是否在近期有更新记录以及 README 里的安装命令是否仍然有效。如果项目中大量条目已经过期或者链接失效那么这个目录只能当历史参考。4.3 从目录条目提取关键信息在 AllMCPs 的条目页重点看这三项信息项目简介判断它是不是你要找的东西。项目链接点进 GitHub 看 star 数、最近 commit、issues 活跃度。面向的客户端有的 MCP Server 明确说明适配 Claude Desktop有的说明支持通用 MCP 客户端。这会影响后面怎么配置。不要只看目录页就决定用哪个。目录站是“索引”不是“最终判据”。最终还是要进 README 确认安装步骤和权限要求。5. 提交收录自己的 MCP Server如果你自己开发了 MCP Server想让更多人通过 AllMCPs 发现可以走提交流程。目录站通常有两种提交方式一种是在 GitHub 仓库里提 issue 或 PR另一种是在站点上填表单。没有表单的时候GitHub 提交流程最常用。5.1 GitHub Issue 提交模板如果 AllMCPs 使用 GitHub 管理收录可以在项目的 Issues 页面选择 New Issue按模板填入信息。一个标准的提交信息应该包含### 项目名称 - 项目名称your-mcp-server - 项目简介一句话说明这个 Server 能做什么 - 项目地址https://github.com/yourname/your-mcp-server - 适用客户端Claude Desktop / 通用 MCP 客户端 / 其他 - 授权协议MIT / Apache-2.0 / 其他 - 是否支持远程访问是 / 否 - 验证方式本地 stdio / HTTP SSE / 其他提交的时候要注意简介不要只写 “这是 MCP Server”要写明解决什么问题。比如“读取本地 SQLite 数据库并执行查询”就比“一个数据库 MCP”清晰得多。5.2 提交前准备提交之前建议先检查README 里有明确的安装步骤和运行要求。项目配置了 license。项目至少有一个可用版本而不是只有几行代码。有明确的示例或测试方式。目录站维护者最怕的是收集到一堆链接但点进去不能用。如果你能把“项目能跑通”这一点在提交前就证明清楚收录概率会高很多。6. MCP Server 接入客户端Claude Desktop 配置示例从 AllMCPs 找到合适的 MCP Server 之后接下来要接入客户端。配置方式跟具体客户端有关这里以 Claude Desktop 本地配置为例。这种配置方式也适用于大部分支持 MCP 的桌面客户端。6.1 本地 stdio 模式配置stdio 模式适合本地运行、通过标准输入输出通信的 MCP Server。在 Claude Desktop 中需要编辑客户端配置文件。Windows 下配置文件一般在%APPDATA%\Claude\claude_desktop_config.jsonmacOS 下配置文件一般在~/Library/Application Support/Claude/claude_desktop_config.json配置内容大概是这样的{ mcpServers: { your-mcp-server: { command: npx, args: [-y, your-mcp-server-package], env: { YOUR_API_KEY: your_key_here } } } }这里要注意几点command 是你启动 Server 用的命令常见的有 node、npx、python、uvx。args 是启动参数具体取决于 MCP Server 的 README。env 是可选的如果 Server 要访问外部 API需要在这里配置密钥。不是所有 MCP Server 都用 npx。有的 Python 项目用uvx有的要走python 某个文件.py有的需要本地先构建。以项目 README 为准。6.2 远程 HTTP SSE 模式配置如果 MCP Server 运行在远程服务器上并且支持 HTTP SSE 或 Streamable HTTP 传输客户端配置会简单一些{ mcpServers: { remote-tool: { url: http://127.0.0.1:8090/mcp, headers: { Authorization: Bearer your_token } } } }远程模式需要确认服务端是否暴露到公网。不建议把没有鉴权的 MCP Server 直接暴露到公网至少要有 Token 或者放到内网访问。6.3 接入后验证配置完成后重启客户端。在对话界面里给一个和该 Server 能力相关的指令比如数据库 Server 就让它查询一张表文件 Server 就让它读取一个文件。判断是否成功的标准客户端能正确识别工具调用。Server 返回预期结果。对话中能看到工具执行过程。失败时需要看客户端日志。Claude Desktop 的日志文件一般会输出 MCP Server 的启动报错信息这是排查的第一步。7. 从目录到工作流MCP 的批量接入思路AllMCPs 这类目录站真正的价值不只是“找一个 Server”而是帮你批量梳理一个 Agent 工作流里需要用到的所有外部能力。7.1 按场景批量收集做一个自动化的项目通常需要多个 MCP Server 协同。举个通用场景读文件本地文件系统 MCP Server。看网页Playwright MCP Server。查数据数据库 MCP Server。查设计稿Figma MCP 或蓝湖 MCP。图片识别OCR 类 MCP Server。在 AllMCPs 里可以按这些功能依次收集候选统一整理成一个清单。清单的结构可以是| 能力 | Server 名称 | 维护状态 | 配置方式 | 备注 | | --- | --- | --- | --- | --- | | 文件读取 | ... | 活跃 | stdio | 本地 | | 浏览器操作 | ... | 活跃 | 远程 | 需 Token | | 数据库查询 | ... | 可使用 | stdio | 只读模式 |这个清单本身就是工作流设计的基础。后续接入时不用再到处找。7.2 接入 Dify、Codex 等工具时的通用思路很多人的需求是在 Dify 里添加本地 MCP 服务或者给 Codex 配置 MCP。这些工具的配置入口不同但原理一致要么填一个 MCP Server 的命令行启动参数要么填一个远程服务地址。在 Dify 这类平台里通常填的是服务地址或命令参数。在 Codex 这类开发者工具里通常走配置文件。无论哪个平台都遵循“先本地验证 Server 能启动再接到客户端”的流程。直接在客户端里调试不熟的工具容易把“Server 配置错误”和“客户端配置格式错误”混在一起排查成本会高很多。7.3 批量任务与调用频率控制如果 MCP Server 即将接入批量任务要注意调用频率和限流问题。比如批量读取网页、批量调用数据库查询、批量处理图片很容易把目标服务打满。建议在应用层加一层控制每次任务间加延迟。失败自动重试最多 2 到 3 次。记录每次调用的输入输出到日志。先跑 10 条数据验证再全量跑。这些控制逻辑并不需要在 MCP Server 里实现在调用方做即可。8. 常见问题与排查方法MCP 生态里排错是绕不开的。下面这张表覆盖了从目录检索到接入运行最常见的几类问题。问题现象可能原因排查方式解决方案目录站上的项目链接打不开项目已删除或迁移在 GitHub 搜索项目名寻找新地址或换一个候选项目链接能打开但 README 没安装说明项目不成熟或未完成检查 issues 和 commit换维护更好的项目配置后客户端找不到 MCP Server命令错误或路径错误查看客户端日志手动运行启动命令按 README 修改 command 或 argsnpx 下载失败网络原因或包名错误检查包名是否与 README 一致换镜像源或改用本地构建Python 项目启动失败缺少依赖检查运行环境按 README 先安装依赖MCP Server 启动了但返回不了结果权限不足或 API Key 无效测试 Server 的独立调用检查 env 配置和密钥显存或内存突然升高本地模型或任务过重观察资源占用限制并发和输入长度接口调用失败远程地址不可达或鉴权失败curl 测试远程地址检查网络和 TokenDify / Codex 里配置保存后不生效配置项格式错误对比官方文档字段名调整字段大小写或路径批量任务卡住目标服务限流或线程阻塞查看日志和超时时间加延迟、加重试、加超时如果遇到“启动后页面打不开”或“服务没起来”之类的问题第一步永远是看日志而不是改配置。日志会给出具体的报错行比盲目试配置高效得多。9. 最佳实践与合规提醒9.1 使用 MCP Server 的检查清单先看 README再跑代码。至少要确认安装命令、启动方式、需要哪些环境变量。先小规模测试再上批量任务。第一次只跑一个请求确认输出格式正常。区分只读和写操作。数据库、文件、支付类的 Server 要注意会不会产生写操作。敏感密钥不要写在客户端配置之外的地方比如对话里、日志里。远程 MCP Server 必须加鉴权至少用 Token最好放内网。9.2 数据与服务授权MCP Server 越强权限越大。数据库读取、浏览器操作、支付开通、设计稿读取这些能力都涉及数据安全和服务边界。不要在未经授权的情况下对生产数据库、公司内部文档、他人设计稿执行操作。使用与发布时都要确认授权否则风险会转移到使用者身上。9.3 目录提交的维护建议如果你打算把自己的 MCP Server 提交到 AllMCPs 这类目录站建议把提交视为一次“发布流程”而非“上线步骤”。提交前更新 README明确运行环境、配置方式、输出示例能减少用户问问题的时间。项目稳定后定期回访目录条目确保链接仍然有效。10. 总结与下一步AllMCPs 的价值不在代码量而在它把 MCP Server 的“发现成本”降了下来。对于第一次接触 MCP 的人来说最值得做的事是先打开目录站把你最关心的几个关键词或分类浏览一遍挑 2 到 3 个候选 Server分别看 README、跑一遍官方示例再把最合适的那一个接入 Claude 或 Dify。这一步跑通了你对 MCP 的感知会比看十篇文章都有用。最容易踩的坑是把目录站当成权威评价。目录只负责收录和展示Server 到底能不能在生产环境使用还是要看维护状态、文档质量、权限设计和实际测试结果。后续可以继续扩展的方向包括维护一份自己的 MCP Server 清单、把最常用的几个 Server 写成一键配置脚本、给团队内部沉淀一份“哪些 Server 推荐使用、哪些只有测试价值”的选型表。MCP 生态还在快速变化真正适合你的方案往往不是 star 最多的那个而是你能跑通、权限清晰、维护跟得上的那一个。如果你正在做 Agent 工作流建议把这篇收藏备用从目录检索到配置验证的路径其实是一致的。找到合适的 Server 之后动手试一次比停留在“看介绍”阶段有用得多。