既生function calling何生MCP？一文全方位了解MCP

了解MCP之前，我们先来回顾一下AI Agent，需要具备什么样的能力，达到什么样的智能程度，才可以称为一个Agent。

AI Agent 是能主动解决问题的智能程序，核心在于 感知→决策→行动→学习 的闭环。未来它会像水电一样渗透到所有数字场景中，成为每个人的“智能伙伴”。

上图可简单划分为 Agent = LLM + 规划技能 + 记忆 + 工具使用，其中 LLM 扮演了 Agent 的“大脑”，在这个 系统中提供推理、规划等能力。过多关于AI Agent概念就不过多介绍，读者可以关注公众号之前的文章。

MCP来源

2024年11月底 Anthropic（Claude提供商）提出了MCP协议，并在Claude 客户端支持了MCP。

MCP协议，全称为“Model Context Protocol”，提供了一种将LLM连接到不同数据源（resource）和工具（tool）的标准化方法，旨在统一大模型与外部数据源和工具之间的沟通通信协议。

MCP 大概的工作方式：MCP Host，比如 Claude Desktop、Cursor 这些工具，在内部实现了 MCP Client，然后MCP Client 通过标准的 MCP 协议和 MCP Server 进行交互，由各种三方开发者提供的 MCP Server 负责实现各种和三方资源交互的逻辑，比如访问数据库、浏览器、本地文件，最终再通过 标准的 MCP 协议返回给 MCP Client，最终在 MCP Host 上展示。

MCP 的核心架构

MCP 采用客户端-服务端架构，以下是 MCP 官方展示的架构：

• MCP Client（客户端）：作为调用方，是用户与 MCP 生态的交互入口。例如，聊天应用类，提供自然语言交互服务，让用户通过对话调用 AI 能力；编码工具类，在 IDE 里调用外部应用和系统的能力；任务自动化类，帮用户自动化执行重复性任务，如数据处理、流程调度，以提升效率。
• MCP Server（服务端）：作为被调用方，提供后端服务支撑，包含各类核心功能模块。例如，数据库类（如 ClickHouse、Supabase）负责数据存储、查询与管理；设计类（如 Figma、Blender）支撑设计创作、文件协作等功能；生产力工具类（如 Notion、Obsidian）提供笔记管理、知识整理等办公协作服务；支付类（如 Stripe），处理在线支付交易，支持商业场景的资金流转。
• Local MCP Server（本地数据源）：MCP 服务器可以安全访问本地计算机上的文件、数据库和服务。
• Remote MCP Server（远程服务源）：MCP 服务器可以通过互联网（例如通过 API）连接到外部系统。

MCP的Server一般由各大厂商按照规范提供，这样不同的MCP Client可以进行调用，这里列举一些MCP服务：

• GitHub MCP Server：该server能够深度整合 GitHub API，实现文件操作、仓库管理、搜索等功能，从而支持代码仓库的自动化管理。
• Google Drive MCP Server：允许用户浏览、读取和搜索 Google Drive 上的文件，并支持自动转换多种文件格式。
• Fetch MCP Server：支持抓取网页内容，并能将 HTML 自动转换为易读的 Markdown 格式，便于内容整理与分享。
• @amap/amap-maps ：高德地图是一个支持任何MCP协议客户端的服务器，允许用户轻松利用高德地图MCP服务器获取各种基于位置的服务。

由于MCP Server比较多，国内国外的都有，这里就不一一列举，可以访问如下链接自行查看：

• 国外Github汇总MCP:https://github.com/modelcontextprotocol/servers
• 国内魔塔社区汇总MCP:https://modelscope.cn/mcp

MCP的工作机制

如上图所示，一次基于MCP的调用，一共有6个核心的步骤，假设我们的需求是：

• 我要开发一个获取时间的AI Agent，用户在使用这个AI Agent时，只需要问类似“现在几点了？”这种问题即可。
• 我已经有了一个关于处理时间的MCP Server，这个MCP Server里有2个MCP Tool，一个负责获取当前时区，一个负责获取当前时间。

调用步骤解析：

• 第一步：用户向AI Agent提问“现在几点了？”，此时AI Agent就是MCP Client，它会把用户的问题和处理时间的MCP Server以及MCP Tool的信息一起发送给LLM。

• 第二步：LLM拿到信息后开始推理，基于用户的问题和MCP Server的信息，选出解决用户问题最合适的MCP Server和MCP Tool，然后返回给AI Agent（MCP Client）。

• LLM返回给AI Agent的信息是：“你可以使用time这个MCP Server里的get_current_time这个MCP Tool，它可以解决用户的问题”。

• 第三步：AI Agent（MCP Client）现在知道应该使用哪个MCP Server里的哪个MCP Tool了，直接调用该MCP Tool，获取结果。

• 调用名称为time的MCP Server里的get_current_time MCP Tool。

• 第四步：Time MCP Server返回结果（当前的时间）给AI Agent（MCP Client）。

• 第五步：AI Agent（MCP Client）把用户的问题和从Time MCP Server处拿到的结果再一次给了LLM，目的是让LLM结合问题和答案再规整一下内容。

• 第六步：LLM把整理后的内容返回给AI Agent（MCP Client），最后AI Agent（MCP Client）再原封不动地返回给用户。

在MCP的整个调用过程中有一个非常关键之处就是MCP Server 以及 MCP Tool 的信息。从第一步、第二步可以看出，这个信息非常关键，是它让LLM知道了该如何解决用户的问题，这个信息就是MCP中最重要的System Prompt，本质上就是优化提示词。

在MCP出现之前，如果要让大模型调用外部服务，需要获取各个外部服务的API的描述信息，如入参说明, 使用场景等，把用户的原始问题和工具的描述信息拼接成Prompt，发送给大模型。

没有MCP的场景

用户想查询北京飞往上海的航班信息和天气情况，传统做法需要以下步骤：

1. 开发者需要先获取两个外部API的文档： 航班查询API：

{
  "name": "flight_search",
  "description": "查询航班信息",
  "parameters": {
    "departure_city": "出发城市",
    "arrival_city": "到达城市", 
    "date": "出发日期（YYYY-MM-DD）"
  }
}

天气查询API：

{
  "name": "weather_query",
  "description": "查询城市天气",
  "parameters": {
    "city": "城市名称",
    "date": "查询日期（YYYY-MM-DD）"
  }
}

1. 拼接Prompt，需要把用户问题和API文档信息一起发送给大模型：

用户问题：帮我查下明天北京飞上海的航班，还有上海的天气

可用工具：
1. flight_search：查询航班信息
   参数：
   - departure_city：出发城市
   - arrival_city：到达城市
   - date：出发日期（YYYY-MM-DD）

2. weather_query：查询城市天气
   参数：
   - city：城市名称
   - date：查询日期（YYYY-MM-DD）

请分析用户需求，选择需要调用的工具，并输出符合工具要求的参数JSON。

3.大模型输出大模型输出，模型会返回类似这样的结构化请求：

{
  "flight_search": {
    "departure_city": "北京",
    "arrival_city": "上海",
    "date": "2023-11-20"
  },
  "weather_query": {
    "city": "上海",
    "date": "2023-11-20"
  }
}

4.开发者处理，需要写代码将这个JSON分别发送给对应的API，然后再把结果整合后返回给用户。

这种方式的痛点：

• 每个新工具接入都要手动编写描述文档。
• 需要处理复杂的prompt工程。
• 参数转换和结果整合需要大量定制代码，无法复用。
• 不同模型的prompt格式可能不兼容。

有了MCP后:

• AI Agent与工具（Tools）解耦，工具有了标准化的实现，解决了工具无法复用的问题。
• 统一的function calling标准，不同AI模型之间的无缝切换和无缝协作，减少对LLM平台的依赖。

解决天气查询问题

为了解决上面查询航班和天气的问题，我们直接搜索对对应的使用MCP工具，如下：

将MCP服务集成到自己的大模型应用开发平台，或者是自己的AI Agent应用中，只需将一些配置参数，大模型即可自行调用对应的MCP工具来获取结果，就不需要自行拼接prompt，组装数据，如下是集成对应的MCP服务：

{
    "mcpServers": {
        "variflight": {
            "command": "npx",
            "args": [
                "-y",
                "@variflight-ai/variflight-mcp"
            ],
            "env": {
                "VARIFLIGHT_API_KEY": "your_api_key_here"
            }
        }
    }
}

然后再自己的大模型应用或者Agent中配置调用即可，大模型会根据你的输入和工具的描述，智能调用工具，如下图所示：

如图所示，左边的提示词并没有指定调用天气查询的接口，或者是指定调用的具体方法和参数，根据天气MCP的配置，大模型会自动调用对应的MCP工具，返回正确的结果，这就是MCP比function calling的优势之处。

支付场景

以下是一个虚构的简化使用场景，用于方便理解工具能力：

1. 一位插画师希望通过提供定制的原创插画服务谋取收入。传统方式下，他/她需要和每位客户反复沟通需求、确定价格，并发送支付链接，然后再人工确认支付情况，这个过程繁琐且费时。
2. 现在，插画师利用支付宝 MCP Server 与智能 Agent 工具，通过 Agent 搭建平台，开发了一个智能聊天应用（网页或小程序）。客户只需在应用中描述自己的绘画需求（如风格偏好、插画用途、交付时间等），AI 就会自动分析需求，快速生成准确且合理的定制报价，并通过工具即时创建出专用的支付宝支付链接。
3. 客户点击并支付后，创作者立即收到通知，进入创作环节。无需人工往返对话确认交易状态或支付情况，整个流程不仅便捷顺畅，还能显著提高交易效率和客户满意度，让插画师更专注于自己的创作本身，实现更轻松的个性化服务商业模式。

例如，在Agent中引入对应的支付MCP，即可实现定制需求，提供报价，快速交易变现的场景。

让我们在回顾一下MCP的整个概念和流程：

用户提问 → LLM通过MCP Client生成工具调用请求 → MCP Server路由到目标工具 → 工具返回结果 → LLM整合结果并回复用户

MCP宗旨：统一大模型与外部服务的智能桥梁

1. MCP协议的核心价值：标准化通信 MCP（Model Control Protocol）协议本质上是一种标准化接口规范，它统一了大模型（LLM）与外部数据源、工具服务之间的通信方式。通过MCP：解耦LLM与工具：不同厂商的大模型（如GPT-4、Claude、文心一言）可通过同一套MCP协议调用外部工具，无需为每个模型单独适配。
2. 统一工具描述：所有外部服务（如航班查询、天气API、数据库）以标准化的MCP格式注册其功能、参数和权限，避免手动拼接Prompt的繁琐操作。
3. 动态兼容性：当新增工具时，只需将其注册到MCP Server，所有接入MCP的LLM均可立即调用，无需重新训练或调整模型。