很多人第一次看到 MCP，会把它理解成 Function Calling 的升级版。这个说法不准确。MCP 和 Function Calling 不是谁淘汰谁，而是解决的问题不在同一层。

更通俗一点：Function Calling 负责把“模型这一次要调哪个函数、参数是什么”说清楚；MCP 负责把外部工具做成标准服务，让不同 AI 应用都能发现、连接和复用。

实际落地时，两者经常一起用：MCP 把工具接进来，Function Calling 让模型在对话里选择并触发工具。

1. Function Calling：解决“一次调用怎么表达”

Function Calling 的重点是单次调用格式。你把工具说明发给模型，模型判断需要工具时，返回一个结构化调用请求；你的业务代码拿到参数后，才真正执行函数。

所以，Function Calling 不是让模型直接访问数据库、写文件、发消息。模型只负责生成调用意图，真正执行动作的是应用侧代码。

比如定义一个查询天气的工具，模型看到用户问“上海今天热不热”，就可以选择调用 get_weather。工具定义一般会用 JSON Schema 描述参数。

Function Calling 工具定义：

{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get weather by city name.",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {
                    "type": "string"
                }
            },
            "required": [
                "city"
            ],
            "additionalProperties": false
        },
        "strict": true
    }
}

模型返回的一次工具调用：

{
    "type": "function_call",
    "name": "get_weather",
    "arguments": "{\"city\":\"Shanghai\"}"
}

这就是 Function Calling 的边界：它让模型用结构化方式表达动作，但工具从哪里来、怎么注册、怎么跨项目复用、怎么统一治理，不是它主要解决的问题。

2. 只靠 Function Calling，工具多了会重复建设

如果只有一两个工具，Function Calling 很轻巧。但当多个应用都要接同一批工具时，问题会变明显：每个应用都要写一份 schema，每个应用都要写执行逻辑，每个应用都要处理权限、异常和日志。

比如客服 Agent、运营 Agent、研发 Agent、数据 Agent 都要接 GitHub、Slack、数据库和文件系统。如果只靠 Function Calling，很容易变成“每个项目复制一遍工具定义”。

3. MCP：解决“工具怎么接入、发现和复用”

MCP 的思路是：不要让每个 AI 应用都重复对接外部系统，而是把外部系统封装成 MCP Server。AI 应用作为 Host，通过 Client 连接 Server，自动发现可用工具和资源。

MCP 官方把它定义为连接 AI 应用和外部系统的开放标准。它不是某个具体工具，而是一套通信和能力暴露规范。

比如在客户端配置一个天气 MCP Server。配置好之后，支持 MCP 的客户端就可以启动它、连接它，并读取它暴露出来的工具清单。

MCP Server 配置示例：

{
    "mcpServers": {
        "weather": {
            "command": "node",
            "args": [
                "./weather-mcp-server.js"
            ]
        }
    }
}

向 MCP Server 请求工具列表：

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {

    }
}

调用 MCP Server 暴露的工具：

{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
        "name": "get_weather",
        "arguments": {
            "city": "Shanghai"
        }
    }
}

注意这个区别：MCP 不是替模型执行思考，也不是替代 Function Calling。它是把工具接入标准化，让工具可以被发现、被连接、被复用。

4. 两者怎么配合：MCP 接工具，Function Calling 触发工具

一个实际系统可以这样跑：MCP Client 先从 MCP Server 拿到工具清单；AI 应用把这些工具整理成模型能理解的工具描述；模型通过 Function Calling 选择工具；应用侧再把调用转成 MCP 的 tools/call 请求。

下面是一个简化版伪代码。它表达的是：模型产生 Function Calling 结果之后，应用侧再去调用 MCP Client。

应用侧把 Function Calling 转成 MCP 工具调用：

import json

if tool_call.name == "get_weather":
args = json.loads(tool_call.arguments)

result = mcp_client.call_tool(
name="get_weather",
arguments={
"city": args["city"]
}
)

messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(result, ensure_ascii=False)
})

5. 什么时候只用 Function Calling，什么时候上 MCP？

选择时不要看名字新不新，而要看工具规模和复用需求。工具少、应用单一，用 Function Calling 更直接；工具多、多个应用都要用，就适合 MCP。

6. 实际落地可以这样做

比较稳妥的做法是先轻后重：少量工具先用 Function Calling 跑通业务闭环；当某些工具被多个项目重复使用时，再抽成 MCP Server。

• 第一阶段：业务里只有少量工具，先用 Function Calling 定义 schema，快速上线。

• 第二阶段：工具被多个 Agent 复用，把它们封装成 MCP Server。

• 第三阶段：统一做工具权限、参数校验、审计日志、限流和异常处理。

• 第四阶段：把常用工具沉淀成内部工具市场，让不同 AI 应用按需连接。

7. 生产环境必须管住工具风险

无论是 Function Calling 还是 MCP，只要工具能读数据库、写文件、发消息、创建工单，就不能只关注“能不能调通”。工具调用本质上是系统执行能力，必须有边界。

至少要做五件事：工具白名单、参数校验、用户确认、权限隔离、审计日志。尤其是有副作用的动作，比如删除文件、发邮件、创建工单、转账支付，一定不能让模型绕过确认流程。

8. 一句话讲清楚

MCP 和 Function Calling 不是替代关系。Function Calling 解决的是一次工具调用的结构化表达；MCP 解决的是工具接入、发现、复用和治理。小项目、少量工具，用 Function Calling 就够；多项目、多工具、多客户端复用，就应该考虑 MCP。

真正落地时，MCP 往往在工具管理层，Function Calling 在模型调用层：MCP 负责把工具接进来，Function Calling 负责让模型触发这一次调用。