为什么 MCP 总是一个坏主意？

为什么 MCP 总是一个坏主意 最近我参加了一个全天的活动，该活动以 MCP 世界的最新和最伟大的内容为中心。虽然所有演讲者都很棒并且似乎对他们所做的工作充满热情，但老实说我已经厌倦了 MCP。这是一个可怕的协议，是在法学硕士还没有那么聪明的时候建立的，而且我们已经超越了它。简史 MCP 由 Anthropic 团队于 2024 年 11 月发布，作为旨在帮助代理连接到外部服务和数据源的协议。 1 当时的模型仍然相对原始，至少与我们现在的模型相比是这样。当时我们甚至没有 Claude Code，通用代理工作流程的可靠性也差得多。用户开始看到让他们的人工智能模型访问外部服务的有用性。它实现了我们以前从未见过的生产力水平。我们看到 MCP 的采用呈爆炸式增长，与此同时，整个经济领域 LLM 的采用也出现了类似的、甚至更具爆炸性的增长。随着时间的推移，MCP 在 Anthropic 的管理下不断发展，最终于 2025 年捐赠给 Linux 基金会旗下的 Agentic AI 基金会。 2 MCP 工业综合体 随着采用率的大幅增长，用户开始在其设置中添加许多 MCP 服务器，并开始遇到上下文膨胀问题。每个服务器都会配备多个工具，每个工具都有自己的模式，这开始使所有这些模型的上下文过载。利用开发人员发现了许多围绕此问题的技巧，包括 Composio、MintMCP 和 Pipedream 等平台现在提供的通用搜索/执行模式。它们都有效地解决了在一个地方放置各种外部服务的凭据的问题，并为您的代理提供了一组可用于访问它们的最小工具（以减少上下文膨胀）。我想澄清的是，从短期来看，这是一件好事。对于我们围绕 MCP 构建的所有东西，我们没有考虑到或者可能忽略的是模型正在变得更好。我们现在拥有专门用于监控 MCP 服务器的整个系统，确保响应良好，确保代理能够轻松访问工具，找出模式，并确定我们需要向代理提供什么，以便他们能够在正确的时间做出正确的呼叫。惊喜，惊喜，大实验室是对的 模型变得更好了。他们现在能够在计算机上执行代码，对大型代码库进行推理，并且通常比以前更加自主地行动。这项工作的很大一部分是为了编码目的而编写/运行脚本。副作用（虽然是这样吗？）是现在他们擅长直接调用 API。他们可以编写脚本，组合多个不同的服务，并调用他们以前从未见过的 API，所有这些都在有用的工作流程中，只需最少的用户干预。 LLM 在这方面做得非常出色，Cloudflare 甚至推出了代码模式，这是一种更好的使用 MCP 的方法，让 LLM 将各种调用组合成可以在沙箱中执行的脚本。 3 但更妙的是，法学硕士已经弄清楚如何使用 --help 命令来发现 CLI，因此他们不再需要 MCP 服务器来访问通过记录的 API 或 CLI 提供的许多服务。大多数远程服务 MCP 服务器最终都会包装已经存在的 API。现在怎么办？我们删除了大部分 MCP 服务器。就是这样。具有终端访问权限的代理可以取代大多数 MCP 服务器，并且通常能力更强。仍然存在一些问题，例如 CLI 返回机器可读的响应（JSON/XML 等），这往往非常冗长且占用大量令牌，但我们有办法解决这个问题。许多替代方案已经存在：记录的 HTTP API、标准内容协商和成熟的身份验证机制。我们应该开始标准化代理如何直接使用 HTTP API。例如，代理客户端可以附加标头以将自己标识为代理，服务器可以自动向其发送 Markdown 或文本形式的响应数据，而不是 HTML 或详细的 JSON。一些真实的例子 Accept Markdown 标头 越来越多的 LLM 友好服务器，特别是像文档网站这样的文本密集型网站，都遵循 Accept: text/markdown 标头。这些服务器可以自动发送渲染的 Markdown 文件，而不是它们通常发送的 HTML 响应。媒体类型本身是标准化的，并且将其用于面向代理的内容协商正在得到采用。使用 Accept-Language 标头的文档站点 最近，一位 Vercel 工程师要求利用 Harness 发送客户喜欢的编程语言，以便文档站点可以提供更具体的示例。例如，添加 Python 可以优先考虑 Python SDK 的文档，而不是发送通用的内容。 Shopify 的 Tobi Lutke 非常喜欢它，以至于它现在在 Shopify 文档中提供。 Malte Ubl (@cramforce)：对harnesses的请求：我喜欢你现在发送“接受：文本/markdown”。接下来的事情是：将您喜欢的编程语言放入 Accept-Language 堆中