搞 AI 应用开发的人最近应该都被“MCP”这个词刷屏了。社区里到处都在聊 MCP ServerIDE 接 MCP数据库接 MCP连设计工具、支付平台都开始把自己的能力封装成 MCP 服务。但你有没有想过一个问题当你想真正接入一个 MCP Server 的时候第一个麻烦往往不是不会配置而是不知道去哪找、怎么选、哪个才是靠谱的。Github 上搜出来的结果又多又杂官方文档推荐的列表又不够全Reddit 和 Hacker News 上的讨论倒是信息量大可要把散落的链接梳理成可以直接用的配置文件仍然要花上不少时间。最近 Hacker News 上出现了一个叫 AllMCPs 的项目标题很直接——Directory of MCP Servers。从名字就能看出来它想做的是 MCP 生态的“黄页”或“大全”。这类目录项目为什么会在现在集中出现它到底解决了什么问题又该怎么把它用好这篇博客会从 MCP 生态的真实痛点讲起先解释 MCP 协议的核心机制再分析 AllMCPs 这类目录项目的价值边界最后用实际配置示例和排错清单帮你把“找到合适的 MCP Server”这件事真正落地。1. 这篇文章真正要解决的问题MCP 现在的热度很像 Kubernetes 刚兴起时的早期阶段。协议本身是好的生态也在快速膨胀但开发者使用起来的第一道门槛不再是“协议能不能通”而变成了“我能用什么、我用哪个”。这里有一个很反直觉的事实MCP 已经诞生两年多但它的“可发现性”仍然处于非常原始的状态。你可以在 Github 上用mcp server这个词搜出成千上万个仓库也可以翻遍各大官方文档找到十几条经过审核的服务器列表但当你面对的实际问题是“我想让 Agent 直接查 PostgreSQL还想让它能调用 Figma 的设计稿信息”你需要的不只是搜索结果而是一个分类清晰、信息完整、能直接让我判断“这个能不能用、怎么装”的索引。AllMCPs 正是在这个节点出现的。它的定位很简单收集、分类并展示 MCP Server 的信息让开发者从“大海捞针”变成“按图索骥”。但这类目录项目也有几个必须回答的问题收录标准是什么是自动抓取还是人工审核分类维度怎么做按领域、按客户端还是按协议传输方式会不会收录大量低质量、过期甚至不再维护的仓库是否给出实用的配置示例和版本兼容信息所以这篇文章不仅是介绍 AllMCPs 这个项目本身更是要讲清楚 MCP Server 目录这个品类以及作为开发者你该如何利用目录去提高自己的选型效率。1.1 最应该读这篇文章的人如果你属于以下三种情况这篇文章很适合你刚开始接触 MCP想知道 MCP Server 到底有哪些类型从哪里获取已经在用 Claude、Dify、Codex 等工具想接入更多第三方能力但不知道如何高效检索和判断准备自己开发 MCP Server想了解当前生态里哪些赛道已经拥挤、哪些方向还有空间。2. MCP 协议的核心概念与原理在讲目录项目之前先把 MCP 的最基本概念捋清楚。因为如果你不了解 MCP 的工作原理面对再好的目录也无从下手。2.1 MCP 是什么MCPModel Context Protocol模型上下文协议是一个开放协议用于标准化 AI 应用与外部数据源、工具之间的交互方式。它最早由 Anthropic 提出后来逐渐被 OpenAI、Google、Microsoft 等生态接纳形成了行业内比较少见的“跨厂商共识”。通俗理解MCP 之于 AI Agent就像 HTTP 之于 Web 应用。在 HTTP 出现之前每个客户端要连接每个服务器都需要一套自己的协议HTTP 出现之后浏览器和服务器只需要遵守同一种语言就能通信。MCP 想做的是同一件事让 AI 应用和外部工具用同一种标准化的语言交换信息和命令。2.2 MCP 的组成角色一个完整的 MCP 架构包含四个角色角色说明典型例子Host用户交互的应用程序负责管理多个客户端连接Claude Desktop、Dify、Cursor 等Client与 MCP Server 建立一对一连接的组件负责协议通信集成在 Host 内部Server暴露特定能力的中介通过标准协议向外提供工具、资源和提示PostgreSQL MCP ServerTransport底层通信机制常见的有 stdio 和 HTTPSSE本地命令行、远程服务这四个角色的关系可以类比成Host 是你的电脑Client 是浏览器Server 是网站服务器Transport 是网络协议。用户通过 Host 发起请求Client 把请求翻译成 MCP 协议规定的格式通过 Transport 传给 ServerServer 执行实际逻辑后返回结果。2.3 三个核心抽象Tool、Resource、PromptMCP 定义了三个基础原语几乎所有 MCP Server 都在围绕它们做文章Tool工具可被模型调用并执行操作的函数。比如query_sales_data、create_jira_ticket。Tools 是 MCP 里最常用的能力相当于给了 AI 一双可以操作真实系统的“手”。Resource资源可供模型读取的结构化数据。比如数据库 schema、配置文件内容、日志文件。Resource 解决的是“模型如何获得上下文”的问题。Prompt提示词模板可复用的提示词模板让用户通过一个简短命令就能触发复杂的工作流。从目录的角度看一个 MCP Server 背后往往兼有多种能力。比如一个数据库 MCP Server它既可以提供 SQL 执行 Tool也可以把表结构暴露为 Resource还可以预置几个分析数据的 Prompt 模板。因此目录的分类不应该是“一个服务器只有一个标签”而应该是一个服务器对应多个能力维度。2.4 容易混淆的概念MCP 与 Agent Skill最近还有一个概念经常被放在一起比较Agent Skill智能体技能。有些读者会遇到“agent skill 和 mcp 有什么区别”这样的搜索问题。从设计目标上看MCP 强调的是“能力接入”。它解决的是 Agent 怎么调用外部系统、怎么获取外部数据是一种标准化的集成方式。Agent Skill 强调的是“任务封装”。它更偏向于把一个完整的任务流程、提示词、工具调用链封装成一个可复用的“技能包”。你可以这样理解MCP 是接口标准Skill 是组织方式。实际项目中两者经常搭配使用一套 MCP Server 提供了基础能力Agent Skill 再在其上编排业务逻辑。3. AllMCPs 的定位与目录项目的价值接下来的问题很自然既然 MCP 协议本身很清晰为什么还需要一个目录项目3.1 没有目录时开发者都经历过什么在没有 AllMCPs 这样的索引之前一个普通开发者想给自己的 Claude Desktop 加一个“能读取本地文件”的能力标准流程是这样的打开搜索引擎输入“MCP server file system”在搜索结果里翻到 Github 仓库查看 star 数量、最近更新时间、README 质量确认这个仓库还活着看它是使用 TypeScript SDK 还是 Python SDK阅读安装说明确认运行方式是npx、uvx还是 Docker打开 Claude 配置文件手工填写command、args、env重启客户端测试是否生效。每一步都不难但每一步都有信息损耗。特别是当你要接入五六个 MCP Server 时光是搜集和比对信息就能消耗一个下午。目录项目正是来压缩这段耗时的。3.2 AllMCPs 这类目录应该提供什么从社区需求来看一个合格的 MCP Server 目录至少应该提供这些维度信息维度为什么重要名称和维护状态避免选中已经几个月没人维护的仓库功能标签知道它是干数据库、浏览器还是消息推送的安装方式是npx、uvx、Docker 还是二进制文件配置示例可直接复制到客户端配置文件中使用客户端兼容性是否支持 Claude Desktop、Dify、Cursor、Codex 等传输方式本地 stdio 还是远程 HTTP/SSE安全等级是否允许执行任意命令是否连接外部 APIAllMCPs 从这个角度切入本质是在做“基础设施之上的基础设施”。它不是 MCP 协议本身也不是 MCP Server 的实现而是让整个生态从“能跑”变成“好用”的信息枢纽。3.3 目录项目自身的局限也需要冷静看待。任何目录项目都会面临三类问题AllMCPs 也无法绕开时效性MCP 生态更新太快一个 Server 可能这周很火下周就被更好的替代。目录要跟上节奏需要投入持续的人力或爬虫工程。质量审核自动收录会混入大量实验性项目人工审核又很难覆盖全量。目录的价值取决于它的筛选标准而不是收录数量。商业化压力目录项目做到后期很可能走上推荐排序的商业模式。届时如何保证排序公正会是一个考验。因此目录只能作为你选型的第一站。真正装到本地之前你还是要自己看一眼源码、跑一次测试。4. MCP Server 生态的常见分类为了让目录检索更高效也为了帮助读者建立全局观这里梳理一下 MCP Server 生态的主要赛道。你在 AllMCPs 这类目录里看到的大部分服务器基本都能归入下面几类。4.1 数据库与数据管道类MCP Server 最成熟、应用最广的领域。典型能力包括连接 PostgreSQL、MySQL、SQLite执行 SQL 查询获取数据库健康指标、分析慢查询读取数据仓库表结构生成数据字典。在dify mcp 怎么使用、workbuddy 通过 mcp 直接访问数据库这些搜索词背后用户真正需要的就是让 Agent 能安全地查询和解析数据库内容。4.2 浏览器自动化与网页抓取类Playwright MCP Server 是这个赛道里的明星项目。它让 LLM 能自动操作真实浏览器完成网页导航、表单填写、数据提取、页面截图等任务。对测试工程师和需要做网页数据采集的开发者来说这类 MCP Server 直接改变了原来的自动化脚本编写方式。这类 MCP 的坑在于它不是纯读操作而是会真实打开浏览器并操作系统资源因此沙箱和权限设计非常关键。4.3 设计工具与内容生成类Figma MCP Server 是另一个高频词。它的价值在于设计师在 Figma 里完成设计稿后开发者可以直接让 Agent 读取设计稿的结构、颜色、组件信息生成对应的前端代码或样式文件。这打通了设计到开发的最后一公里。同样类型的还包括各类文档、知识库同步工具。它们解决的核心问题是把 AI 无法感知的二进制或富文本内容转换成模型可以理解的文本上下文。4.4 开发工具链与 IDE 集成类这个类别覆盖 Java、C#、MATLAB、IDAPython 等专业工具链。比如java mcp server 搭建、c# mcp这类搜索词说明很多后端开发者已经在尝试把自己的业务服务包装成 MCP 格式。这类 MCP Server 往往不只是“给 AI 用”也是在建立一套新的服务集成方式。开发者通过标准协议暴露出内部 API让多个 AI 客户端都能调用。4.5 支付、搜索与第三方服务类支付平台如支付宝提供服务端 MCP搜索厂商提供搜索 MCP云厂商提供资源管理 MCP。这些大型平台开始以 MCP 作为面向 AI 应用的开放接口意味着 MCP 生态正从开发者社区自发生长走向商业平台主动适配的阶段。对个人开发者来说这类服务器通常文档更齐全、安全边界更清晰反而值得优先尝试。5. 环境准备与前置条件无论你是从 AllMCPs 目录里找到一个 MCP Server还是准备自己开发一个都需要先确认本地环境满足基本要求。5.1 运行环境MCP 是传输层与语言无关的协议因此理论上任何语言都能实现 MCP Server。但当前生态里最主流的 SDK 是 TypeScriptmodelcontextprotocol/sdk和 Pythonmcp库其他语言 SDK 也在快速成熟。如果你是普通使用者只需要满足目标客户端能正常使用Claude Desktop、Dify、Cursor、Codex 等本地装有对应的运行时Node.js 或 Python 环境没有本地环境的优先选择 Docker 方式的 MCP Server。5.2 版本问题MCP 协议仍在快速演进。从早期版本到现在的稳定版本传输方式从 stdio 扩展到了 HTTP SSE最新的 Streamable HTTP 也让远程 MCP 变得更容易配置。这里要特别提醒在复制目录或仓库中的配置命令时先确认协议和 SDK 版本是否与你使用的客户端版本匹配。不同版本的配置语法差异很容易导致“配置看起来没问题但连接一直失败”。5.3 依赖管理方式大多数 MCP Server 的安装方式属于这两类npxNode 生态包管理工具适合 TypeScript 编写的 MCP ServeruvxPython 生态的快速运行工具适合 Python 编写的 MCP ServerDocker适合需要隔离环境、有系统依赖的 MCP Server。用npx的好处是无需手动管理目录坏处是首次启动会让模型自动下载依赖需要网络可达用 Docker 的好处是环境干净坏处是每增加一个 MCP Server都会额外占用一个容器的资源。6. 从目录到运行完整配置示例这一节进入实操。我们以 AllMCPs 目录中常见的“文件系统 MCP Server”和“数据库 MCP Server”为例演示从目录检索到本地配置的完整流程。6.1 步骤一从目录里找到目标 Server假设你在 AllMCPs 官网搜索框输入postgresql结果列表会显示若干个候选项目。选型的快速判断标准有四点最近更新时间是否在 3 个月以内是否有明确的功能描述和配置文档star 数量虽然是参考但几百个 star 的项目并不一定比几十个的更靠谱是否给出已知问题或限制说明。6.2 步骤二在 Claude Desktop 中配置 MCP ServerClaude Desktop 是目前配置 MCP 最直接的客户端之一。它的配置文件位于Windows%APPDATA%\Claude\claude_desktop_config.jsonmacOS~/Library/Application Support/Claude/claude_desktop_config.json如果配置文件中还没有 mcpServers 字段可以手动创建。以下是一个典型的文件系统 MCP 配置{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/yourname/Documents ] } } }关键参数说明mcpServers固定字段表示这是一组 MCP Server 配置filesystem自定义名称在客户端界面里会显示为可用工具的前缀command启动命令可以是npx、uvx或本地二进制路径args命令参数第一个参数通常是要安装运行的包名后面的参数是传给该 Server 的配置。保存后重启 Claude Desktop。如果配置正确你会在聊天界面看到新增的工具图标并能在对话中让它读取指定目录下的文件。6.3 步骤三在 Dify 中配置本地 MCP 服务Dify 是目前很多团队在使用的 LLM 应用开发平台。它支持在 Agent 应用里添加 MCP 工具。进入 Dify 的工作流或 Agent 编辑页面在“工具”区域选择“自定义”或“通过 MCP 添加工具”。Dify 支持两种连接方式stdio通过命令行启动本地 MCP ServerstreamableHttp/sse连接已经部署好的远程 MCP Server。以本地 Python 编写的 MCP Server 为例假设你的入口文件是server.pyuvx --from mcp server.py在 Dify 中填写命令时通常需要写uvx --from mcp server.py如果 Dify 的 MCP 表单要求分开填写命令和参数则命令为uvx参数为--from mcp server.py。这里常见的问题是Dify 容器环境和本机环境隔离导致本机能跑的命令在 Dify 中找不到。解决方法是设置好环境变量或直接用远程 HTTP 方式接入一个已经部署好的 MCP Server。6.4 步骤四配置远程 MCP Server远程 MCP Server 是另一个高频场景。很多团队会把 MCP Server 部署到服务器上然后让多个客户端共享。配置方式不再需要command和args而改成 URL 方式{ mcpServers: { remote-db: { url: https://your-server.example.com/mcp, headers: { Authorization: Bearer your-token } } } }这种方式的优势是客户端可以很轻量不需要安装 Node.js 或 Python 环境。需要注意的安全问题是远程 MCP 暴露了 API 能力必须使用 HTTPS 和 token 鉴权不能裸奔在公网上。6.5 步骤五验证配置是否成功配置完成后建议按这个顺序验证在客户端里重启应用并打开 MCP 工具列表确认看到新增 Server 名称用一个最简单的提示词测试比如“列出当前连接的文件系统中项目文件夹有哪些文件”如果测试失败查看客户端的运行日志确认 Server 是否成功启动如果是远程 MCP用curl直接请求对应 URL先排除网络和鉴权问题。7. 运行结果与效果验证为了让“配置成功”不再停留在口头判断这里展示一个可复现的验证流程。7.1 用命令行直接验证 MCP Server无论客户端界面如何封装MCP Server 本身的启动过程都会在命令行中留下痕迹。假设你使用的是modelcontextprotocol/server-filesystem首次启动时终端会输出类似这样的日志Starting MCP server... Server initialized with root directory: /Users/yourname/Documents MCP server listening on stdio这表示 Server 已经通过 stdio 正常监听。如果在这一步就报错大概率是 Node 版本不足、包名写错或目录权限不足。在 Claude Desktop 的日志文件里你通常能看到更明确的错误Failed to connect to MCP server filesystem Error: ENOENT: no such file or directory如果看到ENOENT优先检查args里的路径是否存在。如果看到Command failed: npx: not found则说明客户端的PATH环境变量里没有 Node.js。7.2 判断是否成功以实际问答为准配置完成后的最终判断标准不是“能看到 MCP 图标”而是“Agent 真的能调用工具完成一次操作”。以文件系统 MCP 为例你在对话里输入请查看 /Users/yourname/Documents 目录下有哪些文件并按名称排序。一个正常的响应应该包含文件列表和排序后的结果。如果 Agent 回答“我无法访问文件系统”或“当前没有可用工具”说明 MCP 连接并没有真正生效。7.3 失败后的诊断路径按下面顺序排查可以覆盖绝大多数问题检查客户端日志看 MCP 连接是否报错在终端手动执行配置里的command args看能否正常启动确认运行时环境npx/uvx是否在全局 PATH 中确认网络使用npx时是否需要代理才能下载包确认权限本地目录是否允许读写确认协议版本远程 MCP 使用 HTTP 还是 SSE客户端是否支持。8. 常见问题与排查思路这里整理了一张高频问题表供实际开发时快速对照。问题现象可能原因排查方式解决方案点击工具没反应MCP Server 启动失败查看客户端日志手动在终端执行配置命令验证提示 npx 命令不存在Node.js 未安装或不在 PATH终端执行npx --version安装 Node.js 并配置 PATH提示 uvx 命令不存在Python 环境未配置终端执行uvx --version安装uv工具链本地路径访问失败路径不存在或权限不足检查目录是否存在修改 args 中的路径并赋予读权限远程 MCP 连接超时网络不通、URL 错误或未使用 HTTPS用 curl 直接访问 MCP URL检查网络和证书配置工具列表不显示新增 Server客户端缓存未刷新完全退出客户端后重启重启后重新检查工具列表模型不主动使用工具提示词约束了工具调用检查系统提示词是否禁止外部工具调整提示词并明确告知可用的 MCP 工具Server 能启动但数据返回空查询逻辑或权限配置不正确在终端直接调用对应函数单独调试 MCP Server 内部逻辑8.1 一个容易混淆的场景上下文过大在 MCP 使用过程中“上下文过大”是高频报错尤其当 Agent 同时连接多个 MCP Server、且每个工具都返回大量数据时。很多人会误以为是 MCP Server 坏了其实这是因为把过多内容灌进了模型上下文窗口。排查方向是确认每个 MCP 工具返回的数据量是否过大是否应该在客户端侧做截断或分页处理。这不是协议的 bug而是使用姿势的问题。8.2 注意“看起来正常但实际没生效”的情况还有一种隐蔽的问题MCP Server 配置正确、客户端日志无报错、工具列表也显示了但模型就是不调用。这时候要检查两件事是不是当前对话模型本身不具备工具调用能力是不是提示词里把工具“禁言”了。某些模型在长对话中会逐渐遗忘工具信息这时可以通过显式提醒让模型重新调用。9. 最佳实践与工程建议9.1 选型时的“最小权限”原则在目录里选 MCP Server 时要遵循最小权限原则只给 Agent 它必需的能力不要为了“看起来更强”而一次性接入大量工具。一个常见的反面案例是给一个只需要查询数据库的 Agent 同时接入了文件系统、浏览器、支付等 MCP Server。这样做不仅增加了模型出错、调用错误工具的概率也扩大了安全暴露面。如果你的 Agent 只需要读数据库那就只配置数据库 MCP。9.2 本地使用时的环境隔离在本地使用 MCP 时建议通过 Docker 或虚拟环境隔离依赖。尤其是那些由社区贡献、star 数量有限的项目在跑起来之前最好先读一遍源码或至少观察它的安装脚本。用npx -y拉取的包本质上都会在本地执行代码这一点和npm install的安全风险没有本质区别。如果公司对代码安全有严格要求更稳妥的做法是把 MCP Server 放到独立的容器或沙箱里运行只暴露必要的端口而不是直接以本机权限执行。9.3 远程 MCP 的认证与审计远程 MCP 是团队协作场景下的趋势。生产环境使用远程 MCP 时必须做到使用 HTTPS不暴露明文 HTTP使用 Token 或 OAuth 鉴权不为方便而跳过认证为每个调用方分配独立 Token便于操作审计在网关层记录调用日志至少包含调用方、调用时间、工具名称和入参摘要。9.4 监测与更新MCP 生态更新速度极快别把一个 MCP Server 当作永久不变的组件。为长期使用的 Server 建立版本维护机制比如使用固定版本号而不是latest定期查看维护者的 release 说明和 issue 列表。在目录类项目中筛选时同样要看更新时间。如果一个 Server 已经半年没有提交它给出的配置示例很可能不再适用于新版 MCP 协议。9.5 配置的统一管理当团队里多个人都在使用 MCP 时建议把配置文件纳入版本管理。可以单独建立一个小仓库保存各客户端的claude_desktop_config.json、Dify 工具配置等通过 CI 或脚本统一分发。这样做的好处是配置变更可追踪新员工入职时直接 clone 即可获得一致的开发环境。也可以使用环境变量区分不同环境的差异避免把本机路径泄露到仓库中。10. 总结与后续学习方向从 MCP 协议的爆发到 AllMCPs 这类目录项目的出现能清晰地看到一个技术生态走向成熟的轨迹先是协议标准的确立再是核心工具的涌现然后是信息组织和筛选机制的出现。目录的价值不在于它显示了成千上万个一行链接而在于它把开发者的“搜索成本”压缩成了“选择成本”。回到实践层面读完这篇文章你可以做到三件事理解 MCP 协议的基本角色和原语知道如何通过 AllMCPs 这类目录去检索和筛选 MCP Server并且能够在 Claude Desktop、Dify 等客户端里完成本地或远程 MCP Server 的配置和排错。下一步值得深入的方向有三个一是把 MCP Server 的选型标准沉淀成团队规范避免每个成员各自摸索二是研究 MCP 服务端的鉴权与审计尤其是远程部署时如何设计安全边界三是结合 Agent Skill把多个 MCP 工具编排成完整的业务能力而不仅仅是“能调用单个工具”。技术生态的演进从来不是单点突破而是协议、工具、目录、治理共同成熟的过程。MCP 现在还处在“能用”到“好用”的过渡期AllMCPs 这类目录的价值会随着生态膨胀而不断放大。建议你先从自己最常用的客户端入手选一个数据库类或文件系统类的 MCP Server把这个最小链路跑通。跑通之后再慢慢扩展其他能力。 
长河君 · 2026/8/27 1:20:40 · 阅读 1.2k AllMCPs：MCP Server 目录项目如何帮你高效选型与配置
搞 AI 应用开发的人最近应该都被“MCP”这个词刷屏了。社区里到处都在聊 MCP ServerIDE 接 MCP数据库接 MCP连设计工具、支付平台都开始把自己的能力封装成 MCP 服务。但你有没有想过一个问题当你想真正接入一个 MCP Server 的时候第一个麻烦往往不是不会配置而是不知道去哪找、怎么选、哪个才是靠谱的。Github 上搜出来的结果又多又杂官方文档推荐的列表又不够全Reddit 和 Hacker News 上的讨论倒是信息量大可要把散落的链接梳理成可以直接用的配置文件仍然要花上不少时间。最近 Hacker News 上出现了一个叫 AllMCPs 的项目标题很直接——Directory of MCP Servers。从名字就能看出来它想做的是 MCP 生态的“黄页”或“大全”。这类目录项目为什么会在现在集中出现它到底解决了什么问题又该怎么把它用好这篇博客会从 MCP 生态的真实痛点讲起先解释 MCP 协议的核心机制再分析 AllMCPs 这类目录项目的价值边界最后用实际配置示例和排错清单帮你把“找到合适的 MCP Server”这件事真正落地。1. 这篇文章真正要解决的问题MCP 现在的热度很像 Kubernetes 刚兴起时的早期阶段。协议本身是好的生态也在快速膨胀但开发者使用起来的第一道门槛不再是“协议能不能通”而变成了“我能用什么、我用哪个”。这里有一个很反直觉的事实MCP 已经诞生两年多但它的“可发现性”仍然处于非常原始的状态。你可以在 Github 上用mcp server这个词搜出成千上万个仓库也可以翻遍各大官方文档找到十几条经过审核的服务器列表但当你面对的实际问题是“我想让 Agent 直接查 PostgreSQL还想让它能调用 Figma 的设计稿信息”你需要的不只是搜索结果而是一个分类清晰、信息完整、能直接让我判断“这个能不能用、怎么装”的索引。AllMCPs 正是在这个节点出现的。它的定位很简单收集、分类并展示 MCP Server 的信息让开发者从“大海捞针”变成“按图索骥”。但这类目录项目也有几个必须回答的问题收录标准是什么是自动抓取还是人工审核分类维度怎么做按领域、按客户端还是按协议传输方式会不会收录大量低质量、过期甚至不再维护的仓库是否给出实用的配置示例和版本兼容信息所以这篇文章不仅是介绍 AllMCPs 这个项目本身更是要讲清楚 MCP Server 目录这个品类以及作为开发者你该如何利用目录去提高自己的选型效率。1.1 最应该读这篇文章的人如果你属于以下三种情况这篇文章很适合你刚开始接触 MCP想知道 MCP Server 到底有哪些类型从哪里获取已经在用 Claude、Dify、Codex 等工具想接入更多第三方能力但不知道如何高效检索和判断准备自己开发 MCP Server想了解当前生态里哪些赛道已经拥挤、哪些方向还有空间。2. MCP 协议的核心概念与原理在讲目录项目之前先把 MCP 的最基本概念捋清楚。因为如果你不了解 MCP 的工作原理面对再好的目录也无从下手。2.1 MCP 是什么MCPModel Context Protocol模型上下文协议是一个开放协议用于标准化 AI 应用与外部数据源、工具之间的交互方式。它最早由 Anthropic 提出后来逐渐被 OpenAI、Google、Microsoft 等生态接纳形成了行业内比较少见的“跨厂商共识”。通俗理解MCP 之于 AI Agent就像 HTTP 之于 Web 应用。在 HTTP 出现之前每个客户端要连接每个服务器都需要一套自己的协议HTTP 出现之后浏览器和服务器只需要遵守同一种语言就能通信。MCP 想做的是同一件事让 AI 应用和外部工具用同一种标准化的语言交换信息和命令。2.2 MCP 的组成角色一个完整的 MCP 架构包含四个角色角色说明典型例子Host用户交互的应用程序负责管理多个客户端连接Claude Desktop、Dify、Cursor 等Client与 MCP Server 建立一对一连接的组件负责协议通信集成在 Host 内部Server暴露特定能力的中介通过标准协议向外提供工具、资源和提示PostgreSQL MCP ServerTransport底层通信机制常见的有 stdio 和 HTTPSSE本地命令行、远程服务这四个角色的关系可以类比成Host 是你的电脑Client 是浏览器Server 是网站服务器Transport 是网络协议。用户通过 Host 发起请求Client 把请求翻译成 MCP 协议规定的格式通过 Transport 传给 ServerServer 执行实际逻辑后返回结果。2.3 三个核心抽象Tool、Resource、PromptMCP 定义了三个基础原语几乎所有 MCP Server 都在围绕它们做文章Tool工具可被模型调用并执行操作的函数。比如query_sales_data、create_jira_ticket。Tools 是 MCP 里最常用的能力相当于给了 AI 一双可以操作真实系统的“手”。Resource资源可供模型读取的结构化数据。比如数据库 schema、配置文件内容、日志文件。Resource 解决的是“模型如何获得上下文”的问题。Prompt提示词模板可复用的提示词模板让用户通过一个简短命令就能触发复杂的工作流。从目录的角度看一个 MCP Server 背后往往兼有多种能力。比如一个数据库 MCP Server它既可以提供 SQL 执行 Tool也可以把表结构暴露为 Resource还可以预置几个分析数据的 Prompt 模板。因此目录的分类不应该是“一个服务器只有一个标签”而应该是一个服务器对应多个能力维度。2.4 容易混淆的概念MCP 与 Agent Skill最近还有一个概念经常被放在一起比较Agent Skill智能体技能。有些读者会遇到“agent skill 和 mcp 有什么区别”这样的搜索问题。从设计目标上看MCP 强调的是“能力接入”。它解决的是 Agent 怎么调用外部系统、怎么获取外部数据是一种标准化的集成方式。Agent Skill 强调的是“任务封装”。它更偏向于把一个完整的任务流程、提示词、工具调用链封装成一个可复用的“技能包”。你可以这样理解MCP 是接口标准Skill 是组织方式。实际项目中两者经常搭配使用一套 MCP Server 提供了基础能力Agent Skill 再在其上编排业务逻辑。3. AllMCPs 的定位与目录项目的价值接下来的问题很自然既然 MCP 协议本身很清晰为什么还需要一个目录项目3.1 没有目录时开发者都经历过什么在没有 AllMCPs 这样的索引之前一个普通开发者想给自己的 Claude Desktop 加一个“能读取本地文件”的能力标准流程是这样的打开搜索引擎输入“MCP server file system”在搜索结果里翻到 Github 仓库查看 star 数量、最近更新时间、README 质量确认这个仓库还活着看它是使用 TypeScript SDK 还是 Python SDK阅读安装说明确认运行方式是npx、uvx还是 Docker打开 Claude 配置文件手工填写command、args、env重启客户端测试是否生效。每一步都不难但每一步都有信息损耗。特别是当你要接入五六个 MCP Server 时光是搜集和比对信息就能消耗一个下午。目录项目正是来压缩这段耗时的。3.2 AllMCPs 这类目录应该提供什么从社区需求来看一个合格的 MCP Server 目录至少应该提供这些维度信息维度为什么重要名称和维护状态避免选中已经几个月没人维护的仓库功能标签知道它是干数据库、浏览器还是消息推送的安装方式是npx、uvx、Docker 还是二进制文件配置示例可直接复制到客户端配置文件中使用客户端兼容性是否支持 Claude Desktop、Dify、Cursor、Codex 等传输方式本地 stdio 还是远程 HTTP/SSE安全等级是否允许执行任意命令是否连接外部 APIAllMCPs 从这个角度切入本质是在做“基础设施之上的基础设施”。它不是 MCP 协议本身也不是 MCP Server 的实现而是让整个生态从“能跑”变成“好用”的信息枢纽。3.3 目录项目自身的局限也需要冷静看待。任何目录项目都会面临三类问题AllMCPs 也无法绕开时效性MCP 生态更新太快一个 Server 可能这周很火下周就被更好的替代。目录要跟上节奏需要投入持续的人力或爬虫工程。质量审核自动收录会混入大量实验性项目人工审核又很难覆盖全量。目录的价值取决于它的筛选标准而不是收录数量。商业化压力目录项目做到后期很可能走上推荐排序的商业模式。届时如何保证排序公正会是一个考验。因此目录只能作为你选型的第一站。真正装到本地之前你还是要自己看一眼源码、跑一次测试。4. MCP Server 生态的常见分类为了让目录检索更高效也为了帮助读者建立全局观这里梳理一下 MCP Server 生态的主要赛道。你在 AllMCPs 这类目录里看到的大部分服务器基本都能归入下面几类。4.1 数据库与数据管道类MCP Server 最成熟、应用最广的领域。典型能力包括连接 PostgreSQL、MySQL、SQLite执行 SQL 查询获取数据库健康指标、分析慢查询读取数据仓库表结构生成数据字典。在dify mcp 怎么使用、workbuddy 通过 mcp 直接访问数据库这些搜索词背后用户真正需要的就是让 Agent 能安全地查询和解析数据库内容。4.2 浏览器自动化与网页抓取类Playwright MCP Server 是这个赛道里的明星项目。它让 LLM 能自动操作真实浏览器完成网页导航、表单填写、数据提取、页面截图等任务。对测试工程师和需要做网页数据采集的开发者来说这类 MCP Server 直接改变了原来的自动化脚本编写方式。这类 MCP 的坑在于它不是纯读操作而是会真实打开浏览器并操作系统资源因此沙箱和权限设计非常关键。4.3 设计工具与内容生成类Figma MCP Server 是另一个高频词。它的价值在于设计师在 Figma 里完成设计稿后开发者可以直接让 Agent 读取设计稿的结构、颜色、组件信息生成对应的前端代码或样式文件。这打通了设计到开发的最后一公里。同样类型的还包括各类文档、知识库同步工具。它们解决的核心问题是把 AI 无法感知的二进制或富文本内容转换成模型可以理解的文本上下文。4.4 开发工具链与 IDE 集成类这个类别覆盖 Java、C#、MATLAB、IDAPython 等专业工具链。比如java mcp server 搭建、c# mcp这类搜索词说明很多后端开发者已经在尝试把自己的业务服务包装成 MCP 格式。这类 MCP Server 往往不只是“给 AI 用”也是在建立一套新的服务集成方式。开发者通过标准协议暴露出内部 API让多个 AI 客户端都能调用。4.5 支付、搜索与第三方服务类支付平台如支付宝提供服务端 MCP搜索厂商提供搜索 MCP云厂商提供资源管理 MCP。这些大型平台开始以 MCP 作为面向 AI 应用的开放接口意味着 MCP 生态正从开发者社区自发生长走向商业平台主动适配的阶段。对个人开发者来说这类服务器通常文档更齐全、安全边界更清晰反而值得优先尝试。5. 环境准备与前置条件无论你是从 AllMCPs 目录里找到一个 MCP Server还是准备自己开发一个都需要先确认本地环境满足基本要求。5.1 运行环境MCP 是传输层与语言无关的协议因此理论上任何语言都能实现 MCP Server。但当前生态里最主流的 SDK 是 TypeScriptmodelcontextprotocol/sdk和 Pythonmcp库其他语言 SDK 也在快速成熟。如果你是普通使用者只需要满足目标客户端能正常使用Claude Desktop、Dify、Cursor、Codex 等本地装有对应的运行时Node.js 或 Python 环境没有本地环境的优先选择 Docker 方式的 MCP Server。5.2 版本问题MCP 协议仍在快速演进。从早期版本到现在的稳定版本传输方式从 stdio 扩展到了 HTTP SSE最新的 Streamable HTTP 也让远程 MCP 变得更容易配置。这里要特别提醒在复制目录或仓库中的配置命令时先确认协议和 SDK 版本是否与你使用的客户端版本匹配。不同版本的配置语法差异很容易导致“配置看起来没问题但连接一直失败”。5.3 依赖管理方式大多数 MCP Server 的安装方式属于这两类npxNode 生态包管理工具适合 TypeScript 编写的 MCP ServeruvxPython 生态的快速运行工具适合 Python 编写的 MCP ServerDocker适合需要隔离环境、有系统依赖的 MCP Server。用npx的好处是无需手动管理目录坏处是首次启动会让模型自动下载依赖需要网络可达用 Docker 的好处是环境干净坏处是每增加一个 MCP Server都会额外占用一个容器的资源。6. 从目录到运行完整配置示例这一节进入实操。我们以 AllMCPs 目录中常见的“文件系统 MCP Server”和“数据库 MCP Server”为例演示从目录检索到本地配置的完整流程。6.1 步骤一从目录里找到目标 Server假设你在 AllMCPs 官网搜索框输入postgresql结果列表会显示若干个候选项目。选型的快速判断标准有四点最近更新时间是否在 3 个月以内是否有明确的功能描述和配置文档star 数量虽然是参考但几百个 star 的项目并不一定比几十个的更靠谱是否给出已知问题或限制说明。6.2 步骤二在 Claude Desktop 中配置 MCP ServerClaude Desktop 是目前配置 MCP 最直接的客户端之一。它的配置文件位于Windows%APPDATA%\Claude\claude_desktop_config.jsonmacOS~/Library/Application Support/Claude/claude_desktop_config.json如果配置文件中还没有 mcpServers 字段可以手动创建。以下是一个典型的文件系统 MCP 配置{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/yourname/Documents ] } } }关键参数说明mcpServers固定字段表示这是一组 MCP Server 配置filesystem自定义名称在客户端界面里会显示为可用工具的前缀command启动命令可以是npx、uvx或本地二进制路径args命令参数第一个参数通常是要安装运行的包名后面的参数是传给该 Server 的配置。保存后重启 Claude Desktop。如果配置正确你会在聊天界面看到新增的工具图标并能在对话中让它读取指定目录下的文件。6.3 步骤三在 Dify 中配置本地 MCP 服务Dify 是目前很多团队在使用的 LLM 应用开发平台。它支持在 Agent 应用里添加 MCP 工具。进入 Dify 的工作流或 Agent 编辑页面在“工具”区域选择“自定义”或“通过 MCP 添加工具”。Dify 支持两种连接方式stdio通过命令行启动本地 MCP ServerstreamableHttp/sse连接已经部署好的远程 MCP Server。以本地 Python 编写的 MCP Server 为例假设你的入口文件是server.pyuvx --from mcp server.py在 Dify 中填写命令时通常需要写uvx --from mcp server.py如果 Dify 的 MCP 表单要求分开填写命令和参数则命令为uvx参数为--from mcp server.py。这里常见的问题是Dify 容器环境和本机环境隔离导致本机能跑的命令在 Dify 中找不到。解决方法是设置好环境变量或直接用远程 HTTP 方式接入一个已经部署好的 MCP Server。6.4 步骤四配置远程 MCP Server远程 MCP Server 是另一个高频场景。很多团队会把 MCP Server 部署到服务器上然后让多个客户端共享。配置方式不再需要command和args而改成 URL 方式{ mcpServers: { remote-db: { url: https://your-server.example.com/mcp, headers: { Authorization: Bearer your-token } } } }这种方式的优势是客户端可以很轻量不需要安装 Node.js 或 Python 环境。需要注意的安全问题是远程 MCP 暴露了 API 能力必须使用 HTTPS 和 token 鉴权不能裸奔在公网上。6.5 步骤五验证配置是否成功配置完成后建议按这个顺序验证在客户端里重启应用并打开 MCP 工具列表确认看到新增 Server 名称用一个最简单的提示词测试比如“列出当前连接的文件系统中项目文件夹有哪些文件”如果测试失败查看客户端的运行日志确认 Server 是否成功启动如果是远程 MCP用curl直接请求对应 URL先排除网络和鉴权问题。7. 运行结果与效果验证为了让“配置成功”不再停留在口头判断这里展示一个可复现的验证流程。7.1 用命令行直接验证 MCP Server无论客户端界面如何封装MCP Server 本身的启动过程都会在命令行中留下痕迹。假设你使用的是modelcontextprotocol/server-filesystem首次启动时终端会输出类似这样的日志Starting MCP server... Server initialized with root directory: /Users/yourname/Documents MCP server listening on stdio这表示 Server 已经通过 stdio 正常监听。如果在这一步就报错大概率是 Node 版本不足、包名写错或目录权限不足。在 Claude Desktop 的日志文件里你通常能看到更明确的错误Failed to connect to MCP server filesystem Error: ENOENT: no such file or directory如果看到ENOENT优先检查args里的路径是否存在。如果看到Command failed: npx: not found则说明客户端的PATH环境变量里没有 Node.js。7.2 判断是否成功以实际问答为准配置完成后的最终判断标准不是“能看到 MCP 图标”而是“Agent 真的能调用工具完成一次操作”。以文件系统 MCP 为例你在对话里输入请查看 /Users/yourname/Documents 目录下有哪些文件并按名称排序。一个正常的响应应该包含文件列表和排序后的结果。如果 Agent 回答“我无法访问文件系统”或“当前没有可用工具”说明 MCP 连接并没有真正生效。7.3 失败后的诊断路径按下面顺序排查可以覆盖绝大多数问题检查客户端日志看 MCP 连接是否报错在终端手动执行配置里的command args看能否正常启动确认运行时环境npx/uvx是否在全局 PATH 中确认网络使用npx时是否需要代理才能下载包确认权限本地目录是否允许读写确认协议版本远程 MCP 使用 HTTP 还是 SSE客户端是否支持。8. 常见问题与排查思路这里整理了一张高频问题表供实际开发时快速对照。问题现象可能原因排查方式解决方案点击工具没反应MCP Server 启动失败查看客户端日志手动在终端执行配置命令验证提示 npx 命令不存在Node.js 未安装或不在 PATH终端执行npx --version安装 Node.js 并配置 PATH提示 uvx 命令不存在Python 环境未配置终端执行uvx --version安装uv工具链本地路径访问失败路径不存在或权限不足检查目录是否存在修改 args 中的路径并赋予读权限远程 MCP 连接超时网络不通、URL 错误或未使用 HTTPS用 curl 直接访问 MCP URL检查网络和证书配置工具列表不显示新增 Server客户端缓存未刷新完全退出客户端后重启重启后重新检查工具列表模型不主动使用工具提示词约束了工具调用检查系统提示词是否禁止外部工具调整提示词并明确告知可用的 MCP 工具Server 能启动但数据返回空查询逻辑或权限配置不正确在终端直接调用对应函数单独调试 MCP Server 内部逻辑8.1 一个容易混淆的场景上下文过大在 MCP 使用过程中“上下文过大”是高频报错尤其当 Agent 同时连接多个 MCP Server、且每个工具都返回大量数据时。很多人会误以为是 MCP Server 坏了其实这是因为把过多内容灌进了模型上下文窗口。排查方向是确认每个 MCP 工具返回的数据量是否过大是否应该在客户端侧做截断或分页处理。这不是协议的 bug而是使用姿势的问题。8.2 注意“看起来正常但实际没生效”的情况还有一种隐蔽的问题MCP Server 配置正确、客户端日志无报错、工具列表也显示了但模型就是不调用。这时候要检查两件事是不是当前对话模型本身不具备工具调用能力是不是提示词里把工具“禁言”了。某些模型在长对话中会逐渐遗忘工具信息这时可以通过显式提醒让模型重新调用。9. 最佳实践与工程建议9.1 选型时的“最小权限”原则在目录里选 MCP Server 时要遵循最小权限原则只给 Agent 它必需的能力不要为了“看起来更强”而一次性接入大量工具。一个常见的反面案例是给一个只需要查询数据库的 Agent 同时接入了文件系统、浏览器、支付等 MCP Server。这样做不仅增加了模型出错、调用错误工具的概率也扩大了安全暴露面。如果你的 Agent 只需要读数据库那就只配置数据库 MCP。9.2 本地使用时的环境隔离在本地使用 MCP 时建议通过 Docker 或虚拟环境隔离依赖。尤其是那些由社区贡献、star 数量有限的项目在跑起来之前最好先读一遍源码或至少观察它的安装脚本。用npx -y拉取的包本质上都会在本地执行代码这一点和npm install的安全风险没有本质区别。如果公司对代码安全有严格要求更稳妥的做法是把 MCP Server 放到独立的容器或沙箱里运行只暴露必要的端口而不是直接以本机权限执行。9.3 远程 MCP 的认证与审计远程 MCP 是团队协作场景下的趋势。生产环境使用远程 MCP 时必须做到使用 HTTPS不暴露明文 HTTP使用 Token 或 OAuth 鉴权不为方便而跳过认证为每个调用方分配独立 Token便于操作审计在网关层记录调用日志至少包含调用方、调用时间、工具名称和入参摘要。9.4 监测与更新MCP 生态更新速度极快别把一个 MCP Server 当作永久不变的组件。为长期使用的 Server 建立版本维护机制比如使用固定版本号而不是latest定期查看维护者的 release 说明和 issue 列表。在目录类项目中筛选时同样要看更新时间。如果一个 Server 已经半年没有提交它给出的配置示例很可能不再适用于新版 MCP 协议。9.5 配置的统一管理当团队里多个人都在使用 MCP 时建议把配置文件纳入版本管理。可以单独建立一个小仓库保存各客户端的claude_desktop_config.json、Dify 工具配置等通过 CI 或脚本统一分发。这样做的好处是配置变更可追踪新员工入职时直接 clone 即可获得一致的开发环境。也可以使用环境变量区分不同环境的差异避免把本机路径泄露到仓库中。10. 总结与后续学习方向从 MCP 协议的爆发到 AllMCPs 这类目录项目的出现能清晰地看到一个技术生态走向成熟的轨迹先是协议标准的确立再是核心工具的涌现然后是信息组织和筛选机制的出现。目录的价值不在于它显示了成千上万个一行链接而在于它把开发者的“搜索成本”压缩成了“选择成本”。回到实践层面读完这篇文章你可以做到三件事理解 MCP 协议的基本角色和原语知道如何通过 AllMCPs 这类目录去检索和筛选 MCP Server并且能够在 Claude Desktop、Dify 等客户端里完成本地或远程 MCP Server 的配置和排错。下一步值得深入的方向有三个一是把 MCP Server 的选型标准沉淀成团队规范避免每个成员各自摸索二是研究 MCP 服务端的鉴权与审计尤其是远程部署时如何设计安全边界三是结合 Agent Skill把多个 MCP 工具编排成完整的业务能力而不仅仅是“能调用单个工具”。技术生态的演进从来不是单点突破而是协议、工具、目录、治理共同成熟的过程。MCP 现在还处在“能用”到“好用”的过渡期AllMCPs 这类目录的价值会随着生态膨胀而不断放大。建议你先从自己最常用的客户端入手选一个数据库类或文件系统类的 MCP Server把这个最小链路跑通。跑通之后再慢慢扩展其他能力。