深入理解 MCP 协议：与 Function Call 的差异及实战用法

对应的 Python SDK 代码如下。我们将工具列表放入 create 函数的 tools 参数中，并设置 tool_choice 为 auto。这里以 Qwen2.5 模型为例，实际运行时请替换正确的 API Key。

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 中。

❯ uv run main.py
content: 
tools: [ChatCompletionMessageToolCall(id='...', function=Function(arguments='{"city": "上海"}', name='get_weather'), type='function')]

2. 调用工具与上下文维护

拿到模型返回的参数后，我们需要执行函数并将结果回传给模型，以便进行二次处理。这一步的关键在于维护对话上下文。

首先保留第一次请求的 Assistant 回复，然后插入一条 tool 角色的消息，格式如下：

{
  "role": "tool",
  "tool_call_id": "01964be6e485603d6a2a0acbbc7eba91",
  "content": "{\"temperature\": \"25°C\", \"city\": \"上海\"}"
}

将这条数据追加到 messages 列表中再次发送给模型，模型就能结合工具返回的实际数据给出最终回答。

小结

Function Call 解决了大模型调用工具的基本问题，但在多模型适配和标准化上仍有局限。MCP 协议正是为了统一这一交互标准而生，它试图像 USB-C 一样，让不同的大模型和工具之间能够'即插即用'。后续我们会进一步探讨 MCP 的具体实现细节。