Function Call 解决了"LLM如何对外部世界的调用"的问题.

MCP 要解决的是"系统如何统一、安全、标准化地执行这些调用"的问题。

一、MCP为何而生？

Function Call 技术能让 LLM 调用外部工具，但在实际工程落地中，仍面临以下根本性挑战：

1. 集成碎片化：N×M 的复杂适配

Function Call 让模型能"调用"，但没规定"如何连接"。

• 场景：假设你有 3 个 AI 应用（ChatBot、IDE插件、数据分析助手），想连接 5 个数据源（GitHub、Slack、PostgreSQL、本地文件、企业API）。
• 问题：每个应用都需要为每个数据源单独编写适配代码：解析模型输出→调用对应API→处理返回结果→格式化回传。理论上需要维护 3×5=15 套集成逻辑。
• 后果：开发成本高、维护困难、每次模型API或数据源接口更新都需重新适配。

2. 上下文管理单一：只有"执行"，缺乏"读取"

Function Call 核心关注"调用函数执行动作"，但智能代理同样需要高效"读取信息"。

• 局限：想让用户问"帮我总结昨天会议记录"，你需要：① 写一个"读取文件"的 Function；② 让模型先调用它读取内容；③ 再调用"总结"函数。流程冗长且易出错。
• 缺失：缺乏对"静态资源按需加载"的标准化支持，导致开发者用 Function Call 模拟"读操作"，既浪费Token又增加延迟。

3. 模型厂商锁定：工具生态难以复用

不同模型厂商的 Function Call 实现细节各异（OpenAI Tools、Anthropic Tool Use、Google Function Calling）。

• 困境：工具开发者若想支持多模型，需为每家厂商编写适配层；应用开发者若想切换模型，需重新调整工具描述格式。
• 结果：工具生态被模型厂商割裂，阻碍了"一次开发，处处运行"的理想。

💡 MCP 的使命：在 Function Call 之上，构建一层标准化的连接协议，让工具开发与应用开发解耦，让模型进化与工具生态解耦，让 AI 应用能像"插USB设备"一样便捷、安全地连接外部世界。

二、MCP的核心思想

目标：为 LLM 与外部系统的交互建立统一通信标准

• 工具开发者：只需实现一次 MCP Server，即可被所有 MCP Client 复用
• 应用开发者：只需集成 MCP Client，即可访问所有 MCP 兼容工具/数据源
• 模型厂商：只需支持 Function Call 机制，即可通过 MCP 接入丰富生态

本质：协议规范

MCP 不是新的模型能力，而是一套协议规范，标准化以下全流程： [能力发现] → [上下文注入] → [意图决策] → [协议传输] → [安全执行] → [结果回传] 三大核心组件（承接并扩展 Function Call）

核心差异

Function Call 流程中，"工具定义→调用→执行"由应用层自定义； MCP 流程中，这三步通过标准协议解耦，应用层只需关注业务编排。

三、MCP的技术实现

MCP 基于 JSON-RPC 2.0 构建通信协议，支持 STDIO（本地进程）、SSE/HTTP（远程服务）等多种传输层。以下以"天气查询"为例，对比展示 MCP 如何实现 Function Call 的标准化落地。

信息交互流程图

流程详细拆解

一、MCP Server 能力声明（对应 Function Call 的"函数信息准备"）

1. 定义 Tool（与 Function Call 类似，但格式标准化）

{
  "name": "get_current_weather",
  "description": "获取指定城市的当前天气信息",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "城市名称，例如'北京市'或'Shanghai'"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "温度单位"
      }
    },
    "required": ["location"]
  }
}

2. 定义 Resource（MCP 新增能力，Function Call 无直接对应）

{
  "uri": "weather://forecast/shanghai",
  "name": "上海天气预报",
  "description": "上海地区的7天天气预测数据",
  "mimeType": "application/json",
  "read": {
    "description": "读取该资源将返回JSON格式的天气预测"
  }
}

区别：Function Call 中，"读取文件"需伪装成函数调用；MCP 中，Resources 原生支持"按需加载"，模型可直接请求weather://forecast/shanghai获取数据，无需执行逻辑。

二、MCP Client 发现与注册（Function Call 中由应用层手动完成）

1. 【MCP Client】启动时与【MCP Server】建立连接
2. 【MCP Server】响应 initialize 请求，返回服务器信息和能力列表
3. 【MCP Client】调用 tools/list 接口，获取所有可用工具的定义
4. 【MCP Client】将 MCP 格式的工具描述自动转换为 LLM 可识别的格式（如 OpenAI tools 格式），注入 System Prompt

{
  "type": "function",
  "function": {
    "name": "get_current_weather",
    "description": "获取指定城市的当前天气信息",
    "parameters": { /* ... */ }
  }
}

价值：开发者无需为不同模型手动转换工具描述，MCP Client 自动完成适配。

三、LLM 决策与 Function Call 生成（与 Function Call 一致）

1. 用户提问："明天上海的天气怎么样？"
2. 【应用程序】将问题发送给【LLM】，携带已注入的 MCP 工具描述
3. 【LLM】分析意图，决定调用 get_current_weather 工具，生成结构化 Function Call：

{
  "name": "get_current_weather",
  "arguments": {
    "location": "上海市"
  }
}

注意：此步骤与 Function Call 完全一致，MCP 不改变模型的决策逻辑，只标准化后续的传输与执行。

四、MCP 协议传输与执行（Function Call 中由应用层自定义）

1. 【MCP Client】捕获 LLM 返回的 Function Call，将其封装为 MCP 协议消息：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_current_weather",
    "arguments": {
      "location": "上海市"
    }
  }
}

2. 【MCP Client】通过传输层（如 STDIO）将消息发送给【MCP Server】
3. 【MCP Server】解析请求，执行实际的天气 API 调用（业务逻辑开发者实现）
4. 【MCP Server】将执行结果封装为 MCP 标准响应 返回：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{
      "type": "text",
      "text": "{\"location\": \"上海市\", \"temperature\": 22, \"unit\": \"celsius\", \"forecast\": \"晴\"}"
    }],
    "isError": false
  }
}

MCP优势：无论底层调用的是 OpenWeatherMap、和风天气还是自建API，MCP Client 收到的响应格式完全一致，应用层无需关心数据源差异。

五、结果回传与最终回复（与 Function Call 一致）

1. 【MCP Client】解析 MCP 响应，提取工具执行结果
2. 【应用程序】将结果作为 tool 消息追加到对话历史，发起第二轮 LLM 请求
3. 【LLM】结合执行结果生成自然语言回复："上海明天的天气为晴天，气温22摄氏度..."
4. 【应用程序】将回复展示给用户

// 第二轮请求示例（与 Function Call 流程一致）
{
  "messages": [
    { "role": "user", "content": "明天上海的天气怎么样？" },
    {
      "role": "assistant",
      "tool_calls": [{ "id": "call_123", "function": { "name": "get_current_weather", "arguments": "{\"location\":\"上海市\"}" } }]
    },
    {
      "role": "tool",
      "content": "{\"location\": \"上海市\", \"temperature\": 22, \"forecast\": \"晴\"}",
      "tool_call_id": "call_123"
    }
  ]
}

总结：MCP 与 Function Call 的关系梳理

Function Call 是 LLM 的"手"，让它能发出调用指令；MCP 是"USB-C 接口"，让这只手能即插即用地连接任何符合标准的外部设备。

对于开发者：Function Call 是你调用模型时的 API 参数，MCP 是你构建后端工具服务时遵循的架构规范。两者结合，才能构建出真正可扩展、安全、企业级的 AI 应用。