By 黄金金枪鱼 
导语
Agent 调用工具时，背后其实是三套规范在协作：JSON Schema 定义参数形状、OpenAPI 描述 HTTP 服务、MCP 提供握手与能力协商。三者并非替代关系，而是在协议栈不同层级承担职责。
核心事件
2026 年 Anthropic 把 MCP（Model Context Protocol）从「私有协议」升级为开放标准后，社区开始重新审视工具描述的边界：是继续用 OpenAPI 一统天下，还是切到 MCP 原生工具？还是把 JSON Schema 当作底层事实源，三者共存？LangGraph、Claude Desktop、Cline 等客户端的快速接入，让 MCP 成为新事实标准。
技术解析
工具设计的本质是契约——Agent（调用方）需要知道「我能传什么参数、会拿到什么结果」。三套规范从不同维度回答这个问题：
- JSON Schema 是参数级的「最小公分母」。它只规定字段类型与约束，不关心服务在哪儿、用什么协议。OpenAI function calling、Anthropic tool use、MCP 工具描述底层都用 JSON Schema。
- OpenAPI 是 HTTP 服务级的「完整身份证」。它把 JSON Schema 嵌进 endpoint 描述里，加上 base URL、鉴权、错误码，一份 YAML 就能生成 SDK。但它默认面向同步 HTTP 调用，流式与长连接支持较弱。
- MCP 是协议级的「握手规范」。它不重新发明 Schema，而是把 JSON Schema 作为 tool definition 的载体，外加 initialize 握手、capability 协商、resources / prompts / tools 三类原语。一次 MCP 连接可以暴露多个工具，并支持双向流。
为什么三者不是替代而是分工：JSON Schema 是「原子」，OpenAPI 是「HTTP 服务的包装盒」，MCP 是「Agent 与工具宿主之间的协议」。把 OpenAPI 文档自动转成 MCP server，已经有多个开源项目在做；反过来，用 MCP 直接描述 HTTP 服务也是可行的。
关键点
- 契约最小化：能 JSON Schema 描述的，不要加 HTTP 包装；不要让 Agent 在简单工具调用上扛 RESTful 路由判断。Atom 工具（如「计算两个数字之和」）用纯 function call 即可，加 OpenAPI 反而引入 base URL 与鉴权噪声
- MCP 不是 OpenAPI 杀手：OpenAPI 仍是 REST 服务的事实标准，MCP 解决的是「Agent 怎么发现和调用」的协议问题，不是「服务怎么实现」。社区已有多个开源项目能把存量 OpenAPI 服务快速暴露成 MCP server
- 能力协商是 MCP 的关键差异：
initialize握手时客户端声明支持什么（sampling / roots / elicitation 等），服务端声明暴露什么（tools / resources / prompts），双方按交集能力调用。这种「双方各自声明 + 取交集」的模式比「Server 把所有能力塞进 OpenAPI yaml」更稳健 - JSON Schema 选 Draft 2020-12：支持
if/then/else、nullable、$ref 解析，老版本（Draft 7）在嵌套校验时容易出坑。OpenAI / Anthropic 的工具描述对 Draft 2020-12 关键字（$defs、prefixItems）兼容度最高 - 工具描述字段宜精不宜多：description 字段决定 LLM 是否会用对工具。OpenAI 官方建议 100-200 token 内讲清楚功能、参数语义、返回结构，例：「get_weather：查询指定城市的当前天气。参数：city (string, 必填, 城市英文名)。返回：temperature_celsius (number) / humidity (number) / description (string)。失败时返回 error 字段含原因」
- 错误模式统一：工具返回结构里必须有
error或is_error字段，否则 Agent 无法区分「调用成功但无数据」与「调用失败」。MCP 把这点写进规范，OpenAPI 只能靠约定
行业影响
未来 12 个月值得观察的方向：MCP registry 生态成熟度、企业内部 OpenAPI → MCP server 的自动转换流水线、多模态工具（图像 / 视频 / 音频）在 MCP 原语下的统一描述，以及 Anthropic 把 MCP 升级为开放标准后其他厂商（OpenAI、Google DeepMind）的接入节奏。从工程团队视角，建议先把内部高频工具（数据库查询、文档检索、CI/CD 触发）用 MCP 暴露给 Agent，再考虑把外部 OpenAPI 服务桥接进来。
结语
工具设计的复杂度不在「描述」，而在「让 Agent 在错误使用前就知道怎么正确用」。JSON Schema、OpenAPI、MCP 各管一摊，搭配得当比单押一个更稳。对刚起步的团队，建议先从 MCP + JSON Schema 起步，工具数量超过 20 个再考虑接入 OpenAPI gateway 做统一管理。
参考资料
官方文档
- Anthropic: Model Context Protocol Specification [200] - 2026-06
- JSON Schema Draft 2020-12 官方文档 [200] - 2020 至今
- OpenAPI Initiative 规范索引 [200]
开源项目
- modelcontextprotocol/python-sdk [200] - 2026-07 活跃维护
- fastapi-mcp: OpenAPI → MCP 自动转换 [200]
- openai/openai-python function calling 示例 [200]
行业报道
- The New Stack: MCP 与 function calling 对比观察 [200] - 站点入口
社区讨论
对比基准
- Hugging Face Blog 主页 [200] - 社区博客聚合
- GitHub awesome-mcp-servers 索引 API [200]
本文由 AI 生成。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。