大部分MCP服务器并不需要存在。你的情况可能是例外

# 大多数 MCP 服务器本不需要存在。你的情况可能是例外。——[Martian Chronicles, Evil Martians’ team blog](https://evilmartians.com/chronicles/most-mcp-servers-dont-need-to-exist-your-case-might-be-an-exception) 大多数 MCP 服务器并非智能体架构，而是过早搭建的产品接口。第一波炒作催生了太多半成品实现，因为许多产品根本不需要 MCP 服务器。有时，直接调用 API 就够了。对某些产品来说，CLI 能完成任务。对另一些来说，一个“技能”就是一次廉价的实验。本文提供了一个决策框架，帮助你判断 MCP 是否真的值得投入，如果是，又该留意哪些考量。 开门见山：[Bloomberry 对 1,412 个 MCP 服务器的分析](https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-heres-what-we-learned/) 发现，大约一半发布 MCP 的公司**根本没有面向外部的 API**。没有 API 就发布 MCP，意味着你还没有为外部消费者定义稳定、意图级别的操作。 TL;DR：[点击此处查看清单](https://evilmartians.com/chronicles/most-mcp-servers-dont-need-to-exist-your-case-might-be-an-exception#or-just-answer-these-eight-questions)。 **值得记住的简写**：API 是你的软件契约。CLI 是你的执行契约。MCP 是你的智能体访问契约。技能则是你教会智能体如何良好使用它们的方式。因此，MCP 服务器是你的产品第三个接口。如果前两个接口不连贯，第三个就无所依凭。 那些成功发布 MCP 服务器的团队，把它当作产品的任何其他部分来对待：保持狭窄、有主见，并花力气让它持续运行。只有当有足够多的人、在足够多的地方真正需要它时，他们才会认定值得构建。 本文其余部分将帮助你判断自己是否属于这种情况，或者是否应该选择其他方向。 [预约咨询 **Irina Nazarova** Evil Martians CEO](https://cal.com/team/evilmartians/exploration) ## 在构建 MCP 之前，先修复你的 CLI 和 API 当团队考虑让产品为智能体做好准备时，CLI 的问题通常会出现。**“我们应该发布一个 CLI 吗？”** **问题本身就不对**。代码智能体已经有了一个 CLI。正确的问题是：“**我们现有的 CLI 是否足够规范，能让智能体驱动它？**” 这里，“规范”意味着：稳定、非交互式的命令，围绕产品意图设计，输出结构化，并且没有仅面向人类的模式（例如混在 stdout 中的进度条）。这些规范同时有益于人类、CI 和智能体。 当团队想让产品为智能体做好准备时，下一个本能反应是：“**我们已经有了 API，能不能把智能体直接对接上去？**” **这个问题也不对**。但原因并非你想的那样！问题不在于太多客户端接入了太多工具；你的 API 是根据数据**存储**的方式设计的，而不是根据用户想**做什么**来设计的。 内部 API 充满了簿记信息：ID、分页游标、状态标志、生命周期状态、层层嵌套的对象。这种形态之所以存在，是因为数据库需要它。如果你把它交给智能体，模型会浪费有限的注意力去理解你的数据模型，然后才能做有用的事情。 > 所以，你其实不是在暴露一项能力。你只是在给数据库换个更好听的品牌名称而已。 转向 MCP 并不能修复任何底层的 API 问题。如果工具仍然像数据库行一样，MCP 只是用新协议包裹了同样的问题。相反，修复必须提前一步进行：**围绕用户想做什么来设计操作**，然后再决定 MCP 是否是正确选择。 ## 在 MCP 之前，先尝试技能 MCP 处理**访问**。技能处理**操作纪律**：这意味着指令、示例、参考文件、模板，或者有时是帮助智能体学会如何使用其他地方暴露的能力的辅助脚本。在以下情况下，**先**使用技能，**再**考虑 MCP： - **能力已经存在，但纪律缺失。** 比如说，智能体已经有了所需的 API/CLI，但使用得很糟糕：调用顺序错误、遗漏边界情况、丢失上下文。技能可以在没有服务器的情况下编码出一套操作手册。 - **你想廉价地测试需求。** 如果使用量真实存在，那么 MCP 的理由会更充分。 技能可以教会智能体如何使用 API、CLI、本地文件或 MCP 服务器，并且可以包含用于确定性辅助工作的脚本。但它不提供租户范围、远程访问、授权、审计或跨进程治理。如果这些原语应该属于产品接口的一部分，那么你需要一个外部边界（例如 MCP），而不仅仅是一个技能。 我们将在本文的剩余部分看到这个边界是什么样的。 ## 证明构建 MCP 服务器合理的主要理由 在决定是否构建 MCP 服务器时，有一个重要的信号值得关注：**你无法控制的 AI 客户端也在使用同样的操作。** 例如，假设你的用户生活在不同的客户端中，比如 Claude、Cursor、ChatGPT、Copilot、客户自建的智能体，并且他们希望你的产品能在这些地方使用。 如果不是这样，那么 MCP 基本上只是在函数调用已经提供的功能之上增加了一层额外的协议：一个单一应用内的智能体对接单一后端，可以直接使用 OpenAI Responses API 或 Anthropic tools API 来调用相同的操作，而且仪式感更少。 一旦存在跨客户端需求，维护一个统一规范契约的成本就可能胜过 N 个各自为政的客户端集成。这就是为什么 Linear、Sentry、Resend、Cloudflare 和 Stripe 都发布了官方的 MCP 表面：有些是远程集中托管的，有些是作为本地或自运行服务器分发的，但所有这些都旨在让产品能力对 AI 客户端可用。 ## MCP 的放大器 下面每一项都可以在应用层通过函数调用来解决。它们单独来看都不能证明 MCP 的合理性。但是，一旦上述承载主要负荷的信号（跨客户端需求）被确认为真实存在，以下几点就能加强论证，并决定服务器应该包含什么。 1. **你的服务运行在与智能体不同的进程中**：第三方 SaaS、另一个团队的服务、智能体通过网络访问的远程系统。对于 AI 客户端消费者来说，MCP 越来越成为它们与原生连接器、函数调用和 IDE 特定扩展一起使用的共享协议。 2. **将原始数据或低级调用转化为意图级操作的确定性处理**：聚合、过滤、归一化、组合。用 `find_flaky_tests` 代替五次 CI 调用和手动拼接。用 `get_customer_context` 代替让模型自己去连接用户、工作区、计费状态和事件。这在任何层面都是良好的工具设计；MCP 只是当这一层是跨客户端时的交付方式。 3. **无法放入上下文的代码库、文档集或数据集**。智能体进行搜索、获取和过滤，而不是被动地接收所有内容。这种“拉取”模式本身对函数调用来说是通用的；MCP 使得相同的拉取表面在多个客户端之间可被发现。 4. **需要治理的写入能力自动化**。一旦智能体能够改变状态，操作就需要作用域、审批和审计。后端仍然负责执行。MCP 可以帮助通过支持[elicitation](https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation) 的客户端来呈现用户输入或确认，但支持程度参差不齐，因此请为最弱的目标客户端设计这些流程。 ## 知道什么应该（以及不应该）放在 MCP 服务器中 收集上下文属于 MCP；决定用户目标则不是。准备回滚预览属于 MCP；选择回滚是否是正确的业务决策则不是。 > 如果你说不清什么应该属于服务器，那么你还没准备好。规则很简单：**封装操作，而不是工作流**。 - **允许的：** 确定性组合、验证、数据投影、权限检查、预览。 - **危险的：** 自主目标选择、不可逆的业务决策、没有可检查预览的隐藏多步规划。 - **灰色地带：** 摘要、排序、创建工单（只有在有明确约束、确定性输入以及模型必须首先呈现预览才能提交的情况下才有用）。 这个规则有一个清晰的示例和一个值得注意的例外。 **获胜示例**：Sentry 的 API 涵盖问题、事件、发布、性能数据、告警、计费和组织管理。它的 MCP 暴露了大约十几个工具，全部围绕一个工作流：代码智能体调试生产问题。管理、团队管理和计费保留在 API 中。该服务器通过解决好一个工作流达到了每月 5000 万次请求，这是保留约束所需的最少操作，而不是封装最多的端点。 **例外是表面过大，无法用意图工具涵盖。** 有些产品无法简化为少量意图工具。例如，Cloudflare 的 API 大约有 2,500 个端点；每个端点一个工具会在第一条消息之前消耗超过一百万 token 的 schema。它的 MCP 改为提供两个工具（`search` 和 `execute`），并让智能体在沙箱中根据类型化的 spec 编写代码（*codemode* 模式，无论表面大小如何，大约 1000 token）。它假设了一个可编程平台和一个能很好地编写代码的模型，所以并非适合所有人——但对于拥有数千个端点的表面，它比策划那些无法覆盖整个范围的意图工具要好。 MCP 不会取代你的后端、评估、可观测性或权限设计。智能体仍然决定下一步做什么。隐藏复杂性，而不是责任。 **上下文预算。** [Anthropic 报道](https://www.anthropic.com/engineering/advanced-tool-use)了五台服务器、58 个工具的设置，在第一条消息之前消耗了大约 55K token，内部案例在优化前达到了 134K token。工具目录是提示词的一部分：每个名称、描述和 schema 字段都在消耗上下文。工具搜索和延迟加载在宿主或模型平台支持的情况下可以缓解这个问题，但它们不能解决上游的工具设计问题。MCP 服务器设计就是提示词设计。糟糕的接口设计会变成延迟、成本和更低的工具选择准确率。 **运营成本。** MCP 服务器是你需要运维的软件：部署、正常运行时间、版本控制、向后兼容性、可观测性、事件响应。[Portkey](https://portkey.ai/docs/product/mcp-gateway) 作为一个 MCP 网关产品（客户端与服务器之间的认证、访问控制、审计、限流）的存在，恰恰说明市场与架构表达了同样的观点：生产级的 MCP 需要协议本身没有捆绑的治理基础设施。 **安全债务。** [Astrix 对 5,205 个 MCP 仓库的审计](https://astrix.security/learn/blog/state-of-mcp-server-security-2025/)发现，88% 需要凭据，53% 依赖静态 API 密钥或 PAT，只有 8.5% 实现了 OAuth。威胁[不仅仅是通用的 API 卫生问题](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html)；MCP 将 API 安全与智能体特有风险结合在一起：共享注册表中的[工具投毒](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)、通过工具输出进行的提示词注入、跨租户的混淆代理、通过 npm 或 pip 分发的 stdio 服务器带来的供应链风险。把 MCP 当作“又一个适配器”，就是把清晰的边界变成事故。 **审批洗白。** 这是一个值得命名的失败模式：一个无害的预览后跟着一个用户已经同意的破坏性调用。设计破坏性步骤需要它自己的同意（而不是继承预览的同意），不能只靠客户端；服务器必须强制执行边界。[Resend 的 MCP](https://resend.com/docs/mcp-server#what-can-resend%E2%80%99s-mcp-server-do)（发送邮件、管理联系人、验证域名、读取入站邮件）的广度，正是为什么作用域、审批、审计日志和撤销不能是可选的。一旦智能体能够改变面向客户的通信基础设施，标准就会提高，并且始终保持下去。 **客户端碎片化。** “一个服务器，多个客户端”是正确的，但有一个让团队在生产中感到意外的警告。MCP 规范包括工具、资源和提示词；不同的客户端实现了不同的子集。[GitHub Copilot 的云智能体](https://docs.github.com/en/copilot/concepts/agents/cloud-agent/mcp-and-cloud-agent)目前暴露了 MCP 工具，但不支持资源和提示词，也尚未接受远程服务器的 OAuth 流程，并且自主使用可用工具，无需在每次调用前请求批准。[Cursor](https://cursor.com/docs/mcp#protocol-and-extension-support) 支持工具、提示词、资源、根、elicitation 和 apps。[Gemini CLI](https://google-gemini.github.io/gemini-cli/docs/tools/mcp-server.html#mcp-prompts-as-slash-commands) 将提示词视为斜杠命令。协议是同一个。客户端则不是。为最弱的目标客户端设计，否则服务器在生产中将对一半用户失效。 ## 或者，直接回答这八个问题 下面的问题可以快速过滤出“是”或“否”。 1. **是否只有一个你控制下的应用内智能体会使用它？** → 使用直接 API 工具。不需要 MCP。 2. **这个工作是否适合一个带有类型化输出的 shell 管道？** → 首先让 CLI 变得可被智能体操作。 3. **缺失的是能力，还是使用纪律？** → 如果是纪律，针对你已有的 CLI 发布一个技能。如果是能力，继续。 4. **智能体是否需要结构化发现、运行时上下文或跨客户端复用？** → 如果都不需要，MCP 为时过早。 5. **你的目标客户端是否消费你需要的 MCP 功能——工具、资源、提示词、OAuth、elicitation？** → 如果你的最低可行子集不符合最弱目标客户端的要求，停止。 6. **你能说出 3-5 个稳定的、意图级别的操作吗？——或者对于巨大的可编程表面，一个搜索/执行模式？** → 如果两者都不能，你还没准备好。 7. **这个操作是否具有写入能力、跨租户，或者高风险？** → 治理、审批和审计必须从原型阶段就存在，而不是事后添加。 8. **你能否在不破坏已安装客户端的情况下发布版本变更？** → 如果版本控制和弃用问题未解决，你还没有产品就绪。 对 1 或 2 的回答为“是”，则返回更小的边界。对 3，如果缺失的是使用纪律，从技能开始；如果是能力或访问，继续。对 4 的回答为“否”，说明为时过早。对 5-8 中任何一个回答为“否”，说明还未准备好。 ## 即使你得到“是”，也要留意这些 常见的 MCP 失败因素可能会让你轻易错过，如果你不知道要寻找什么： - **API 转储。** 每个端点包装成一个工具，每个内部名词暴露出来，每个 schema 都面向工程师设计。这和你破坏直接 API 调用的后端泄漏失败完全是同一个问题。 - **工具过载。** 不断增长的工具目录有着重叠的名称和 schema，一旦服务器工具数量进入两位数就常见了。像 `notification-send-user` 和 `notification-send-channel` 这样的名称不再具有区分度；模型选错工具。 - **没有安全模型。** 没有最小权限原则的认证、没有按工具划分的作用域、没有审批关卡、没有审计日志、没有提示词注入防御。一个默认允许的网络接口，就是一场等待合适提示词触发的安全事故。 - **没有评估。** 没人知道工具是否正常工作，因为没人编写过一个测试来证明它们能工作。 - **一个不了解其客户端的服务器。** 团队为最丰富的 MCP 功能集构建；实际用户却在使用只支持子集的客户端。 - **端点形状的工具。** `getUser`、`updateUser`、`deleteUser` 而不是智能体可以组合成工作的意图级操作。名称本身就暴露了问题。 - **没有版本控制故事。** 在没有命名空间、弃用窗口或仅增加 schema 演进的情况下发布破坏性签名更改，就把协议的“复合层”承诺变成了