MCP 协议详解：与 Function Call 的区别及使用方法

1. 什么是 MCP？

Anthropic 提出了 MCP 协议。MCP 全称为 Model Context Protocol，翻译过来是大模型上下文协议。这个协议的主要为AI 大模型和外部工具（比如让 AI 去查询信息，或者让 AI 操作本地文件）之间的交互提供了一个统一的处理协议。我们常用的 USB TypeC 接口（USB-C）统一了 USB 接口的样式，MCP 协议就好比 AI 大模型中的 USB-C，统一了大模型与工具的对接方式。

MCP 协议采用了 C/S 架构，也就是服务端、客户端架构，能支持在客户端设备上调用远程 Server 提供的服务，同时也支持 stdio 流式传输模式，也就是在客户端本地启动 mcp 服务端。只需要在配置文件中新增 MCP 服务端，就能用上这个 MCP 服务器提供的各种工具，大大提高了大模型使用外部工具的便捷性。

MCP 是开源协议，能让所有 AI 厂商、AI 工具都将 MCP 集成到自己的客户端中，从而扩大 MCP 的可用面。毕竟只有用的人越多，协议才能不断发展，不断变得更好。

2. 了解 function call

在 MCP 没有出来之前，我们的 AI Agent 开发如果想调用外部工具需要针对不同的 AI 大模型 SDK 编写不同的代码，其中最为常用的是 openai 提供的 function call 的处理逻辑。

2.1. function call demo

2.1.1. 配置工具，AI 提供参数

当我们调用 OpenAI Chat Completions 接口时，可以通过 tools 参数传入可供使用的外部工具。这个工具的调用中就包含了工具的作用，工具需要传入的参数，以及参数的释义。其中 tool_choice 字段设置为 auto 代表让大模型自动选择 tools，设置为 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 openai 代码如下，我们将 tools 部分放入一个包含 dict 的 list，作为 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()

运行程序，发出请求后，大模型就会根据用户提出的问题和提供的 tools，来为这个 tools 编写需要提供的参数。此时 content 会是空，不会输出内容，tool_calls 中会包含调用的工具和参数。

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

对应如下 json 格式响应，包含了我们的参数

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

2.1.2. 调用工具并让 AI 二次处理

随后，我们就可以根据这个大模型返回的参数来调用我们的函数，并得到函数的返回结果，再次与大模型进行对话。此时需要按下面的方式维护对话上下文，首先需要将第一次请求 AI 返回的结果插入到上下文中（"role": "assistant"的 json 字符串），然后再插入工具调用的数据，格式如下：

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

完成上述步骤后，大模型会根据工具返回的结果生成最终回答。MCP 协议在此基础上进一步标准化了工具调用的握手过程，使得不同厂商的工具能够无缝接入大模型生态，解决了 Function Call 在不同模型间适配困难的问题。

3. MCP 与 Function Call 的核心区别

1. 标准化程度：Function Call 通常依赖特定模型的 API 实现，不同模型间格式差异较大；MCP 提供了统一的协议标准，屏蔽底层差异。
2. 扩展性：MCP 支持 C/S 架构和 stdio 模式，允许本地或远程灵活部署工具服务；Function Call 多局限于模型侧的同步调用。
3. 生态整合：MCP 旨在成为 AI 领域的通用接口标准，类似 USB-C，便于第三方工具快速接入；Function Call 更多是单一模型的功能特性。