MCP 协议详解：与 Function Call 的区别及 Python SDK 使用指南

1. 什么是 MCP？

官网提供了详细的介绍文档。2025 年，Anthropic 提出了 MCP 协议，全称为 Model Context Protocol，即大模型上下文协议。它的核心目标是为 AI 大模型和外部工具之间的交互提供一个统一的处理标准。

这就好比 USB Type-C 接口统一了各种设备的连接方式，MCP 协议试图统一大模型与工具的对接方式。无论是让 AI 查询信息，还是操作本地文件，MCP 都提供了一套标准化的接口。

MCP 采用 C/S 架构，支持客户端调用远程 Server 提供的服务，同时也支持 stdio 流式传输模式，允许在客户端本地启动 MCP 服务端。只需在配置文件中新增 MCP 服务端，就能利用服务器提供的各种工具，大大提升了大模型调用外部能力的便捷性。

该协议是开源的，旨在让所有 AI 厂商和工具都能集成到自己的客户端中。只有用户基数足够大，协议才能不断演进优化。

2. 回顾 Function Call

在 MCP 普及之前，开发 AI Agent 调用外部工具时，往往需要针对不同的模型 SDK 编写适配代码。最典型的便是 OpenAI 提供的 Function Call 处理逻辑。

2.1. Function Call 实战

2.1.1. 配置工具与参数

调用 Chat Completions 接口时，通过 tools 参数传入外部工具定义。这包含了工具的描述、所需参数及其释义。其中 tool_choice 字段设为 auto 代表由大模型自动选择是否调用工具，设为 none 则强制不调用。

请求体大致如下：

{
  "tool_choice": "auto",
  "messages": [
    { "role": "system", "content": "你是一个天气查询助手" },
    { "role": "user", "content": "帮我查询上海的天气" }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取指定城市的天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": { "type": "string", "description": "城市名" }
          },
          "required": ["city"]
        }
      }
    }
  ]
}

对应的 Python SDK 代码如下，我们将工具列表放入 create 函数的 tools 参数中：

import openai
import json

def main():
    client = openai.OpenAI(
        api_key="xxxxx",
        base_url="https://api.siliconflow.cn/v1"
    )
    
    tools = [{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取指定城市的天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": { "type": "string", "description": "城市名" }
                },
                "required": ["city"]
            }
        }
    }]
    
    res = client.chat.completions.create(
        model="Qwen/Qwen2.5-32B-Instruct",
        messages=[
            { "role": "system", "content": "你是一个天气查询助手" },
            { "role": "user", "content": "帮我查询上海的天气" }
        ],
        tools=tools,
        tool_choice="auto"
    )
    print("content:", res.choices[0].message.content)
    print("tools:", res.choices[0].message.tool_calls)
    print("message:", res.choices[0].message.to_dict())

if __name__ == "__main__":
    main()

运行后，大模型会根据用户问题和提供的工具定义生成参数。此时 content 通常为空，而 tool_calls 中会包含具体的工具名称和参数字符串。

响应示例如下：

{
  "role": "assistant",
  "content": "",
  "tool_calls": [
    {
      "id": "01964be6e485603d6a2a0acbbc7eba91",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\n \"city\": \"上海\"\n}"
      }
    }
  ]
}

2.1.2. 执行工具并二次对话

拿到模型返回的参数后，我们需要在应用层实际调用函数，获取结果，然后再次与大模型对话。这一步的关键是维护对话上下文。

首先将第一次请求 AI 返回的结果插入上下文（role 为 assistant），紧接着插入工具调用的数据。格式上需要将工具的执行结果以 tool 角色发送回去：

{
  "role": "tool",
  "name": "get_weather",
  "content": "上海天气晴朗，气温 25 度"
}

这样，模型就能根据工具返回的实际数据，生成最终的自然语言回答给用户。这种流程虽然有效，但不同模型对工具调用的支持细节各异，导致 Agent 开发存在碎片化问题，这也是 MCP 协议诞生的背景之一。