你问 AI 助手「8.8.8.8 是个好 IP 吗」，它答得好像早就知道似的。它不知道——它调了一个工具。Tool calling（也叫函数调用）就是那个把语言模型变成能去取活数据的东西的机制。这篇文章把线上发生的事走一遍，用 IPIPAI 的 MCP 工具做具体例子。
三步循环
每一次工具调用都是同一个循环，三个角色。模型判断需要工具，发出一份结构化的调用请求。客户端（Claude、Cursor、你自己写的脚本）拿这个请求去真的调服务。服务返回活数据，客户端把它作为工具结果喂回模型。模型手里有了这些数据，才继续组织它的答案。
这套能跑起来靠两件事。第一，模型自己从不碰网络——它只是描述想要哪个工具、带什么参数。第二，结果以结构化数据回来，模型可以基于它推理而不是瞎猜。背后的协议机制在 MCP 和 JSON-RPC 指南里有讲。
示例：模型决定查一个 IP
假设你问：「关于 8.8.8.8 你能告诉我什么？」模型被告知存在一个叫 lookup_ip 的工具。它决定用，并返回一次工具调用：
{
"name": "lookup_ip",
"arguments": { "ip": "8.8.8.8", "lang": "en" }
}客户端接过这个，POST 到 IPIPAI 的 MCP 端点（就是 协议指南里展示的那条 tools/call 消息），拿回结构化数据：地理位置、ASN、ISP 类型、风险评分，整套 ipai_score 拆解。这个载荷作为工具结果回到模型手里，直到这一刻模型才开始组织答案。
示例：给流媒体节点打分
接下来是好玩的那个。问：「我想要个能看美区 Netflix 的节点，104.16.x.x 行吗？」模型可以带着 IP 和 netflix 这样的目标去调 rate_ip_node：
{
"name": "rate_ip_node",
"arguments": { "ip": "104.16.132.229", "target": "netflix" }
}回来一个结论：这个 IP 当前能不能解锁目标，外加延迟和稳定性信号。模型把它折叠成直接答案——「能，这个现在能看美区 Netflix，延迟也低」——而不是一段关于代理的泛泛而谈。这就是工具调用值回票价的地方。
为什么这改变了你能问的问题
没有工具，AI 模型用训练数据回答 IP 问题，数据发布当天就开始过时。有了工具，同一个模型用活查询来回答。这就是「Google DNS 是知名公共解析器」和「8.8.8.8 当前得分 96/100，四大主流 AI 服务全部可达」的区别。前者是记忆，后者是测量。
你自己直接调
想拿同样的数据，不需要 AI 客户端。IPIPAI 用普通 HTTP 端点暴露同样的能力——IP 查询 API 一次 POST 或 GET 就到手。想让模型在循环里，每个工具及其 schema 都列在 /mcp-tools.json，配置步骤在 MCP 接入指南。
收尾
Tool calling 是个听起来很枯燥、却让 AI 答案可验证的功能：模型决定、客户端执行、服务用活数据响应、模型作答。IPIPAI 的 MCP 服务器给你十一个这样的工具可以插——lookup_ip 和 rate_ip_node 只是最受欢迎的两个。完整清单在 /mcp-tools.json，更多博客内容在 IPIPAI 文章页。