为什么MCP可以适配不同LLM

你好，我是 shengjk1，多年大厂经验，努力构建 通俗易懂的、好玩的编程语言教程。 欢迎关注！你会有如下收益：

1. 了解大厂经验
2. 拥有和大厂相匹配的技术等

希望看什么，评论或者私信告诉我！

一、背景

最近趁有时间，搞一下 MCP，前面我们已经再为更进一步的 MCP 打下了基础
一文搞定 Python 装饰器
Web架构全解析：8种类型优缺点及场景
解锁 MCP 中的 JSON-RPC

接下来我们一起了解一下，为什么 MCP 协议可以兼容各种 LLM，即使 LLM 不支持 Function Call

二、兼容各种 LLM 的原因

MCP（Model Context Protocol）通过协议分层与客户端适配机制，实现了对各类LLM（无论是否原生支持Function Call）的兼容性支持，其核心设计逻辑可分为以下三个层面：

2.1 协议分层解耦：工具调用与模型决策的分离

MCP将工具调用拆解为两个独立环节：
1. 工具描述标准化

MCP服务器统一管理工具元数据（名称、参数、描述），并通过协议向客户端暴露标准化的工具列表。

2. 客户端适配层

MCP客户端根据LLM能力差异，动态调整工具描述的呈现形式：

• 支持Function Call的LLM：直接传递工具JSON Schema，利用原生能力生成结构化调用指令。

• 不支持Function Call的LLM：将工具信息转换为自然语言描述，通过System Prompt强制引导LLM输出预定义格式（如XML/JSON）的调用指令。

例如，Cline插件通过近千行的系统提示词，明确要求LLM以XML格式输出工具调用指令（如 <read_file path=“…” />），并通过正则表达式解析响应。

2.2、执行层统一接管：屏蔽模型差异

MCP通过以下机制确保工具调用与LLM无关：

• 格式校验与参数解析

  客户端内置解析器，对LLM的原始输出进行格式校验（如检查XML标签闭合），并提取参数值。

• 服务化执行接口

  解析后的工具调用请求通过MCP协议发送至对应服务器执行，实际调用过程由服务器完成，与LLM无关。

这种设计使得LLM只需生成符合格式的指令文本，无需关注底层工具如何执行，实现了"生成即调用"的无缝衔接。

2.3、动态协商与扩展能力

MCP协议支持能力协商机制（Capability Negotiation）：

• 客户端声明支持格式：如纯文本/JSON/XML响应解析能力。

• 服务器动态适配输出：根据客户端能力返回最佳工具描述形式。

这种灵活性允许开发者针对不同LLM特性定制适配策略，例如为低能力模型提供更简化的Prompt模板。

2.4 实际案例：非Function Call模型的支持流程

以调用"天气查询工具"为例：

• 提示词引导

  System Prompt中明确告知：“你可以使用以下工具：1. 天气查询（参数：城市）…请用格式调用”。

• 响应解析

  客户端捕获类似的文本片段，提取参数并转发至天气服务MCP服务器。

• 结果反馈

  服务器返回数据后，客户端将结果插入对话上下文，供LLM生成最终回答。

三、MCP 优势与挑战

• 优势：降低LLM集成门槛、避免重复开发工具调用逻辑、促进工具生态标准化。

• 挑战：依赖Prompt设计质量、需防范格式解析错误、工具安全性依赖服务器实现。

通过这种分层架构，MCP成功将工具调用的复杂性从模型侧转移至协议层，成为连接LLM与外部世界的"万能适配器"。

四、总结

MCP通过协议分层与客户端适配机制，实现了对各类LLM的兼容性支持。其核心设计包括工具描述标准化、客户端适配层、格式校验与参数解析、服务化执行接口以及动态协商能力。MCP的优势在于降低LLM集成门槛、避免重复开发工具调用逻辑、促进工具生态标准化。然而，MCP也面临依赖Prompt设计质量、需防范格式解析错误、工具安全性依赖服务器实现等挑战。