MCP协议实战：从Function Calling到AI智能体工具调用的工程落地

AI智能体要完成真实任务，必须调用外部工具。早期各家模型的Function Calling接口互不兼容，每接入一个工具就要写一套适配层，工具生态被割裂在各自框架里。MCP（Model Context Protocol）的出现把这个问题标准化：模型与工具之间通过统一的JSON-RPC协议通信，一套工具服务可以被任意支持MCP的智能体复用。这篇实战讲清楚MCP的落地方式，以及AI智能体工具调用的工程细节。

MCP是什么：AI智能体工具调用的标准化接口

MCP由Anthropic在2024年底开源，核心是把工具、资源、提示词三种能力统一成服务端暴露的资源，客户端（智能体）通过协议层发现和调用。对开发者来说，MCP的价值在于：工具服务写一次，就能被Claude、各类支持MCP的Agent框架复用，不用再为每家模型单独实现JSON Schema映射。

MCP的通信模型分三层：客户端连接服务端、服务端声明可用的tools/resources/prompts、请求执行时按协议往返。传输层支持stdio（本地子进程）和Streamable HTTP（远程服务），前者适合本地工具，后者适合部署为独立服务。

MCP工具服务搭建实战：一个Python天气工具

用官方Python SDK（mcp）实现一个天气查询工具，服务端暴露两个工具：get_weather返回实时天气，get_forecast返回预报。代码如下：

from mcp.server.fastmcp import FastMCP
import requests

mcp = FastMCP("weather-service")

@mcp.tool()
def get_weather(city: str) -> str:
    """查询指定城市的实时天气"""
    resp = requests.get(f"https://api.example.com/weather?city={city}", timeout=5)
    data = resp.json()
    return f"{city}: {data['temp']}℃, {data['desc']}"

@mcp.tool()
def get_forecast(city: str, days: int = 3) -> str:
    """查询未来几天的天气预报"""
    resp = requests.get(
        f"https://api.example.com/forecast?city={city}&days={days}", timeout=5
    )
    return resp.text

if __name__ == "__main__":
    mcp.run(transport="stdio")

启动后，智能体客户端通过SDK连接这个子进程，就能自动发现get_weather和get_forecast两个工具，模型会根据用户问句决定调用哪个、传什么参数。

客户端接入MCP：Agent框架中的工具发现与调用

在Python侧用官方client SDK连接stdio服务端：

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

params = StdioServerParameters(command="python", args=["weather_server.py"])
async with stdio_client(params) as (read, write):
    async with ClientSession(read, write) as session:
        await session.initialize()
        tools = await session.list_tools()
        for t in tools.tools:
            print(t.name, t.description)
        result = await session.call_tool("get_weather", {"city": "北京"})
        print(result.content)

这段代码演示了智能体侧最核心的三步：握手初始化、列出工具清单、按参数调用。模型层只需要把工具清单拼进system prompt，由模型在推理时决定调用顺序与参数，Function Calling与MCP在这一层的差别就只剩下协议封装。

Function Calling与MCP的选型边界

Function Calling是模型API层面的原生能力，适合单模型直连的简单场景，代码量小；MCP是多模型、多工具、跨进程场景的标准化方案。选型时按三点判断：

1. 工具数量超过10个、且多个Agent共享工具时，用MCP统一管理；
2. 需要本地读文件、连数据库、操作浏览器的工具，MCP的stdio模式天然适合；
3. 只给单一模型API传工具时，直接用Function Calling省掉一层服务开销。

智能体工具调用的容错与安全设计

工具调用不是发起请求就算完，生产环境要处理三件事：

一是超时与重试，外部API可能5秒不返回，给每个工具设置独立timeout，失败后让模型改用备选路径；二是工具白名单，对写操作类工具（删除文件、发消息、转账）强制人工确认，避免智能体误触发；三是调用审计，把每次工具调用的入参、出参、耗时落日志，模型输出错误时才能定位是哪一步工具结果把上下文带偏了。

MCP在GitHub、模型应用、IDE插件里已经大量落地，社区服务端数量过千。标准化的代价是协议层学习成本，换来的是智能体工具层的复用性，这个交换在工程规模变大后是值得的。