MCP 与 Function Calling 的关系与区别

问题：Function Calling 定义的函数过多是否会导致模型上下文爆炸？

函数定义本身会计入模型上下文。OpenAI 在官方说明中明确写道：“functions 会被注入到 system message 中，因此它们会占用上下文并按输入 token 计费；如果遇到上下文极限，应当减少函数数量或精简参数描述。”

只要所有输入 token（系统提示 + 函数列表 + 对话历史 + 用户提问）之和没有超过所选模型的最大上下文窗口，就不会触发context_length_exceeded错误；反之就会报错。

真正会爆的是：

（1）函数描述写得尤为冗长（例：将完整 OpenAPI schema 逐字段贴进去）；

（2）对话历史很长且未做截断；

（3）一次性把所有函数都塞给中小窗口模型。

问题：不同模型 Function Calling 实现不一样，难以兼容？

（1）不同模型在处理 Function Calling 的方式不同，tool use 是 decoding 分支（GPT）还是 prompt convention（Claude）；

（2）各模型对 system prompt 指令和格式标准各异。

MCP 对大模型 Function Calling 的意义

首先说结论：

（1）传统 Function Calling 难以支持「规模化、多任务、跨模态、多工具、实时变化」的智能体（Agent）系统；

（2）MCP 没有直接提升模型上下文长度；

（3）MCP 不仅仅包括 Function Calling 的能力，提供了“按需加载 + 分层调用 + 本地缓存”机制，统一多种资源接入与调用能力，解决跨模型兼容性问题，并为 Agent 系统智能化提供基础设施；

（4）模型依旧需要“看见”工具接口，若完全没描述，LLM 无法生成正确参数。

MCP 初始化流程

MCP 的客户端与服务端在建立连接时，服务端会将支持的能力返回给客户端，并保存在客户端本地。同时，在服务端能力更新时，可以动态对客户端本地的缓存进行更新。

用户交互时序图

相较于 Function Calling 在 LLM 首轮对话时，AI 应用将 Functions description 以prompt的形式全部输入给 LLM，MCP 在与 LLM 交互时，把函数详细描述与参数定义移出首轮 prompt，能有效减少 LLM 的上下文 token 消耗，并优化处理速度。

按需加载

那么在时候客户端将工具具体的 JSON Schema 给到 LLM 呢？

在 LLM 首轮交互时，客户端只将“user query + system message（default prompt & history context & capabilities）”传入，由LLM 判断是否需要调用工具或访问资源。只有当需要调用工具或访问资源时，客户端才会再将“具体的 tool 或 resource 的 JSON Schema 传入给LLM，让 LLM 生成 tool 或 resource 的参数。

分层调用

MCP 通过客户端与服务端的职责分离，为“执行层”提供了统一的 JSON-RPC 规范，支持动态列举与调用工具（tools/list→tools/call），这样工具的元数据可以在“模型外”维护，而不是每轮对话都放进上下文。