工具调用与 MCP：分别解决什么问题？

用户问“北京今天多少度？”应用把天气工具的说明交给模型，模型选择工具并填写城市，程序执行查询，把结果交回模型组织回答。这个从“想查”走到“查到了”的过程，就是工具调用。

可以把它想成点餐：模型负责写点菜单，应用负责核对并交给厨房，工具负责做菜，做好的菜再送回来。点菜单上写了“宫保鸡丁”，厨房才刚收到任务。对应到程序里，工具名和参数表达要做的动作，工具的返回值才提供执行结果。

从函数调用到工具调用

先看熟悉的函数：

def get_weather(city: str) -> dict:
    # 用固定天气数据观察调用过程。
    return {"city": city, "temperature": 26, "mock": True}

result = get_weather("北京")
print(result)

把上面完整代码保存为 weather_demo.py，在资源管理器打开保存它的文件夹，在地址栏输入 powershell 并回车。运行：

macOS：先在 Python 篇的学习文件夹中打开终端，执行 source .venv/bin/activate。再输入 cd ，把当前例子的文件夹拖入终端并回车，运行下面的命令。

ls
python weather_demo.py

你会看到：

{'city': '北京', 'temperature': 26, 'mock': True}

city 是城市，temperature 是温度，mock: True 标记这份结果来自固定示例数据。把调用中的“北京”换成“上海”再运行，城市字段会改变，固定温度仍是26。这样先看清“传入参数→运行函数→得到返回值”。

函数名是 get_weather，输入参数 city 是城市，返回值是包含城市和温度的字典。代码已经把调用哪个函数、传什么值写好了。

工具调用把“选择函数、填写参数”这一步交给模型。应用提供工具清单，例如“get_weather：查询一个城市的天气”；模型根据问题返回结构化请求：

{"name": "get_weather", "arguments": {"city": "北京"}}

这里 name 是工具名，arguments 是参数集合。应用接到这份请求后，找到对应函数，检查参数，再执行。把数据库查询、文件读取、搜索接口包装成工具，都是同一种思路。

“应用运行时”指应用实际运行、处理这些请求的程序。下面直接称它为应用，沿着一个查询看清数据怎样走。

后面会用到 MCP（Model Context Protocol，模型上下文协议）：当工具由另一个程序提供时，它约定双方怎样发送工具说明、请求与结果。先沿图看清模型、应用、工具的分工，再学习它们跨进程通信的方式。

把请求交给对应函数

新建一个学习文件夹，创建 tool_example.py，保存下面的完整程序。在该文件夹的资源管理器地址栏输入 powershell，回车打开终端。

def get_weather(city: str) -> dict:
    # 固定天气表用于观察输入、执行和输出。
    return {"city": city, "temperature": 26, "mock": True}

# 工具注册表：名字对应实际可调用的函数。
tools = {"get_weather": get_weather}

# 先固定一份模型可能生成的请求，方便逐步观察。
request = {"name": "get_weather", "arguments": {"city": "北京"}}

if request["name"] not in tools:
    raise ValueError("工具不在白名单中")

args = request["arguments"]
# 字段集合必须恰好是 city；城市类型必须是字符串。
if set(args) != {"city"} or not isinstance(args["city"], str):
    raise ValueError("参数结构不合法")
if not args["city"].strip() or len(args["city"]) > 80:
    raise ValueError("城市名称不合法")

# **args 把 {"city": "北京"} 展开为 city="北京"。
result = tools[request["name"]](**args)
print(result)

在刚打开的 PowerShell 中运行：

python -X utf8 tool_example.py

输出为：

{'city': '北京', 'temperature': 26, 'mock': True}

mock: True 表示温度来自固定数据。想观察执行机制，固定输入比一开始连接天气网站更容易排查；等这条路径走通，再把函数内部替换为天气 API 请求。

沿着代码读一次：tools 像前台的服务名单；request["name"] 选服务；args 携带城市；检查通过后，result = tools[request["name"]](**args) 真正调用函数。Python 的 ** 在这里负责展开字典，相当于写 get_weather(city="北京")。

白名单就是应用允许执行的工具集合。模型给出的名字在名单里，应用才找到对应函数。这让模型可以灵活选择动作，同时让应用掌握实际执行入口。

结果怎样回到模型

一次完整交互通常包含下面五个动作：

1. 应用把问题和工具说明发给模型。
2. 模型返回请求，例如查询北京天气。
3. 应用检查并执行 get_weather。
4. 应用把查询结果作为工具结果交回模型。
5. 模型根据结果给出答复：“示例天气表里，北京为 26°C。”

当一次响应包含多个工具请求时，每个请求需要一个调用编号，例如 call-1。回传结果带上相同编号，就能找到它对应的请求。像外卖取餐号一样，取餐先后可以变化，订单关系仍然清楚。具体字段名和消息格式由使用的模型接口规定。

上面的 Python 程序运行到了第三步，print 让你在终端看到结果。第一个循环实验会把接收结果、继续判断、结束任务接起来。

MCP 接在哪一段

当工具只有几个、本来就在应用代码里，注册 Python 函数就很直接。若工具由多个独立服务提供，每个应用都各写一套接入格式，维护成本会越来越高。

MCP（Model Context Protocol，模型上下文协议）约定 AI 应用与能力提供程序怎样交换消息。应用可以按共同的格式获取工具清单、请求执行并接收结果。它的三个参与者是：

工具调用关注“选择并使用工具”；MCP 关注“应用怎样接入外部能力”。同一个天气工具可以直接作为函数调用，也可以由 MCP Server 发布。选择取决于是否需要跨应用复用、独立部署和统一接入。MCP 官方架构说明介绍了 Host、Client、Server 的关系。

改两处，观察执行入口

先把请求的名字改成 unregistered，再运行。你会看到 ValueError: 工具不在白名单中。错误发生在查找并执行函数之前。

恢复工具名，把城市改为 ""，再运行，会看到 ValueError: 城市名称不合法。恢复 "北京"，输出重新出现温度。

进一步接入读取笔记、创建订单等工具时，应用还要检查当前用户和资源权限。查询一般获取数据，写入则会改变外部状态；涉及写入时，应在执行旁安排权限、重复请求处理和状态确认。这些控制沿后续文章逐步实现。

工具调用的主线可以记成一句话：模型选择动作，应用检查并执行，结果回到模型。接着读工具描述与输入输出 Schema，把工具清单写成模型和程序都能理解的数据契约。