MCP 实测：3482 个 Server 中真正值得用的只有这4类

MCP 实测：3482 个 Server 只这 4 类值得用

我花了整整两周时间，把 MCP 生态里能搜到的 3482 个 Server 翻了个底朝天。

起因很简单：团队里已经有人把 MCP（Model Context Protocol）接进了 IDE 和内部工具链，但更多人处于“听说过、不知道怎么用、更不知道选哪个”的状态。而社区里那些“Top 10 MCP Server”榜单，翻来覆去就那十几个，水分大得很。我也见过不少帖子吹某个 Server 多好用，结果自己一接，要么协议实现不完整，要么文档和实际行为对不上。

所以这次我把各路来源——官方仓库、社区聚合站、GitHub 趋势、用户自发分享——里的 Server 信息抓下来，去重、分类、逐个过了一遍。当然，3482 个不可能每个都装上跑一遍，我按热度、维护活跃度、协议实现完整度、用户口碑做了分层抽样，实际部署测试了 100 多个，deep dive 了其中大概 40 个，最后得出了一个可能有点得罪人的结论：

真正值得用的，只有 4 类。

而且这 4 类不是按“领域”分的，是按“解决什么问题”分的。下面详细说。

1. 为什么我决定把 MCP Server 全量筛一遍

先说背景，方便你对号入座。

我们团队做的是 AI 辅助开发工具链的落地，会同时用到 Claude、Codex、Cursor 这类编码助手。这些工具本身能力很强，但有个天生的短板：它们拿不到你本地的文件内容、数据库结构、设计稿信息，也没有权限直接操作你的开发环境。MCP 这个协议就是为了解决这个问题的——它像一根 USB 线，把 AI 模型和外部工具、数据源连起来，让模型能通过标准化的接口去读写文件、查数据库、调浏览器、操作设计软件。

协议本身很轻，就是 JSON-RPC 2.0 那套，定义了tools、resources、prompts三类原语。但协议轻不代表生态不乱。恰恰因为接入门槛低，任何人都能写一个 MCP Server 丢到 GitHub 上，导致整个生态鱼龙混杂。我筛选时最头疼的不是“找不到”，而是“找到太多但没法判断哪个靠谱”。

这也解释了为什么社区里 MCP 相关的问题永远集中在几类：

• “Cursor 怎么配 MySQL 的 MCP？”——数据库类，刚需。
• “VSCode Copilot 能连 Figma MCP 吗？”——工具链打通，大家都在试。
• “Codex 怎么添加 MCP？”——官方支持后，一堆人接不上。
• “某个 MCP Server 登录失败 / token 过期 / 握手失败”——协议实现和认证流程问题。

每个问题背后都是一个 Server 的选型和使用问题。见过太多人装了 10 个 MCP Server，最后真正天天用的只有 1 个，其余 9 个要么配置太复杂，要么维护不活跃，要么干脆就是玩具项目。

我这次筛选的视角很明确：不看你属于什么领域，只看你对一个真实用户有没有不可替代的价值。

2. 从 3482 个 Server 里筛出来的方法

先交代筛选方法，否则结论没有说服力。

我抓取了 github、mcp.so、mcp.directory、pulse.mcp.so 等几个主要 MCP 聚合源的公开列表，合并去重后得到 3482 个项目。然后按下面的流程分了三轮筛选：

第一轮是硬指标粗筛。一个 MCP Server 如果连最基本的条件都达不到，直接淘汰：

• 仓库存在且不是 fork、不是存档（archived）状态
• 最近 12 个月内有实际代码提交，或者 star 数超过 200
• 有可用的 README 或文档，包含安装和配置说明
• 不是“hello world”级别的示例项目（比如只暴露一个 echo 工具）

这一轮下来，3482 个直接缩到 700 多个。说实话，大量项目就是蹭热度创建的，README 写得比代码还长，跑起来却什么都干不了。

第二轮是跑通测试。我在隔离环境里给剩下的项目装依赖、配环境变量、启动 server，用 MCP Inspector 或测试客户端去连，看能不能正常握手、能不能调通至少一个工具。

这一轮暴露的问题特别多：

• Python 项目依赖冲突、Node 项目版本不对，启动就报错
• 有些 Server 启动时静默失败，日志里没有错误信息，连上后所有工具调用都返回空
• 认证流程写得不清不楚，token 过期后根本没有刷新机制
• 有相当一部分依赖外部 API，但免费额度用完了，没法实跑

第三轮是价值评估。把跑得通的 Server 按“能不能解决一个真实问题”来打分。这里有个很关键的标准：这个 Server 能不能做到我单独靠提示词做不到的事？

比如访问本地数据库结构、操作设计软件、控制浏览器、读本地文件系统、调用企业内部的 API 网关——这些是模型本身做不到的，必须通过工具。如果一个 Server 暴露的工具，我用一条提示词就能让模型自己写代码完成，那这个 Server 的边际价值就大打折扣。

三轮筛选后，真正让我觉得值得长期使用的，集中在了 4 类里面。

3. 第一类值得用：文件与上下文访问类 Server

这一类解决的是最基础也最刚性的需求：让 AI 真正读到你的代码库和文档，而不仅仅是靠你手动复制粘贴。

用过的都知道，编码助手如果只能在一个文件里帮你改代码，那它就是个高级补全插件。但在多文件项目里，它经常找不到某个函数在哪定义、某个配置在哪修改。文件访问类 MCP Server 就是来解决这个问题的，它把工作目录映射成一个资源树，AI 可以通过协议直接遍历目录结构、读取文件内容、甚至按语义搜索。

现在比较稳的几个方案集中在两类实现上：

第一类是在 IDE 插件层面集成的。Cursor、VSCode 的 Copilot 这类工具，本身有“读取当前项目上下文”的能力，但这种能力是封闭的，不遵循 MCP 标准。它们的优点是零配置就能用，缺点是离开这个 IDE 就没了，而且对项目外的文件无能为力。

第二类是独立跑的 MCP Server，比如文件系统访问、项目代码库语义索引这一类。这类 Server 的优势是通用性强，Claude Desktop 能连、Codex 能连、自己写客户端也能连。用它你可以做到：

• 让 AI 自动遍历 docs 目录，找出所有提到了某个 API 的文档，然后基于这些文档生成迁移方案
• 让 AI 读取本地未提交的代码变更，结合仓库的提交历史分析潜在的回归风险
• 给 AI 暴露一个日志目录，让它自己去找最近的报错信息并给出排查建议

用途远不止这几种。我实际用得最多的是一个基于 SQLite FTS5 的代码语义搜索 Server。它会把指定目录下的文本内容做分词索引，然后用 SQL 的全文搜索能力做关键词匹配。我对它的评价是：它不解决“AI 能不能写代码”的问题，它解决的是“AI 能不能找到该改哪段代码”的问题。

为什么说这一类值得用？因为几乎所有 AI 编程场景的第一步都是“让它理解现状”。而现状的理解，光靠 prompt 和模型自己的训练数据是不够的。你的代码库、文档、配置文件，这些信息都只存在于本地，MCP 是让模型触达这些信息的最干净的方式。

3.1 文件访问 Server 里值得关注的实现

我自己实测下来稳定性比较高的两个方向：

1. 按文本向量做的检索（适合代码量中等、文件多的仓库）
2. 按目录树直接映射的读写（适合结构简单但需要“边说边改”的场景）

第一种就是热度很高的代码库语义检索那一类，GitHub 上能找到四五个实现相近的项目。它们的共同点是：离线建索引、启动时加载到内存、暴露搜索工具、返回带行号的代码片段地址。实测中需要注意索引构建时间，我拿一个 50 万行代码的中型仓库试过，最长的花了将近 10 分钟建索引，但索引完成后搜索响应基本在 100ms 以内，体验在可接受范围内。

第二种则更接近“给 AI 一个文件系统 API”。它会暴露 read_file、write_file、list_directory 这类工具。别看简单，在脚本类任务里特别有用——比如让 AI 批量重命名一组文件、给几十个 Markdown 文件统一加个 frontmatter。这类 Server 要特别注意权限控制，因为给 AI 的写权限越大，风险越大。

3.2 用文件类 Server 的权限建议

接入这类 Server 时，我强烈建议只暴露一个工作目录，不要直接给根目录或整个用户目录的权限。

有些 Server 的设计会给一个“根路径”参数，默认可能是当前用户目录，改不改全看你自己。如果你把整个~都暴露给 AI，它理论上可以读取你 SSH key、通讯录、浏览器文件。本地模型还好，如果是云端 API 调用，你的敏感信息会被发到第三方。

我的习惯是给这类 Server 单独建一个 workspace 目录，需要什么业务文件就复制或软链进去。权限上，优先用只读模式，除非确实需要让 AI 改文件，再去放开写权限。这个习惯帮我避免过不少把配置文件改坏的事故。

4. 第二类值得用：数据库操作类 Server

数据库是 MCP Server 里另一个刚需场景。你让 AI 写一条 SQL 很容易，但让它“看看数据库里到底有哪些表、每张表长什么样、某个字段有哪些值、然后写一条正确的 SQL”，没有数据库访问能力是做不到的。

数据库类 MCP Server 要解决的核心问题不是“SQL 生成”，而是“让 AI 获得数据库的 schema 信息和样本数据”。模型在训练时见过大量 SQL，但没见过你的表结构。没有这些信息，AI 只能猜，猜错的概率非常高。

这一类 Server 现在相当成熟了，MySQL、PostgreSQL、SQLite 的都有实现得不错的。总共测试下来，我能给的建议是：

如果你用的是 SQLite，不要装 Server，直接用协议里的 resource 模版。因为 SQLite 是一个本地文件，你可以直接通过文件访问类 Server 把.db文件的位置告诉 AI，然后用一个轻量 agent 去调用 sqlite3 CLI。多绕一层 MCP Server 反而增加复杂度，没带来额外价值。

如果你用的是 MySQL / PostgreSQL，值得装一个专门的 MCP Server。实测中最常见的坑是认证失败：很多 Server 用mysql2这个 Node 库做连接，但没处理好 socket 连接和 TLS 的兼容问题，导致用户在 Windows 上连本地 MySQL 时报“以一种访问权限不允许的方式做了一个访问套接字尝试”这类的错误。这个报错常见于 Node 应用和 MySQL 通信时的 socket 路径冲突，一般把连接方式从socketPath改成host: 127.0.0.1就能绕过去。

另一个常见问题是 Server 暴露的工具粒度不同。有的 Server 只暴露一个execute_sql工具，需要 AI 自己管理连接、处理事务。有的 Server 做得好一些，会把“列出所有表”“查看表结构”“执行查询”拆成独立的工具，限制 AI 只能读不能写。在测试中，后一种的误操作率明显更低，因为 AI 在没有“写入工具”可选时，根本不会去冒险生成UPDATE或DELETE语句。

4.1 实测中最理想的使用姿势

我目前的生产环境配置是这样的：

• PostgreSQL 用一个支持list_tables、get_schema、execute_select的只读 MCP Server
• AI agent 负责分析需求、生成 SQL、调用 Server 执行查询
• 查询结果返回给 agent，用来做下一步决策
• 所有 DDL / DML 操作走人工审批，不让 AI 直接执行

这种模式下，AI 能把“从拿到需求到产出可用 SQL”这个过程缩短到一个请求内完成。过去你得先把表结构拷给 AI，再把业务需求描述清楚，让它生成 SQL，然后你手动去数据库执行，再把结果丢回给它调整。现在这些步骤可以在对话里自动循环，效率提升非常明显。

4.2 数据库 MCP Server 的选型要点

我总结几个选型时要关注的点，都是踩过坑换来的经验：

1. 看它支持哪些验证方式。密码、SSL、SSH 隧道、IAM 这些能不能配置。最好支持环境变量注入，而不是在配置里写明文密码。
2. 看它有没有“只读模式”开关。这个必须有，没有就等于裸奔。
3. 看它会不会缓存 schema。每次查询都去 information_schema 拉全表结构，性能会有问题。好的实现会缓存且有失效策略。
4. 看查询结果的行数上限。有些 Server 不设上限，一个全表查询能返回几十万行，直接把上下文撑爆。

一句话结论：数据库这类的 MCP Server 不是给 AI 用的，是给“被你信任的 AI”用的。权限收得越紧，你用起来越放心。

5. 第三类值得用：设计工具桥接类 Server

第三类多少有点出乎我意料，但实测下来确实很有价值：设计工具桥接类 MCP Server。

代表就是 Figma MCP Server，还有一小撮针对 Sketch、蓝湖这类设计协作工具的同类实现。这类 Server 的价值在于：它把设计稿里的信息结构化了，AI 可以直接读取图层、颜色、字体、间距这些属性，然后基于这些属性去生成代码。

为什么这个重要？因为传统的“设计稿转代码”流程长且容易失真。设计师交付的是图片或链接，前端工程师拿到的是一堆需要手动测量的色值和尺寸。有了 MCP Server，AI 可以直接读取设计稿的结构化数据，做到“所见即所得”的还原。

实测中我在 Cursor 里接入 Figma MCP 后，让它根据一个按钮组件的设计稿自动生成了对应的 React 组件。第一次生成的结构跟我手写的基本一致，样式数值也是准确的。整个过程比人肉量尺寸快太多了。

但必须提醒一句：这类 Server 的高度取决于设计稿的质量。如果你的设计稿图层乱七八糟、自动布局没做好、命名全是“Frame 182”，那 AI 读到的也是一堆垃圾信息，生成不了什么好代码。换句话说，这类 Server 对规范化设计要求比较高，适合设计系统成熟、组件库成体系的团队。反之，你会觉得它徒有其名。

另外，Figma MCP 这类 Server 的认证流程是它最大的使用门槛。它的 OAuth 配置不算简单，还经常有 token 过期的问题。社区里大量“无法连接”“token 失效”的提问都是这个环节出的。接入时建议把 token 存在环境变量的管理工具里，同时关注过期时间，提前刷新。

5.1 这类 Server 的真实场景不只有“设计稿转代码”

我实际使用中发现，它的价值覆盖面比很多人想的宽得多：

• 设计规范审查：让 AI 检查某个页面的实现是否符合设计规范。它可以直接调用 MCP 获取组件的实际属性，跟规范条目做比对，输出差异报告。
• 设计稿 diff：同一个组件在两个版本的设计稿里有什么变化，让 AI 对比图层属性和布局差异。
• 自动生成设计 token：把设计稿里的颜色变量、字体变量导出来，映射成代码里的 design token。

它的核心价值就是把“视觉-代码”之间的翻译过程自动化了。对任何一个前端工程化做得比较好的团队，都是值得投入时间去接的。

6. 第四类值得用：本地环境操作与浏览器控制类 Server

第四类可能争议最大，但也是我觉得潜力最大的：本地环境操作与浏览器控制类 MCP Server。

这类 Server 暴露的是“让 AI 直接操作你的浏览器”或“让 AI 在本地终端执行命令”的能力。听起来有点吓人，但确实解决了一大类问题：很多任务只有 AI 亲自去点、去试、去看渲染结果才能做好。

浏览器控制类的代表是 Playwright MCP Server。它能控制浏览器完成跳转、点击、输入、截图，也能读取网页的 DOM 结构和控制台日志。我在实际测试中用它完成过一个非常烦人的任务：自动化验证一个管理后台的 20 多个权限组合。之前靠人工点，每次发布都要花一下午。现在让 AI 控制浏览器按测试用例跑一遍，跑完输出一份截图 + 断言结果汇总，十几分钟就完事。

终端操作类的 Server 也有，主要是暴露execute_command能力。但我对这类 Server 的态度比浏览器控制谨慎得多。让 AI 直接跑终端命令，本质上就是把 shell 的权限交给了模型，一旦 prompt 注入或者模型判断失误，可能造成不可逆的破坏。我的建议是：如果要给 AI shell 能力，一定要单独建用户、限制可执行命令白名单、容器化隔离，且绝对不能把生产环境接进去。

浏览器控制类和终端操作类虽然同属“环境操作”，但风险等级是完全不同的。浏览器里跑的是渲染引擎的沙箱，即使 AI 误操作，扫死一个 tab 也就重开的事。但终端命令是直接系统级权限，所以两者建议区分对待。

6.1 Computer Use 和 MCP 的区别

测试浏览器控制类 Server 时，很多同事会拿它跟 Anthropic 的 Computer Use 对比，问我这俩到底啥区别。

本质区别就一条：Computer Use 是模型厂商提供的“视觉+鼠标键盘模拟”能力，它通过截图来理解界面、通过模拟输入来操作界面；而 MCP 是一种协议，它定义了模型怎么跟外部工具通信，不限定工具的粒度。浏览器控制类 MCP Server 走的是 DOM 级别的结构化操作，而不是像素级别的视觉模拟。

实际效果上，DOM 操作比视觉模拟快得多、准得多，还不会遇到“截图里看不清控件”这种尴尬问题。Computer Use 的适用场景是那些没有 API、只能人肉操作的遗留系统；而 MCP 走 DOM 的场景是“这个页面我可以拿到结构化数据，为什么还要用猜的”。两者不是替代关系，更多是互补——一个应对黑盒，一个应对白盒。

6.2 浏览器控制 MCP 的配置建议

如果你准备试 Playwright MCP，有几个建议可以参考：

1. 用 headless 模式跑测试。无头模式对 form 提交类任务工作效率更高，也更稳。需要人看过程时才用 headed 模式。
2. 控制并发浏览器实例数。同时开多个浏览器实例会让系统资源消耗很大，还容易在截图时出现白屏，建议起步用一个实例。
3. 给它独立的 user-data-dir。不要让 AI 操作你日常用的浏览器 profile，否则登录态、插件都是风险点。

这类 Server 最可能在接下来一年成为 MCP 生态里最活跃的方向，因为它真正解决了“AI 不光会说，还能动手”的问题。

7. 剩下那些 Server：它们为什么不值得装

说完了值得用的，再聊聊那些被筛掉的。不是所有没入选的都没价值，而是它们大多有替代方案，或者还没到能用程度。

第一类是“官方 API 的裸封装”。很多 Server 就是把某个服务的 OpenAPI 规范直接转成了 MCP 工具，没有任何额外逻辑。这类 Server 的问题在于：模型本来就知道这些 API 的用法，你把 API 变成 MCP 工具，它只是换一种方式调而已，没有增加任何“感知”或“决策”能力。而且这类 Server 还额外引入了一层依赖，一旦上游 API 变更，它还可能挂掉。如果你要用某个服务的 API，不如直接用 function calling 或让模型基于文档生成代码去调。

第二类是“玩具型工具集”。这类 Server 会暴露一些看起来很酷但实际没用的工具：生成二维码、查天气、返回随机笑话。它们确实演示了 MCP 协议的可能性，但作为日常工具去用，价值很低。

第三类是“认证永远配不通”的私有服务 Server。有些 Server 是给企业内部或某个特定 SaaS 做的，文档里写了认流程，但配置起来极其麻烦。实测中我遇到过 token 获取文档已经更新，但代码还停留在旧版，导致整个 OAuth 流程跑不通。这类项目往往只有作者一个人在维护，issue 也没人回。

第四类是早就不维护的过期 Server。MCP 协议去年火起来之后，大量项目被创建又迅速被弃坑。这批 Server 是最坑的：它们会出现在搜索列表里，但是跑不起来，或者跑起来了行为跟文档完全不一致。这就是为什么我第一轮就把“12 个月内有提交”作为硬性指标。

我没具体点名，是因为这类项目过两周就换一批新的，点名没有意义。想避开它们的办法只有一个：用之前先看仓库的 star 数量、最近提交时间、issue 响应情况这三项。

8. 接入 MCP 的实操步骤和避坑点

前面这四类到底怎么接，很多人在配置这一步就卡住了。我把从零到一跑通一个 MCP Server 的通用流程写一下，基本能覆盖 80% 的场景。

8.1 在 Claude Desktop 里添加 MCP Server

Claude Desktop 是最简单的 MCP 宿主。添加方式在设置的 Advanced 选项里找到 Developer 模式，会有一个 MCP 服务器的配置入口，通过编辑 JSON 配置文件来加。

格式大约是：

{ "mcpServers": { "server-name": { "command": "npx", "args": ["-y", "server-package-name"], "env": { "API_KEY": "your-key" } } } }

关键是command和args两个字段要写对。最常见的坑是：Windows 上npx要写成cmd /c npx，因为直接写 npx 会找不到命令。另一个坑是env里的配置项名称要跟 Server 实际读取的完全一致，少一个字母都可能启动失败。

8.2 在 Cursor 里配置 MCP Server

Cursor 的 MCP 配置入口在 Settings 的 Features 选项卡里。它支持两种方式：

• 全局配置：在~/.cursor/mcp.json里写，对所有项目生效
• 项目级配置：在项目根目录的.cursor/mcp.json里写，只对当前项目生效

同样的 JSON 格式。但注意 Cursor 对某些类型 Server 的支持需要特定配置项，比如浏览器的参数要传对。Cursor 接 MySQL 的 MCP 是社区里问得最多的话题之一，核心还是那几步：确保 MySQL 允许远程连接（或使用本地 socket）、把 host 和端口写对、用户名密码用 env 传递。

8.3 在 Codex 里接入 MCP Server

Codex 支持 MCP 的方式跟 Claude Desktop 类似。命令行版本用一个配置文件指定mcp_servers字段，Web/IDE 版本在设置里找 MCP 配置入口。

Codex 接入 MCP 常见的一个问题是：Server 启动失败后，Codex 只报一个笼统的错误，不告诉你具体原因。这时候别在 Codex 的日志里死磕，直接把启动命令拿到终端里手动跑一遍，看有没有报错。大多数问题都是依赖缺失或 env 没配好，终端里一眼就能看出来。

8.4 三种接入方式的对比

配置难度从低到高，灵活度也从小到大，你要做的就是匹配自己的场景。

9. 排查 MCP 连接失败的经验

最后写点排错经验。MCP Server 连接失败这个问题，热搜词里一抓一把，我自己也踩过不少坑。按照下面这个思路排查，能省下一个下午：

第一步，确认 Server 进程有没有起来。把启动命令放到终端里，手动执行一遍，看有没有报错。这一步能过滤掉一半的问题。

第二步，确认配置文件里的启动命令和参数对不对。特别是 Windows 上npx的问题、Python 项目用python -m而不是python的问题、Node 项目版本不对的问题。

第三步，确认宿主工具能看见 Server。在 Claude Desktop 里如果 Server 是 404 或者红色的错误状态，先看 Server 的日志输出，找到报错的具体原因。如果是“failed to start login server”或“token exchange failed”这类错误，基本都是认证流程的问题，去检查 token 的获取方式和有效期。

第四步，确认你的本地端口和网络权限。有些 Server 会监听一个本地端口，如果 8080 被其他应用占了，启动就会失败。SQL Server 安装、Windows Server 配置这类场景，经常出现权限不允许访问的问题，这时候把服务改为手动启动、以管理员身份运行，基本能解决。

第五步，看协议版本是否匹配。MCP 协议有两版主要规范差异——早期是 streamable HTTP，后来倾向用 SSE，最近的 SDK 又迭代了。如果 Server 端实现和新版协议不兼容，客户端连接时会报 handshake 错误或直接超时。遇到这种问题，看看 Server 最近的 release notes，或者强制指定协议版本试试。

第 5 步是个隐藏比较深的坑。比如报错里出现“lost connection to server at handshake”，十有八九就是协议版本或者编码格式的问题。这时不是 Server 没启动，是两边握不上手。解决办法是更新 Server 到最新版，或者换一个实现。

10. 最后说点实在的

这 3482 个 Server 筛下来，我的体感是：MCP 生态还处在“万事俱备，只欠好工具”的阶段。协议本身足够好，支持它的客户端也足够多，缺的是真正打磨到位、开箱即用、让人愿意长期留在配置文件里的 Server。

目前值得长期用的，就是我上面说的四类：文件与上下文访问、数据库操作、设计工具桥接、本地环境操作。这四类共同的特点是：它们在协议之上提供了不可替代的价值，并且有足够多的真实用户在使用和维护。

所以说，不要在 MCP Server 上赶时髦，先想清楚你每天被哪个“拿不到数据”或“点不了按钮”的问题卡住，再去找对应的 Server。它解决不了你的痛点，再加也还是“装了 10 个、用一个”的宿命。

如果你想接着玩，我这还有两个方向可以作为后续探索：一是本地私有化部署一个小模型，再用 MCP 连你自己的工具链，把数据完全控制在本地；二是借助订阅制的 MCP 网关，把几个高频服务统一接入一个入口，简化配置文件的管理。具体每个方案的实测结果，后面找时间再展开聊。