关于 2026 年 MCP 服务器的大多数文章都是演示，不是生产栈。诚实的版本：MCP 生态系统大约有 200 个服务器，其中一半是玩具，而你为日常代理商工作实际运行的生产级栈比演示视频暗示的更小、更无趣。这是我们在 Seahawk Media 跨客户协作中运行的栈，我们学到的权衡，以及我们试过但没有赢得一席之地的东西。
关键要点：在 200 多个 MCP 服务器中，真正的生产堆栈只有大约八个：Filesystem、Puppeteer、Postgres、Brave、GitHub、Sentry 和 Notion 每天都在使用，其余都是演示。Of 200+ MCP servers, a real production stack is about eight: Filesystem, Puppeteer, Postgres, Brave, GitHub, Sentry, and Notion earn daily use, the rest are demos.
我经营一个代理商，交付定制的 WordPress、Next.js 和 Astro 工作以及 SEO 和内容。MCP 层现在对所有这些都是承重的。如果你在权衡在你的日常驱动 Claude Code 上实际安装哪些 MCP 服务器，这就是工作答案。WordPress, Next.js, and Astro work plus SEO and content. The MCP layer is load-bearing across all of that now. If you are weighing which MCP servers to actually install on your daily-driver Claude Code, this is the working answer.
我们每天运行的八个 MCP 服务器
文件系统（内置）
我们使用最多的 MCP。在项目树中读取、写入、搜索。每个 Claude Code 会话都使用它。没什么奇特的；只是必需的。
Puppeteer
用于QA、内容抓取、截图捕获、部署后验证的浏览器自动化工具。替代了我们之前订阅的两个付费SaaS工具。唯一的摩擦点是安装：我们保留了一个node-puppeteer镜像，因为Chromium依赖地狱仍然存在。
Postgres
直接对客户端数据库执行SQL查询。替代了在另一个窗口中打开的SQL编辑器标签页。特别适用于内容审计（哪些文章缺少特色图片、哪些有孤立的版本、哪些标签无法匹配任何内容）。通过Claude查询比自己编写临时SQL问题的查询要快。
Brave Search
用于SEO审计的SERP抓取。我们每天都用它进行竞争对手研究、排名诊断和AI Overview引用跟踪。Brave API比直接抓取Google更可靠；按我们的使用量，成本每月只需几美元。
GitHub
读取issues、pull requests、评论线程和仓库元数据。用于分类传入的工作、起草PR描述和将最近的提交活动综合到客户状态报告中。
Sentry
读取我们监控的生产网站的错误事件。Claude可以将Sentry事件与最近的代码更改关联起来，比我手动点击错误跟踪快得多地找出可能的罪魁祸首。每次事件响应都节省了数小时。
Notion
读取我们的内部文档和客户简报。特别适用于代码生成期间交叉参考客户标准。省去了手动"让我检查我们在发现文档中达成的协议"这一步。
Linear
读取issues、状态和指派人。用于日常站会准备、周期性客户报告，以及从提交活动自动起草issue更新。
我们尝试过但放弃的方案
五个我们安装、使用一个月后移除的MCP服务器：
Slack MCP。将Slack历史记录拉进Claude的信噪比很差。Slack消息结构不够规范，无法作为好的上下文使用。
Google Drive MCP。认证流程不稳定，文档解析也不可靠。我们改为手动导出为markdown。
通用网页抓取MCPs。当我们需要实际浏览网站时，大多数的速度都比Puppeteer慢或可靠性更低。全部移除了。
多个AI图像生成MCPs。我们已经在Claude之外有一个可用的FAL管道；MCP包装器增加了延迟，却没有节省实际时间。
数据库 MCP 通用适配器。我们尝试的所有通用数据库 MCP 中，内置 Postgres MCP 的表现最好。
MCP 堆栈卫生规则
经过一年的试验和错误，我们确定了三条规则：
少即是多
8 个 MCP 是最佳数量。我们试过 15 个，持续一个月；上下文窗口的压力让 Claude 变慢且准确度下降。每安装一个 MCP 都有上下文成本，成本会复合增长。每季度审计一次；删除最近 30 天未使用的任何东西。
内置优于第三方（当有重叠时）
Anthropic 出品的 MCP（Filesystem、官方集成）在我们的经验中比社区等效版本更可靠。我们优先使用内置版本，只有当内置版本无法满足用例时才求助于第三方。
身份验证是隐性成本
每个 MCP 服务器都有自己的身份验证方式。有些使用 OAuth，有些需要 API 密钥，有些需要服务账户 JSON 文件。设置开销是真实的；令牌轮换时的维护成本更是真实的。选择身份验证模式与现有基础设施匹配的 MCP，而不是那些需要新增凭证的。
我们在 2026 年关注的事项
我预期成熟的三个MCP类别：
代理商-CRM MCP（HubSpot、Salesforce、Pipedrive）。目前发布的版本都是alpha质量；正式版本可能在2026年下半年推出。
项目特定的MCP（一个Seahawk内部MCP，公开我们的客户数据库、定价逻辑、托管清单）。我们在自己构建这个，而不是等待通用版本。
大规模浏览器控制MCP。Puppeteer适合单页交互；在数百个页面上高效运行无头浏览器仍然需要自定义编排。这里的MCP层在改进但还未解决。
总结
八个MCP服务器每天在Seahawk运行：Filesystem、Puppeteer、Postgres、Brave、GitHub、Sentry、Notion、Linear。这就是发布的技术栈。生态系统中其他200个MCP服务器大多是演示或这些的重复。
如果你从头开始，先安装Filesystem（已经有了），然后Puppeteer，然后根据你的工作更偏代码还是更偏研究，添加Postgres或Brave。有具体需求时再添加其他的。MCP技术栈应该因工作需求而增长，绝不是因为演示视频看起来不错。
常见问题
哪些 MCP 服务器值得在生产环境中运行？
这里真实的生产堆栈是八个：Filesystem、Puppeteer、Postgres、Brave、GitHub、Sentry、Notion，再加一个根据日常代理工作选定的服务器。生态系统中 200 多个 MCP 服务器中的大多数都是演示或玩具；生产集合很小，刻意保持乏味。
你实际上应该使用多少个 MCP 服务器？
比你想的要少。生态系统大约有 200 个服务器，但生产级日常堆栈大约只有八个。添加更多只会增加维护成本和故障面，而收益很少。运行那些值得的少数几个，其余的都删掉。
你尝试过并放弃了哪些 MCP 服务器？
好几个在演示中看起来很有用，但在没有日常价值的情况下会增加维护或不可靠性。规则是服务器必须赚取持续使用，而不是仅仅演示一次表现出色。堆栈卫生比覆盖范围更重要。
什么样的 MCP 服务器才算生产就绪？
可靠性、明确的日常使用案例和低维护成本。生产服务器是你的团队每天都会用到的，并且相信它不会破坏工作流的服务器。如果它只在演示中表现突出或需要不断的维护，那么它就不属于日常堆栈。