如果你已经在用 Cursor 或 Claude Desktop，大概率见过 MCP（Model Context Protocol） 配置项：一行 npx 命令，Agent 就能读仓库、查数据库、搜网页。2026 年的问题是——该装哪几个？
社区 Server 数量激增，质量参差不齐：有的维护活跃、权限清晰；有的长期无人更新、默认暴露整个磁盘。本文不按 star 数简单排序，而是从稳定性、安全边界、Host 兼容性、工具描述质量、实战价值五个维度评测，给出分场景排名与避坑清单。排名会随生态变化调整，文内注明评测基准日期：2026 年 8 月。
评测方法论
同一 Server 在「个人写脚本」和「企业合规环境」下的评价可能完全相反。我们采用加权评分（满分 5），再按场景给出推荐等级：S（必备）、A（强烈推荐）、B（按需）、C（观望）。
| 维度 | 权重 | 考察点 |
|---|---|---|
| 稳定性 | 25% | 近 6 个月提交频率、Issue 响应、Breaking change 是否文档化 |
| 安全边界 | 25% | 目录/API 白名单、环境变量传密钥、默认权限是否过大 |
| Host 兼容性 | 20% | stdio 支持、Cursor / Claude Desktop / VS Code 实测可连 |
| 工具 Schema 质量 | 15% | 参数 description 是否清晰、减少模型误调用 |
| 实战价值 | 15% | 是否解决高频任务、与 Function Calling 相比是否值得单独装 |
说明：商业 SaaS 类 Server（Notion、Linear 等）还取决于你的订阅与 API 配额；下文评分假设已具备合法 API Key。
综合推荐 Top 10
以下面向日常开发 + Agent 编程的通用组合，覆盖 80% 个人与小团队场景。企业用户请同步阅读后文「权限最佳实践」。
| 排名 | MCP Server | 类型 | 等级 | 一句话理由 |
|---|---|---|---|---|
| 1 | @modelcontextprotocol/server-filesystem | 文件系统 | S | 官方维护，读写在白名单目录内，Agent 操作代码库的基础 |
| 2 | GitHub MCP（官方 github-mcp-server） | 代码托管 | S | Issue、PR、仓库搜索一站式，研发 Agent 几乎必备 |
| 3 | @modelcontextprotocol/server-fetch | HTTP | A | 拉取文档与 API 响应，补全模型训练截止后的信息 |
| 4 | Brave Search / Tavily 等搜索 MCP | 搜索 | A | 可控的网络检索，比让模型「假装搜索」可靠得多 |
| 5 | PostgreSQL / SQLite MCP | 数据库 | A | 只读分析场景极强；写操作务必限权 |
| 6 | @modelcontextprotocol/server-memory | 记忆 | A | 跨会话轻量知识图谱，适合个人偏好与项目备忘 |
| 7 | Puppeteer / Playwright MCP | 浏览器 | B+ | 端到端验证与抓取动态页；资源消耗大，按需启用 |
| 8 | Slack MCP | 协作 | B+ | 把 Agent 产出推到频道，适合 on-call 与评审通知 |
| 9 | Sentry MCP | 可观测 | B | 用自然语言查错误栈与 Release，缩短排障路径 |
| 10 | Docker MCP | 容器 | B | 查镜像、管容器，本地全栈开发时省力 |
Starter 套装（3 个就够起步）：Filesystem + GitHub + Fetch。需要查最新技术文档时再加搜索类；需要分析业务数据时再加 Postgres（只读账号）。
开发协作类
1. Filesystem MCP — 评分 4.8 / 5（S）
能力：在配置的根目录内读取、写入、列出文件，部分实现支持目录树搜索。
优点：官方 SDK 示例最完整；与 Cursor 等 IDE 的「项目根目录」概念天然契合；工具 Schema 简洁，误调用率低。
注意：切勿把 / 或用户主目录设为 root；生产 CI 里应禁用写工具或单独只读实例。
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/your/project"]
}
}
}2. GitHub MCP — 评分 4.7 / 5（S）
能力：搜索仓库与代码、管理 Issue/PR、读文件内容、创建分支等（随版本扩展）。
优点：把「查仓库 + 提 PR」从浏览器搬到对话流；工具命名与 GitHub API 概念一致，模型容易理解。
注意：Personal Access Token 用 fine-grained，仅授予必要仓库与只读 scope；写操作（merge、delete）在自动化场景要加人工确认。
3. Git MCP（本地仓库）— 评分 4.3 / 5（A）
与 GitHub MCP 互补：在未 push 的本地仓库上执行 status、diff、log、commit。适合「先本地理清变更再决定是否推送」的工作流。权限仍应限制在单一 repo 路径。
数据与基础设施类
PostgreSQL MCP — 评分 4.5 / 5（A）
Agent 用自然语言生成 SQL，经 Server 执行后返回 JSON 行集，是数据分析类 Agent 的利器。务必：
- 使用只读数据库角色，禁止
DROP/UPDATE除非有审批流 - 限制可访问的 schema
- 对返回行数设上限，避免大结果集撑爆上下文
返回的 JSON 数组建议用 JSON Schema 约束字段类型，再交给下游报表；开发阶段可在 JSON 工具箱本地校验样例输出。
SQLite MCP — 评分 4.2 / 5（A）
适合本地原型、嵌入式分析与单文件数据集。比 Postgres 部署更轻，但同样要限制数据库文件路径，防止 Agent 读到无关 .db 文件。
Docker MCP — 评分 4.0 / 5（B+）
列出容器、查看日志、检查镜像。对全栈开发者友好；在共享机器上应限制 Docker socket 访问，避免 Agent 启动特权容器。
Kubernetes MCP — 评分 3.8 / 5（B，按需）
适合已有 K8s 运维经验的团队。工具能力强，但集群误操作代价高；建议只读 RBAC + 指定 namespace，并与现有 GitOps 流程并存而非替代。
搜索与信息获取类
Fetch MCP — 评分 4.6 / 5（A）
按 URL 拉取 HTML/Markdown/纯文本，是「读官方文档、读博客」的最低成本方案。与全功能浏览器 MCP 相比更省资源，且攻击面更小（不执行 JS）。
建议配合 URL 白名单或域名过滤，禁止访问内网元数据地址（如 169.254.169.254）。
Brave Search / Tavily MCP — 评分 4.4 / 5（A）
当不知道 URL、需要「搜一下最新版本号/报错信息」时，搜索 MCP 比 Fetch 更合适。Brave 侧重隐私与 API 简洁；Tavily 面向 RAG 场景，返回结构化摘要。二者选一即可，避免重复占用工具槽位。
Puppeteer / Playwright MCP — 评分 4.0 / 5（B+）
需要登录态、点击按钮或渲染 SPA 时才有明显优势。缺点：慢、吃内存、截图易泄露敏感信息。推荐作为按需挂载的 Server，非常驻。
办公与协作类
Slack MCP — 评分 4.1 / 5（B+）
发消息、搜频道、读线程。适合把 Agent 生成的发布说明、Review 摘要推到团队频道。Token 用 Bot scope 最小化，禁止默认 chat:write 到全 workspace 除非必要。
Notion MCP — 评分 3.9 / 5（B）
读写页面与数据库，适合知识库型 Agent。API 限速与块结构复杂，模型偶尔构造错误 payload；适合人工复核后写入的场景。
Linear / Jira MCP — 评分 3.8 / 5（B）
创建与查询工单，衔接「从对话到任务系统」。研发流程若已深度绑定其中一家，值得装；否则优先级低于 GitHub Issue。
Google Drive / Gmail MCP — 评分 3.5 / 5（C+，谨慎）
能力诱人，但 OAuth 范围大、误发邮件或误分享文件风险高。仅建议在强审计、沙箱账号下试用。
可观测与运维类
Sentry MCP — 评分 4.0 / 5（B+）
按项目、Release、时间范围查询 Issue 与事件详情。on-call 时用对话快速定位「上周上线后新增的 N+1 错误」很省时。只读 API Key 即可覆盖大多数查询场景。
Datadog / Grafana MCP — 评分 3.7 / 5（B）
查指标、日志与 Dashboard。适合已有可观测栈的团队；查询 DSL 复杂，建议在工具描述里写清示例查询，降低模型瞎填参数的概率。
AWS / Cloudflare 文档类 MCP — 评分 3.6 / 5（B）
偏「文档检索 + 最佳实践问答」，不直接改云资源，相对安全。真正执行 terraform apply 类操作应走 CI，而非 Agent 直连接生产账号。
配置与权限最佳实践
- 最小权限：每个 Server 独立 Token；数据库只读；文件系统限定项目根目录。
- 环境变量：密钥放
env块，不要写进可提交的 JSON 配置文件。 - 工具数量：单会话可见工具建议控制在 15 个以内；过多时 Host 可分组或按任务动态加载 Server。
- 审计：记录
tool_calls名称、参数摘要与执行结果，便于复盘误操作。 - Schema 自检：自建 MCP 时，工具参数的 JSON Schema 应在 CI 中校验；样例输入输出可用 JSON 工具箱本地验证。
- 传输方式：个人本机用 stdio；团队共享服务用远程 SSE 并加认证，勿把无鉴权 SSE 端口暴露公网。
| 角色 | 推荐组合 |
|---|---|
| 前端 / 全栈开发者 | Filesystem + GitHub + Fetch +（可选）Playwright |
| 后端 / 数据工程师 | Filesystem + GitHub + Postgres（只读）+ Docker |
| 技术负责人 / on-call | GitHub + Sentry + Slack + Fetch |
| 产品经理 / 知识工作者 | Notion + Slack + 搜索 MCP |
不推荐或需谨慎的场景
- 来源不明的「万能 MCP 聚合包」：可能夹带未声明的文件访问或外联，无法审计。
- 对生产库开放写 SQL 的 Database MCP：一次幻觉可能删表；变更应走迁移脚本 + CI。
- 默认挂载整盘 Filesystem：Agent 可能读到
.ssh、.env等敏感文件。 - 同时装 3 个以上功能重叠的搜索/浏览器 Server：增加误选工具概率，浪费上下文。
- 在无沙箱环境用 Shell/Terminal MCP 执行任意命令：等同于把 shell 交给模型；若必须用，限制用户与命令白名单。
2026 年 MCP 已捐赠至 Agentic AI Foundation，生态会更规范，但安全责任仍在配置者与部署者——排名再高，错误权限配置也会酿成事故。
常见问题 FAQ
MCP Server 和普通 REST API 有什么区别？
REST API 面向人类或程序直接调用；MCP Server 面向 Agent Host，提供工具发现、Schema 描述、资源订阅与统一授权。同一业务能力可以既有 REST 又有 MCP 包装，但 Agent 侧优先走 MCP 以降低集成成本。
一次应该装多少个 MCP Server？
建议从 2～4 个高频 Server 起步（如文件系统 + Git + 搜索），确认工作流稳定后再扩展。工具过多会占用上下文、增加误调用概率，也放大权限风险。
stdio 和 SSE 传输怎么选？
本地 IDE（Cursor、Claude Desktop）优先 stdio，配置简单、进程隔离好。远程或多客户端共享服务时用 SSE/HTTP，便于部署与鉴权，但需注意网络安全与 Token 管理。
如何评估第三方 MCP 是否安全？
检查：是否开源可审计、权限是否最小化、是否把密钥写入环境变量而非配置文件明文、是否只暴露必要目录或 API scope、维护者信誉与更新频率。生产环境避免安装来源不明的 npx 一键包。
应该自建 MCP 还是先用官方 Server？
通用能力（文件、Git、Postgres、Fetch）先用 modelcontextprotocol 官方或大厂维护的 Server；只有内部系统、特殊合规或官方无覆盖时再自建，并复用官方 SDK。
MCP 工具返回的 JSON 如何校验？
为工具输出定义 JSON Schema，在 Host 侧或流水线中用校验器验证后再交给下游。开发阶段可用 JSON 工具箱在浏览器本地校验 Schema 与样例数据。
总结
2026 年最值得装的 MCP Server 并没有「唯一正确答案」，但有清晰的优先级：先把官方 Filesystem、GitHub、Fetch 打牢，再按角色叠加数据库、搜索、协作与可观测类 Server。评测时永远把安全边界放在功能丰富度之前。
若你正在搭建 Agent 基础设施，建议同时阅读本站《AI Agent 与 JSON Schema、Function Calling、MCP 技术演进》一文，理解 MCP 在整体栈中的位置；工具返回的 JSON 结构，则用 JSON 工具箱本地校验后再接入流水线。