MCP很好，但它不是万灵药（轻科技）

看完这篇文章，确实有点对 MCP 协议有了祛魅时刻。作为程序开发人员，AI 编程的火爆，确实降低了很多编程门槛和提升了很多开发效率，而 MCP 的出现，让 AI 的能力发挥更上一层楼 MCP 的出现就是为了解决 LLM 接口碎片化，开发低效等问题。这也正是为了解决开发者如何让 AI 应用能够与本地环境和外部工具无缝交互，而无须为每个工具单独开发接口的问题。MCP 提供了在有限资源条件下构建功能丰富 AI 应用的捷径，让我们无需在为接入工具而烦恼，更多的是专注于使用上。当然，方便是方便了，但也存在了很多歧义，也有很多人希望 MCP 能够一劳永逸的通过自动化改善 AI 系统的决策能力，或者提升任务规划的效率。说明很多人对这个 MCP 理解是有偏差的，工具与工匠是两码事。实际上没有理解 MCP 本质：一套“工具插座”的标准规范，它的使命是确保插头能顺利插入，而非决定用哪个电器、怎么使用电器。简单地说，MCP 则专注于提供统一的工具调用接口 总之，“在技术演进的长河中，我们总是倾向于寻找一劳永逸的解决方案，一种可以解决所有问题的银弹。但如同软件工程中著名的“没有银弹”论断，AI 工具调用领域同样不存在万能的解决方案。”所以，未来也一样吧

讲MCP和Function call的区别部分用一个很清晰的视角解释的很立体，我喜欢将MCP比喻成美团的那个例子。对MCP最准确的描述就是协议，但是协议本身也是一个很抽象的概念，这种具体的比喻对产生创意很有帮助。 揭露MCP的两个痛点也很spot-on，开发的不成熟对应着社会进步中的哲学问题：快是慢的先导与前提，慢不是一个应该直接追求的结果，而是在快之后，大浪淘沙剩下的沉淀；实用性不足对应着真相与假象的一些思考：它是好的-它不够好-但它也是好的。有远见的公司应该给一些敢于革命的idea一些时间，允许自己更长久的驰骋在浪上的办法是不抗拒海浪。正确认识MCP，也是正确认识技术变革与社会更替的必修课。

本书深入剖析了MCP在AI领域作为统一工具调用协议的现象级崛起，探讨了其技术架构、与Function Call的关系以及在实际应用中的表现。 通过分析MCP在本地和云端的应用差异，揭示了其在开发过程中遇到的难题和市场中的浮躁现象。 此外，书中还探讨了MCP协议的局限性，强调其在实现全面AI功能上的不足，并指出AI工具选择的重要性以及各大公司在MCP生态中的实践。 通过对MCP的理性认知，本书帮助读者理解其在AI领域的角色及其未来发展面临的挑战与机遇。

MCP解决的真实问题是什么？ 以前 AI 调工具是这样的： 每个 AI： 自己写 GitHub API 接入 自己写 Figma API 接入 自己写 Slack API 接入 结果： 100个AI × 100个工具 = 10000个对接。 MCP 的思路很工程师： 不让 AI 直接接工具，而是让工具统一实现 MCP 标准。 于是变成： AI 只学 MCP 一种协议 工具各自实现 MCP server 变成： 100 AI × 1 MCP 100 工具 × 1 MCP 复杂度瞬间下降。 【以 Figma MCP 举例说明】 底层发生的是： Claude/Codex：“我需要画图” 发现有 MCP 工具：Figma MCP server 于是： Codex → MCP → Figma MCP → Figma API → 创建图 然后返回：图 URL。 AI 不知道 API 怎么用，但 MCP 可以把 API 变成 AI 能理解的“能力描述”。

当某项科技出现狂热时，确实需要有人泼冷水，《MCP很好，但不是灵丹妙药》就是对MCP的冷静思考。 市场整合需要时间和时机，但大浪过后，总会有杂质重新冲回大海，但那些五彩斑斓的贝壳，却被留了下来。

《MCP很好，但它不是万灵药》在介绍协议本身时并没有停留在“概念”层面，而是把技术、市场与生态三条线索贯穿始终，形成了对 MCP 的立体审视。下面从三个维度梳理这一过程。 ​​一、技术底座：MCP 的设计初衷与实现路径​​ 1. ​​起源​​：MCP 最初是 Anthropic 为 Claude Desktop 定制的本地工具调用接口，目标是让 AI 助手能够统一地调用本地文件、应用与外部 API，从而“按需插件化”扩展能力。 2. ​​核心机制​​：它通过一套轻量级协议把“模型-工具-数据”解耦，客户端与服务器端依靠 SSE 长链接+HTTP 短链接的双链模型，既支持实时推送也兼顾一次性调用。但这种设计在企业级场景下带来了并发、跨机器寻址和安全管控的额外复杂度。 3. ​​适用边界​​：在本地桌面端，MCP 真正解决了“工具碎片化”痛点；到了云端，它反而增加了 round-trip 开销，与现有 RPC/无状态服务范式存在天然冲突。 ​​二、市场与生态：热度、混乱与筛选​​ 1. ​​爆发式增长​​：两个月内获 OpenAI、百度、字节、阿里等巨头背书，被视作 Agent 工具调用的“通用语言”，甚至盖过新模型发布热度。 2. ​​市场乱象​​：数千个 MCP 工具涌入，可用性低，“就像 App Store 初期的混乱”，真正能用的不足二成。 3. ​​自然选择与收敛​​：作者指出，这正是新兴生态必经的过度膨胀阶段；经历市场筛选后，只会留下真正有价值的部分——类比互联网泡沫后留下电商与社交通道。 4. ​​产业链协同​​：具体应用案例把抽象框架转成可见商业价值，触发网络效应——工具越多，AI Agent 越强大，反过来吸引更多供应商加入生态。 ​​三、案例视角：谁用得爽、谁被拖累​​ 1. ​​本地客户端受益​​：Cursor 等编辑器借助 MCP 动态加载插件，实现“开箱即用”的开发体验。 2. ​​云端服务挣扎​​：企业如果已有成熟 REST API，再做一层 MCP 适配既增维护成本又难获直接收益，因此 Adoption 动力不足。 3. ​​大厂布局​​：百度、字节、阿里分别在 C 端、工作流与支付场景中集成 MCP，试图抢占用户日常交互入口，显示协议正在成为平台竞争的新战场。 ​​四、价值与局限的综合判断​​ • ​​价值​​： – 为桌面端和小型团队提供“开箱即插”的工具集成捷径； – 促进跨厂商、跨场景的 Agent 互操作，奠定统一接口的可能； – 在动态工具发现、实时推送等场景展现独特优势。 • ​​局限​​： – 云端和大型企业因现有 API 体系、安全管控与成本顾虑，对其兴趣有限； – 协议自身仍在快速迭代（如从 SSE 迁向 streamable HTTP），生态兼容压力大； – 市场泡沫导致工具质量参差，需要时间和规范去筛选。 ​​五、理性看待“行业通用语言”​​ 作者反复强调：MCP 是“行业通用语言”的说法更多是一种营销叙事，而非事实。它在特定场景（本地、开发者工具）确实解决了痛点，但在更广阔的云端、企业服务领域，它只是众多互操作方案之一，需要与现有标准并行甚至被新的更高层框架（如 A2A）所抽象。真正的“万能钥匙”并不存在，只有对场景足够了解、对成本与收益进行权衡，才能判断是否以及如何采用 MCP。 通过技术深挖、市场观察与生态案例并行的论述，本书帮助读者在狂热与质疑之间找到理性平衡：肯定其创新价值，也看清其落地边界，这正是“很好，但不是万灵药”的题中之意。

MCP本质是一个开放协议，可以理解成“USB-C接口”，通过标准化接口解决AI模型与外部工具以及数据源的“M×N集成难题”，实现跨平台、跨模型的交互，让LLM升级为“行动执行”。它的核心价值在于统一通信规范、降低开发成本，支持即插即用与上下文持续维护，同时通过数据隔离、权限管控保障安全，对于开放AI生态构建有积极意义。 这本书的“但是”是在强调它存在明确的局限，使用前需要考虑清楚：它不具备决策与工具选择合理性验证能力，无法替代AI系统本身的智能；开放生态带来安全风险，需应对名称欺骗、代码注入等攻击；需要承担老旧系统兼容成本，开发者需掌握特定技术，且目前为止生态尚未成熟；工具增多易导致上下文膨胀，影响性能与成本控制。 在决定使使用MCP前，一定明确其“协议工具”定位，通过最小权限原则、严格输入验证、合理控制工具数量等方式规避风险，在发挥其连接价值的同时，依托人类监督与生态完善实现高效应用。

一个不错的比喻说明mcp的整个执行流程： 老板（用户）要喝咖啡，于是，在办公室（MCP Host）里，办公室主任（大模型）吩咐秘书（Agent）去买一杯美式（Function Call）。秘书（Agent）查了一下供应商名册，发现美式咖啡的供应商已接入了美团或公司统一采购系统（实现了MCP Server），接着，秘书在采购系统中找到供应商（MCP Client）一键下单。 在过去没有MCP时，大模型下发Function Call，Agent去执行翻译，直接连接到API去调用工具。因此，你得为每个API单独设置对应的调用模式，去单独定义工具列表和调用模式，这样Agent才知道怎么去翻译。而有了MCP后，只是很多API都可以直接通过供应商MCP Client一键下单了，Agent省力了。但大模型的Function Call没有任何变化。还是{tool: “买咖啡”, "type": “美式”}这个形式。

1. MCP只是一套协议，统一了大模型调用工具过程中的接口复杂性问题，如果某个工具实现了MCP协议，就可以更方便的给大模型调用 2. MCP没有决策能力，大模型才能做出决策 3. MCP由于在发展初期，市场上大多数工具的MCP服务还比较的粗糙

我有一个不成熟的见解:为什么一个协议会这么火？不过是大部分人无法从事大模型的开发，又为了赶上AI这趟浪潮，从MCP这一个容易理解又能快速开始的协议上手，也算搭上了这趟车，不过可能是在火车车顶。