Cookbook：Function calling with an OpenAPI specification——把 API 规格书直接变成模型的工具箱；配 Function calling: finding nearby places 的入门示例。
一句话定位
API 即工具：给模型一份 OpenAPI spec，它就能自己挑端点、填参数、调接口——「教会模型用你的 API」从写 N 个工具定义变成递一份规格书。
两道菜精要
Function calling with an OpenAPI spec（主菜）
- OpenAPI（Swagger）规范描述的 REST API → 模型可调用的函数
- 流程：解析 spec → 端点筛选（哪些与任务相关）→ 参数构造 → 实际调用 → 结果回传
- 关键工程点：spec 太大时的端点裁剪——全量端点塞给模型既贵又乱，按任务先筛
Finding nearby places（入门菜）
- 最小示例：一个「找附近地点」函数的定义与调用握手
- 参数 schema 的写法示范——函数定义就是模型的「使用说明书」
方法论精华
1. 「规格书即接口」的杠杆：世界上已有千万个 OpenAPI spec——存量 API 生态一夜之间全变成 agent 的潜在工具箱；这就是 MCP 出现前最大规模的工具接入路径。
2. 工具发现的分层：任务→相关端点→单个调用——三层里的第一层（发现）最容易被忽视：模型面对 200 个端点时的表现远差于面对筛出的 5 个。上下文预算决定工具清单长度。
3. 参数 schema 是给模型看的文档：description 写什么、enum 怎么用、required 怎么设——函数定义的质量直接决定调用质量，这是 prompt 工程在工具层的延伸。
4. 与 MCP 的关系：OpenAPI 路线是「文档驱动、静态」，MCP 是「协议驱动、动态」——前者接入存量，后者定义未来；当前生态两者并存。
编者注
对有自家 API 的团队：这篇的方法可以让你的 API 明天就被 agent 调用——写好 spec、筛好端点、写好参数描述，三步完事。证据台的连接器思路（类别占位符）是它的组织化管理版本。