问题：Function Calling 定义的函数过多是否会导致模型上下文爆炸？
函数定义本身会计入模型上下文。OpenAI 在官方说明中明确写道：“functions 会被注入到 system message 中，因此它们会占用上下文并按输入 token 计费；如果遇到上下文极限，应当减少函数数量或精简参数描述。”
只要所有输入 token（系统提示 + 函数列表 + 对话历史 + 用户提问）之和没有超过所选模型的最大上下文窗口，就不会触发 context_length_exceeded 错误；反之就会报错。
真正会爆的是：
（1）函数描述写得尤为冗长（例：将完整 OpenAPI schema 逐字段贴进去）；问题：不同模型 Function Calling 实现不一样，难以兼容？（1）不同模型在处理 Function Calling 的方式不同，tool use 是 decoding 分支（GPT）还是 prompt convention（Claude）；（2）各模型对 system prompt 指令和格式标准各异。MCP 对大模型 Function Calling 的意义
（1）传统 Function Calling 难以支持「规模化、多任务、跨模态、多工具、实时变化」的智能体（Agent）系统；（3）MCP 不仅仅包括 Function Calling 的能力，提供了“按需加载 + 分层调用 + 本地缓存”机制，统一多种资源接入与调用能力，解决跨模型兼容性问题，并为 Agent 系统智能化提供基础设施；（4）模型依旧需要“看见”工具接口，若完全没描述，LLM 无法生成正确参数。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），这样工具的元数据可以在“模型外”维护，而不是每轮对话都放进上下文。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
