详解模型上下文协议MCP（二）MCP能否撼动甚至颠覆Function Call的地位？目前跟“MCP”类似的大模型协议有哪些？

本文链接：https://blog.youkuaiyun.com/star_nwe/article/details/147162458

三、MCP能否撼动甚至颠覆Function Call的地位？

先说结论，颠覆不好说，但会把“Function Call们”卷起来。

Function Call本质上是某些大模型（如 GPT-4）提供的专有能力，允许 AI 通过结构化请求调用外部工具（例如查询天气、执行计算）。宿主应用收到请求后执行操作并返回结果。其核心是模型厂商内部的功能扩展接口，无统一标准，实现依赖特定厂商。

MCP 的核心优势在于统一了各家大模型原本差异化的 Function Calling 标准，形成通用协议。它不仅支持 Claude，还能兼容市面上几乎所有主流大模型，堪称 AI 领域的“USB-C 接口”。基于标准化通信规范（如 JSON-RPC 2.0），MCP 解决了模型与外部工具、数据源间的兼容性问题，开发者只需按协议开发一次接口，即可被多模型调用。

也是由于两者都能实现与外部数据的联动，MCP在刚问世时，开发者常纠结“它是Function Call的简化版，还是AI交互的HTTP标准？”但随着生态发展，MCP相比Function Call的开放性优势逐渐被认知的更加清晰：

Function Call的“私有协议困局”，类似手机厂商的私有快充协议，主流AI厂商各自定义封闭的调用协议（JSON Schema、Protobuf等），导致开发者为不同平台重复开发适配逻辑。切换AI服务商时，工具调用体系需“推倒重来”，跨平台成本高企，拖慢AI能力的规模化落地。

MCP通过统一通信规范和资源定义标准，MCP让开发者“一次开发，全平台通用”——同一工具可无缝适配GPT、Claude等不同模型。这如同AI世界的“书同文、车同轨”，终结“重复造轮子”的窘境。

但Function Call仍是高频轻量任务的“王者”：它像模型的“贴身助手”，也是 MCP 协议链接各方的基础，运行时直接调用（如快速计算、简单查询），响应极快。

而MCP则擅长“复杂任务外包”：模型像“指挥官”下达需求（如抓取网页），MCP Server作为“快递员”按需响应，通过HTTP/SSE协议“送货上门”，全程无需开发者手动干预。

可以预见的是，MCP短期内不会颠覆Function Call，但会倒逼其进化。当模型自带工具的丰富度追上MCP，开发者还需要费力搭建专用Server吗？答案或许是不一定。但至少，MCP的出现让Function Call们不得不“卷”起来——推动工具调用更标准化、更便捷。

Function Call是AI的“即时小助手”，MCP是“按需响应的快递员”——两者更好的模式是协同发展。

Function Call代表“代码控”思维：开发者需精细控制工具细节；而MCP转向“意图派”模式：开发者只需定义能力边界，具体执行由大模型动态决策。两者并存，让开发者既能享受高频任务的高效，又能解锁复杂场景的灵活性。

四、目前跟“MCP”类似的大模型协议有哪些？MCP离成为“事实标准”还有多远？

都说MCP像当年的HTTP协议，其实上一个和MCP这么像的还是LSP——语言服务器协议。

在2016年LSP发布之前，开发工具生态可以用“各自为政”来形容。

在传统开发范式下，集成开发环境（IDE）与主流代码编辑器（如VSCode、Sublime、VIM等）必须为Java、Python、C++等不同编程语言重复开发语法解析、代码补全、调试支持等核心功能，这不仅造成巨大的资源浪费，更导致开发者体验的割裂。

而LSP的革命性突破，在于创建了编辑器前端与语言后端解耦的标准化通信架构——通过定义JSON-RPC规范下的跨进程交互协议，使得语言智能服务能够以可插拔的方式适配任意编辑器，听着是不是和MCP异曲同工？

可以说，MCP的设计灵感很大程度上来源于LSP，两者的理念非常相似，都将M*N的难题简化成了All in One。

LSP毕竟是解决编程语言和编程环境交互的，除此之外与MCP类似的技术协议大致可分为两类，各自代表不同技术路径，但对比MCP都呈现一定的劣势。

传统API规范派系

OpenAPI/Swagger：通用API描述标准，需开发者手动定义接口与逻辑，缺乏AI原生设计。
GraphQL：灵活的数据查询协议，但需预定义Schema，动态上下文扩展能力不足。
企业私有协议：如OpenAI Plugins、Google Vertex AI工具链，封闭性强，生态割裂。

AI专用框架派系

LangChain工具库：提供500多个工具集成，但依赖开发者编码适配，维护成本高。
Zapier式低代码平台：通过可视化流程连接工具，但功能深度受限，难以满足复杂场景。

从这里面找一个潜在对手，OpenAPI似乎能掰掰手腕。

但事实上， OpenAPI作为API定义的事实标准，为MCP提供了基础架构而非竞争关系。

在API 管理公司CEO Speakeasy Batchu看来：“从OpenAPI规范到MCP的跨越非常小——前者本质上是MCP所需信息的超集，我们只需将其与LLM专用参数（如语义描述、调用示例）封装为实时服务。”

这种设计差异揭示了二者本质区别：OpenAPI是静态接口说明书，而MPC是动态执行引擎。

当AI代理通过MCP服务器发起请求时，其实时交互能力可动态适配上下文变化，例如自动补全参数缺失的API调用，这种“活的规范”特性解决了传统集成中模型无法理解API架构信息的致命缺陷。

前文的提到的“标准之辩”也深入探讨了各种可能性。

正方的观点主张：「MCP 的核心价值在于：让用户为不可控的 Agent 添加工具。例如在使用 Claude Desktop、Cursor 等应用时，普通用户无法修改底层 Agent 的代码，但通过 MCP 协议就能为其扩展新工具。」
核心的技术支撑是：MCP提供标准化的工具描述框架、支持通过提示词 (prompt) 引导工具调用，以及基础模型的工具调用能力本身也在持续进化
反方认为，「现有模型在专为特定工具集优化的 Agent 中，工具调用正确率仅 50%。若强行通过 MCP 注入新工具，效果恐更不理想。」

一些现实的挑战是：