为何MCP一直是个糟糕的想法？

# 为何MCP始终是个糟糕的构想 来源：https://maharship.com/blog/why-mcp-was-always-a-bad-idea/ ## 为何MCP始终是个糟糕的构想 最近我参加了一场围绕MCP领域最新进展的全天活动。虽然所有演讲者都很出色，似乎对他们从事的工作充满热情，但老实说，我已经厌倦了MCP。这是一个为LLM还不够智能的时代而构建的糟糕协议，而我们早已超越了那个阶段。 让我直说吧——你认为MCP是个糟糕的构想？我的确这么认为，而且我厌倦了假装它不是。 ## 简史 MCP于2024年11月由Anthropic团队发布，是一个旨在帮助智能体连接外部服务和数据源的协议。¹（https://maharship.com/blog/why-mcp-was-always-a-bad-idea/#user-content-fn-1）当时的模型仍然相对原始，至少与我们现在拥有的相比。那时我们甚至还没有Claude Code，通用型智能工作流也远没有那么可靠。 用户开始看到让AI模型访问外部服务的价值。这带来了前所未见的生产力水平。我们见证了MCP采用率的激增，恰逢大语言模型在整个经济中的采用也以同样——甚至更迅猛的——速度增长。 随着时间推移，MCP在Anthropic的主导下持续演进，最终于2025年捐赠给了Linux基金会旗下的智能AI基金会。²（https://maharship.com/blog/why-mcp-was-always-a-bad-idea/#user-content-fn-2） ## MCP工业复合体 随着采用量的巨大增长，用户开始在自己的配置中添加大量MCP服务器，于是开始遇到上下文膨胀问题。每个服务器都会附带多个工具，每个工具都有自己的模式，这开始让所有这些模型的上下文不堪重负。工具开发者们想出了许多技巧来解决这个问题，包括像Composio、MintMCP和Pipedream这类平台现在提供的通用搜索/执行模式。它们实际上都解决了为各种外部服务集中存放凭据的问题，并为你的智能体提供了一组最简工具（以减少上下文膨胀）来访问这些服务。我想明确指出，*短期来看*，这是一件好事。 围绕MCP构建的所有这些内容，我们没有考虑到——或者说可能忽略了——模型正在变得更好。我们现在有整套系统专门用于监控MCP服务器，确保响应质量，确保智能体能够轻松访问工具，解析模式，并确定需要为智能体提供什么，以便它们能在正确的时机做出正确的调用。 ## 惊不惊喜，大厂们是对的 模型变得更强了。它们现在能够在计算机上执行代码，理解大型代码库，并且总体上比以往任何时候都更具自主性。这部分工作很大一部分在于编写和运行用于编码的脚本。一个副作用（虽然这是副作用吗？）是，它们现在非常擅长直接调用API。它们可以编写脚本，组合多种不同的服务，调用它们之前从未见过的API，全部以有用的、用户干预极少的工作流形式完成。 大语言模型在这方面变得如此出色，以至于Cloudflare甚至推出了Code Mode，这是一种通过让LLM将各种调用组合成可在沙盒中执行的脚本来更好地使用MCP的方式。³（https://maharship.com/blog/why-mcp-was-always-a-bad-idea/#user-content-fn-3） 但比这更好的是，LLMs已经弄明白了如何使用`--help`命令来发现命令行工具，因此它们不再需要通过MCP服务器来访问许多可通过文档化API或CLI获得的服务。大多数远程服务MCP服务器最终包装的都是已经存在的API。 ## 何去何从？ 我们删除大部分MCP服务器。就这么简单。拥有终端访问权限的智能体可以替代大多数MCP服务器，并且通常功能更强大。仍然存在一些问题，比如CLI返回机器可读的响应（JSON/XML等），这些响应往往非常冗长且耗费token，但我们有办法解决。 很多替代方案已经存在：文档化的HTTP API、标准化的内容协商以及成熟的身份验证机制。 我们应该开始标准化智能体直接使用HTTP API的方式。例如，智能体客户端可以附加标头来标识自己为智能体，服务器则可以自动以Markdown或文本而不是HTML或冗长的JSON形式发送响应数据。 ### 一些实际案例 1. **Accept Markdown 标头**：越来越多对LLM友好的服务器，尤其是像文档网站这样文本密集的站点，会识别`Accept: text/markdown`标头。这些服务器可以自动发送渲染好的Markdown文件，而不是通常会发送的HTML响应。该媒体类型本身是标准化的，并且将其用于面向智能体的内容协商正逐渐普及。 2. **文档站点使用 Accept-Language 标头**：最近，一位Vercel工程师呼吁工具在请求中发送客户端偏好的编程语言，这样文档站点可以提供更具体的示例。例如，添加Python可以优先显示Python SDK的文档，而不是发送通用内容。Shopify的Tobi Lutke非常喜欢这个想法，以至于现在Shopify文档已经实现了这一功能。 Malte Ubl (@cramforce): 对工具的请求：我很喜欢你们现在发送“Accept: text/markdown”。下一步是：在Accept-Language标头中放入你偏好的编程语言。(https://x.com/cramforce/status/2096609086649647324) Tobi Lutke (@tobi): 好主意。Shopify文档会支持这个。(https://x.com/tobi/status/2097775334254907414) ## 结语 围绕通用协议的标准化将互联网发展成了今天的模样。MCP如今已成为一个过时时代的协议。智能体已经足够聪明，能够编写脚本并精确请求所需内容。与其继续在MCP的兔子洞里越陷越深，我认为是时候将其生命周期终结，直接依赖那些已经提供了必要接口的HTTP API和命令行工具了。 1. Anthropic，“介绍模型上下文协议” (https://www.anthropic.com/news/model-context-protocol)，2024年11月25日。↩ (https://maharship.com/blog/why-mcp-was-always-a-bad-idea/#user-content-fnref-1) 2. Anthropic，“捐赠模型上下文协议并成立智能AI基金会” (https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation)，2025年12月9日。↩ (https://maharship.com/blog/why-mcp-was-always-a-bad-idea/#user-content-fnref-2) 3. Kenton Varda 与 Sunil Pai，“代码模式：使用MCP的更佳方式” (https://blog.cloudflare.com/code-mode/)，Cloudflare博客，2025年9月26日。↩ (https://maharship.com/blog/why-mcp-was-always-a-bad-idea/#user-content-fnref-3)