你好，我是 shengjk1，多年大厂经验，努力构建 通俗易懂的、好玩的编程语言教程。 欢迎关注！你会有如下收益：
- 了解大厂经验
- 拥有和大厂相匹配的技术等
希望看什么，评论或者私信告诉我！
一、背景
最近趁有时间，搞一下 MCP，前面我们已经再为更进一步的 MCP 打下了基础
接下来我们一起了解一下，为什么 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设计质量、需防范格式解析错误、工具安全性依赖服务器实现等挑战。
