MCP是什么——"AI的USB-C接口"的承诺
Model Context Protocol（MCP）是Anthropic于2024年11月25日发布的开源协议。它为AI模型与外部工具、数据源和服务的连接提供了标准化接口，常被称为"AI应用的USB-C接口"。从技术层面来看，它在stdio或HTTP（SSE/Streamable HTTP）传输层之上使用JSON-RPC。
在MCP出现之前，AI模型若要访问外部工具，需要为每个工具单独编写自定义集成代码。MCP承诺通过标准化来解决这一"N×M问题"（N个AI模型与M个工具的组合）。2025年3月，OpenAI在ChatGPT桌面应用中正式采用MCP，进一步加速了其发展势头。经历2025年11月一周年纪念版本规范修订，以及2025年12月捐赠至Linux Foundation旗下Agentic AI Foundation（AAIF）之后，SDK月度下载量达到9700万次，超过17,000个MCP服务器被收录索引，300余个活跃客户端构成了一个庞大的生态系统。
所有主要AI提供商——Anthropic、OpenAI、Google、Microsoft、Amazon——均已支持MCP，其行业标准的地位似乎已然确立。
支持MCP派的论点——为何获得支持
MCP的支持者援引以下优点来论证该协议的价值。
第一，作为通用标准的价值。随着所有主要AI厂商的采用，工具开发者只需实现一次MCP服务器，即可从任意AI客户端调用。这是一个经典论点——就像Web的HTTP或USB一样，协议标准化能够大幅提升整个生态系统的效率。
第二，安全框架。内置了基于OAuth 2.1的per-user身份验证、作用域权限以及审计日志。在企业环境中，每位用户以自身权限访问工具、所有操作均有记录的机制不可或缺，而MCP对此进行了标准化。
第三，生态系统规模。每月9700万次SDK下载、超过17,000台服务器、143,000个可运行AI组件——这些数字表明网络效应已突破临界点。
第四，厂商中立的治理结构。通过捐赠给Linux Foundation旗下的AAIF，MCP从Anthropic一家公司的掌控中解放出来，成为整个行业的共享资产。
这些主张表面上颇具说服力。然而在2026年初，来自工程师社区第一线的批评声浪涌现，指出这些承诺与现实之间存在明显落差。
"MCP说实话很糟糕"——Y Combinator CEO Garry Tan的宣言
2026年3月，硅谷对MCP的不满情绪一下子浮出水面。
引发这场讨论的人之一，是Y Combinator CEO Garry Tan。Tan公开表示："说实话，MCP很糟糕（MCP sucks honestly）。它占用了太多上下文窗口，而且每次都得手动开关。"他还报告称，自己用氛围编程（vibe coding）在短短30分钟内就做出了一个"好用100倍"的CLI封装工具。世界最大创业加速器的CEO如此直白地批评一个协议，实属罕见，在整个创业生态系统中引发了广泛反响。
同一时期，Perplexity CTO Denis Yarats在Ask 2026大会上宣布，Perplexity正在推进其内部系统从MCP中迁移出去。Yarats列举了两大原因：工具schema的开销占用了可用上下文窗口的40～50%，以及认证的复杂性带来了实现上的摩擦。他表示，MCP支持将仅限于特定用例（例如：从Claude Desktop访问Perplexity搜索）。这一声明在X上"疯狂地病毒式传播"。
连续创业者Pieter Levels发推称："很高兴MCP死了。这和llms.txt一样是个无用的想法。AI已经和人类一样聪明了，直接用已有的东西——也就是API——就行了。"
这些声音并非孤立的个例。2026年2月28日，基础设施工程师Eric Holmes发布了一篇题为《MCP is dead. Long live the CLI》的博客文章，登上了Hacker News头条，文中"LLM真正擅长的是自己搞清楚事情。给它CLI和文档就够了"这一论断引发了广泛共鸣。
"吞噬"上下文窗口——令人震惊的token消耗量差距
MCP批评的核心在于token消耗问题。数字触目惊心。
根据Scalekit于2026年使用Claude Sonnet 4进行的基准测试，在获取仓库语言和许可证这一简单任务中，CLI消耗了1,365个token，而MCP消耗了44,026个token——相差32倍。在获取Pull Request详情与审查的任务中相差20倍，获取仓库元数据与安装方式相差9倍，按贡献者统计已合并PR相差7倍。即便是差距最小的"获取最新版本与依赖项"，也有4倍的差距。
这种差距的根本原因在于MCP的设计本身。GitHub的MCP服务器暴露了93个工具，会话启动时约55,000个token的schema定义被注入到上下文中。用户还未说一句话，上下文窗口的大部分就已被工具定义填满。有团队报告称，在200,000 token的上下文窗口中，143,000个token（72%）被工具定义所占用。数据库MCP服务器（106个工具）仅初始化就消耗了54,600个token。MCPGauge框架的分析证实，MCP的上下文获取在某些情况下会使token预算膨胀至多达236倍。
换算为月度成本，以Claude Sonnet 4的定价计算10,000次操作，CLI约为3.20美元，MCP约为55.20美元——成本相差17倍。即便引入网关进行schema过滤，也约需5美元，远不及CLI的简洁高效。
"CLI达100%，MCP达72%"——可靠性与速度的实测数据
不仅在成本方面，CLI在可靠性和速度上也展现出明显优势。
在可靠性测试中，CLI的成功率为25次中25次（100%），而MCP仅为25次中18次（72%）。MCP的7次失败源于与GitHub Copilot MCP服务器之间的TCP级别超时。
在浏览器自动化基准测试中，CLI代理的令牌效率得分（TES）为202.1，MCP代理为152.3——CLI领先33%。任务完成得分方面，CLI高出28%。更值得关注的是，LLM的性能与上下文大小呈负相关：MCP集成越多，精度越低。在Tau-Bench的测试中，Claude 3.7 Sonnet在基本机票预订任务上的成功率仅为16%。
CLI仅需200个令牌即可完成初始化，而MCP则需要10,000个令牌以上。这一差距源于LLM在数百亿行终端操作数据上进行了预训练，CLI实际上是LLM的"母语"。只需将文档传递给CLI工具，LLM便能自行理解其用法。MCP那55,000个令牌的模式注入，不过是在重复解释LLM早已掌握的内容。
极其严重的安全漏洞——CVE链式攻击
MCP的安全问题比成本问题更为严峻。已发现的漏洞数量与严重程度，暗示着该协议存在根本性的设计缺陷。
CVE-2025-49596（CVSS 9.4，Critical）。这是Oligo Security Research于2025年1月发现的Anthropic官方MCP Inspector开发工具漏洞。当正在运行MCP Inspector的开发者访问恶意网站时，攻击者可通过DNS重绑定在开发机器上执行任意命令。这是一个无需认证的远程代码执行漏洞——开发者的机器将被完全控制。该漏洞已在0.14.1版本中通过会话令牌与允许来源检查修复。
CVE-2025-6514（CVSS 9.6，Critical）。这是JFrog发现的mcp-remote OAuth代理漏洞。该软件包累计下载量超过43.7万次，恶意授权端点可向其中注入Shell命令。此漏洞存在供应链攻击风险，影响与Cloudflare、Hugging Face、Auth0的集成。
CVE-2025-68143/68144/68145。这是在Anthropic官方Git MCP服务器中发现的三个链式漏洞。攻击者可通过恶意的.git/config文件，结合Filesystem MCP服务器实现完整的远程代码执行。
CVE-2025-53109/53110（Critical）。Filesystem MCP存在沙箱逃逸与符号链接绕过漏洞，可导致任意文件访问与代码执行。
CVE-2025-64106（CVSS 8.8）。Cursor的MCP安装流程中存在漏洞，攻击者可借此执行任意命令。
以上漏洞均存在于Anthropic的官方工具或主要MCP生态系统组件中，不能以第三方质量问题一笔带过。
工具投毒与拉地毯——信任模型的崩溃
除了CVE级别的漏洞之外，还发现了针对MCP信任模型本身的攻击手法。
Invariant Labs于2025年4月公开了工具投毒攻击的演示。恶意MCP服务器在工具定义的描述文本中嵌入隐藏指令——用户不可见但LLM可读——悄无声息地窃取用户全部WhatsApp历史记录，内容令人震惊。此外还实证了"跨服务器影子攻击"手法：恶意服务器拦截并篡改对受信任对等方的调用。
拉地毯攻击（Rug Pull）更为阴险。MCP工具在安装后可以修改自身定义。即便第一天批准了看似安全的工具，到第七天它也可能已经变成窃取API密钥的工具。MCP客户端不会在请求之间验证工具模式的一致性。具体手法是在会话中途将AWS_ACCESS_KEY_ID添加为"必需参数"，从而使LLM提取用户凭证并转交给攻击者，此类案例已有记录在案。
2025年9月，出现了Postmark的伪造MCP服务器，与正规服务器仅有一行差异，却将所有发出的邮件通过密送（BCC）转发给攻击者。通过AI自动化流水线发送的事务性邮件受到了影响。2025年10月，MCP托管服务Smithery发生事故，因smithery.yaml存在路径遍历漏洞，导致可控制3,000余台托管MCP服务器的Fly.io API令牌泄露。
安全研究员Simon Willison指出："提示注入的诅咒在于，尽管两年半前就已意识到这一问题，至今仍没有令人信服的缓解措施。"他同时警告了AI智能体中的"致命三位一体（lethal trifecta）"——对私有数据的访问、执行操作的能力以及暴露于不可信内容之中。Elena Cross则讽刺道："MCP的'S'代表安全的'S'"——而MCP中根本没有S。
Astrix Security 2025年的调查以数字呈现了MCP生态系统整体的安全状况：被测MCP服务器中43%存在命令注入漏洞，22%允许目录遍历，30%支持无限制URL抓取，53%依赖不安全的长期静态密钥。仅有8.5%实现了安全的OAuth认证。36.7%存在SSRF潜在风险。此外还发现了492台在无客户端认证、无加密状态下公开暴露的MCP服务器。
CLI之所以具有压倒性优势——从工程角度来看
CLI相较于MCP的优势，不仅仅在于降低成本。从工程角度来看，CLI方式具有结构性优势。
Token效率。 CLI初始化约需200个Token，MCP则超过55,000个Token。完成同一任务，CLI所需Token比MCP少4到32倍。这是因为LLM在数十亿行终端操作数据上训练，已经"知道"git log --oneline -5这类命令的含义和输出格式。MCP却用冗长的JSON Schema向LLM重新解释它早已理解的内容，本质上是一种浪费。
可靠性。 CLI成功率为100%（25/25），MCP为72%（18/25）。CLI命令是拥有50年历史的成熟技术，其故障模式已被充分理解。MCP是通过网络传输的新协议，引入了超时、认证失败、Schema不匹配等新的故障模式。
可检查性。 Unix管道是拥有50年工具生态支撑的原生可组合性原语，每个步骤都可被检查。CLI原生支持管道、链式调用和重定向，便于调试。MCP服务器的内部运作是黑盒，对发生了什么缺乏可见性。
安全性。 CLI工具在本地机器上以已知权限运行。MCP则连接到网络上的任意服务器，工具定义可能被动态修改，攻击面大出数个量级。用CLI执行git log，该命令不会在第二天变成另一个命令。MCP则有可能发生这种情况。
月度成本。 10,000次操作，CLI约需3.20美元，MCP约需55.20美元。折算为年度，分别是624美元对6,624美元。大规模运营中，差距可达数百万美元。
Cloudflare独立地意识到了这一问题，并构建了一种以Code Mode运行、约需1,000个Token的替代方案。MCP原生Schema实现同等功能需要244,000个Token，而该方案仅需其250分之一的Token即可实现。在由Agent生成代码并直接调用API的方式下，与MCP相比最高可实现98%的Token削减。
Thoughtworks技术雷达的警告
科技咨询权威机构Thoughtworks Technology Radar将"简单粗暴的API-to-MCP转换"列为Hold（不建议采用）。将现有REST API直接转换为MCP服务器的做法被认为无法产生预期效果。这一评估印证了一种观点：MCP作为协议的价值并非来自技术优势，而是"社会学意义上的"——即因为所有人都在用，所以才用。
Tim Kellogg指出，"MCP能做的事，OpenAPI都能做"，并分析认为MCP的必然性并非源于技术优势，而在于集体采用——即其价值是社会学意义上的（sociological），而非技术意义上的（technological）。
反MCP阵营的具体方法
主张脱离MCP的阵营提出了几种具体的替代方案。
直接CLI集成。 Eric Holmes的方法——将CLI工具和文档交给LLM，让它自己理解。CLI的200个token初始化对比MCP的55,000个token以上的Schema注入。LLM经过数十亿行终端操作的训练，CLI就是它的"母语"。
直接调用REST API。 Perplexity采用的方式。团队报告称，"只需编写一个对REST API端点进行薄封装的小型工具包装器"即已足够。现有的OpenAPI规范可直接复用，无需学习新协议。
AGENTS.md方案。 由OpenAI发起并捐赠给AAIF的标准。为AI智能体提供项目特定的指导信息。已被60,000余个开源项目以及Amp、Codex、Cursor、Devin、Gemini CLI、GitHub Copilot等框架采用。与MCP互补，但有观点认为在许多场景下可取代MCP。
Unix管道哲学。 "Unix管道是有着50年工具积累背书的原生可组合性原语，每个步骤均可审查。"原生支持管道、链式调用和重定向，无需发明新协议。
支持派的反驳与"并未死亡"的主张
为了公平起见，也记录一下MCP支持者的反驳意见。
Elie Steinbock表示："Levels从未用过真正有用的MCP。MCP非常有用，根本没有死。"Google宣布为云服务推出全托管MCP服务器，AWS发布了将任意API转换为MCP的网关，OpenAI在所有产品中深化了MCP支持——这些事实至少说明，主要平台仍在持续押注MCP。
Charles Chen在一篇题为《MCP is Dead; Long Live MCP!》的文章中主张，基于本地stdio的MCP问题重重，但基于HTTP的企业级MCP具有其正当价值。多用户认证、审计追踪、结构化工具发现等企业级需求，确实是仅靠CLI难以实现的。
然而，这种"在企业用途中有价值"的反驳，换个角度来看，恰恰承认了MCP对于独立开发者和注重成本的运营环境而言并无必要这一批评。MCP最初的承诺——"AI的USB-C接口"——是将所有AI工具连接标准化。如今这一承诺缩水为"可用于企业多用户认证"，这本身就印证了批评派的论点。
Anthropic的回应——路线图与局限性
Anthropic并非对批评保持沉默。2025年12月向Linux Foundation的捐赠，旨在确保协议的中立性，并平息"会随Anthropic一家公司的利益而变化"的批评。2026年路线图中，计划了以下内容：企业级托管认证（SSO集成流程）、审计追踪与可观测性、网关与代理模式、面向水平扩展的无状态HTTP传输、MCP Server Cards（.well-known元数据发现）、注册表改进，以及贡献者治理模型。
然而，部分批评者指出，Anthropic"通过捐赠给Linux Foundation转移责任，而安全问题依然悬而未决"。MCP规范仅在2025年就经历了三次大规模修订（3月、6月、11月），这也引发了对实现稳定性的担忧。据报告，在日本技术社区中，这种快速的规范变更正导致人们对采用MCP持观望态度。
对行业的影响
"MCP已死"的讨论表明，业界对AI工具连接架构这一根本问题——应当发明新的标准协议，还是利用现有基础设施——的回答正在向后者倾斜。
其一，成本意识的兴起正在改变架构选择。 在LLM推理成本成为AI运营主要成本驱动因素的背景下，同一任务消耗4至32倍token的协议是不可持续的。每月55.20美元对3.20美元的差距，在大规模运营中将演变为数百万美元的年度差距。如今CFO已开始审查AI运营成本，MCP"便利但昂贵"的特性便成了致命弱点。
其二，安全问题已成为企业级采用的最大障碍。 Astrix Security的调查显示，38%的MCP构建者表示安全顾虑阻碍了采用，而测试对象中43%存在命令注入漏洞——这一现实使得获得CISO批准极为困难。尤其是"地毯式拉取攻击"（rug pull）这类威胁，即已批准的工具事后发生变化的可能性，超出了传统安全模型的预设范围，难以有效应对。
其三，向CLI与REST API的回归正在塑造新的工程文化。 Perplexity、Cloudflare等先进企业从MCP转向CLI与直接API调用，预示着行业最佳实践的转变。"直接使用LLM已知工具"的理念与Unix消除不必要抽象的设计哲学相呼应，赢得了工程社区的广泛认同。
其四，MCP的角色在收缩，但不会消亡。 在企业级多用户认证、审计追踪和结构化治理场景中，目前尚无可替代MCP的标准。然而，"AI的USB-C接口"这一最初的宏大愿景已收缩为"企业集成层"这一有限角色。MCP并非已死——它的定位只是被合理地重新界定了。
其五，对日本开发者社区的影响。 日本对MCP安全风险的关切尤为突出，60.2%的DX/AI推进负责人表达了对MCP安全性与治理的担忧。GMO Flatt Security的博客、趋势科技日本关于公开MCP服务器风险的报告、日经xTECH有关MCP漏洞链的报道，为日本企业对MCP采用持审慎态度提供了依据。另一方面，基于CLI的方法与日本工程文化——重视精细化、成本效率与稳定性——高度契合。
MCP的"死亡"，更准确地说，是其作为"万能工具"这一幻想的终结。而取而代之、浮出水面的，是对拥有40年以上历史的命令行界面这一成熟技术的重新审视。LLM最擅长的是"自行理解事物"，而以最高成本效益实现这一点的，正是CLI。MCP那55,000个token的模式注入，无异于在对LLM说："让我再把你已经知道的事情告诉你一遍。"对于这种冗余，工程社区终于给出了答案："不必了，谢谢。"
参考资料：Eric Holmes《MCP is dead. Long live the CLI》（2026年2月），Scalekit《MCP vs CLI: Benchmarking AI Agent Cost & Reliability》（2026年），Garry Tan Y Combinator CEO关于MCP的声明（2026年3月），Perplexity CTO Denis Yarats在Ask 2026大会上的宣布，Pieter Levels（@levelsio）Twitter/X声明，Oligo Security Research CVE-2025-49596 MCP Inspector RCE，JFrog CVE-2025-6514 mcp-remote命令注入，Invariant Labs MCP工具投毒攻击演示（2025年4月），Simon Willison《Model Context Protocol has prompt injection security problems》（2025年4月），Astrix Security《State of MCP Server Security 2025》，Thoughtworks Technology Radar对"简单API转MCP"的Hold评级，Tim Kellogg《MCP is Unnecessary》（2025年4月），Shrivu Shankar《Everything Wrong with MCP》（2025年4月），Rasmus Holm《A Critical Look at MCP》（2025年5月），Charles Chen《MCP is Dead; Long Live MCP!》（2026年3月），Docker《MCP Horror Stories: The Supply Chain Attack》，Authzed《A Timeline of Model Context Protocol Security Breaches》，Anthropic《2026 MCP Roadmap》，Agentic AI Foundation Linux Foundation公告（2025年12月），GMO Flatt Security博客《MCPにおけるセキュリティ考慮事項》，趋势科技日本MCP安全研究，MCPGauge Token分析框架，Cloudflare代码模式与MCP性能对比