By 黄金金枪鱼 
许多团队把 Agent 工具接入理解成“选 JSON Schema、OpenAPI 或 MCP”。这道题的前提其实错了：三者处在不同层。真正可靠的方案不是押注一种格式，而是建立单一契约源，再生成 API 描述与运行时工具接口。
一、核心事件：工具接口正在分层
MCP 的 2025-06-18 工具规范要求每个工具提供 name、description 与 JSON Schema 形式的 inputSchema，并可声明 outputSchema。与此同时，OpenAPI 3.1 已与 JSON Schema 2020-12 对齐。也就是说，Agent 生态正在形成共同底座：数据约束由 JSON Schema 表达，HTTP 生命周期由 OpenAPI 描述，发现、调用与结果交换由 MCP 承担。工程问题从“选哪个”转为“谁是事实源、如何生成、在哪里校验”。
二、技术解析：拆成三层契约
第一层是数据契约。 JSON Schema 负责类型、必填项、枚举、长度和组合约束，应该成为输入输出结构的唯一事实源。不要只验证“是不是 JSON”；语法正确不等于字段完整。JSONSchemaBench 收集约一万份真实 schema，并用覆盖率、效率与输出质量评估约束生成框架，说明复杂 schema 的兼容性本身就需要测试，而不能靠模型自觉。
第二层是服务契约。 OpenAPI 描述路径、HTTP 方法、认证、状态码与请求响应。已有 REST 服务时，不应把整份 OpenAPI 原样塞进模型上下文；应先筛选允许暴露的 operation，再把 operationId、摘要、参数与成功响应映射为小而明确的工具。业务服务仍由 API 网关负责鉴权、限流、审计和版本管理。
第三层是 Agent 协议。 MCP 在运行时提供工具发现和调用封装，但它不会自动解决业务语义、最小权限或幂等性。官方规范还明确提醒：客户端不能无条件信任非可信服务器给出的工具注解。因此，MCP Server 更适合做薄适配层，而不是复制一套业务逻辑。
这套链路的关键是“双向校验”：调用前校验参数，返回后按 outputSchema 校验结果；失败要返回可机器处理的错误类别，而不是一段含糊文本。若 OpenAPI 与 MCP 各自手写，字段漂移只是时间问题；更稳的做法是从同一 registry 生成二者，并在 CI 中做兼容性检查。
三、关键点
- 确定事实源：以领域模型或 JSON Schema 为源，OpenAPI 与 MCP 描述均由构建流程生成。
- 缩小工具面：只暴露面向任务的高层操作，不把内部 CRUD 全量交给模型选择。
- 分离安全边界：MCP 负责适配；认证、授权、限流、审计仍落在网关和业务服务。
- 版本化演进：新增可选字段通常可兼容；删除字段、改类型或收紧枚举必须发布新版本。
- 验证语义而非只验格式：除 schema 校验，还要测试描述是否清楚、操作是否幂等、错误能否恢复。
四、行业影响
MCP 官方仓库在本次核验时有 8,897 颗 GitHub 星，HN 关于“是否需要 MCP”的讨论也获得数百点热度，说明协议价值与边界仍在快速形成共识。企业下一阶段的竞争点不会只是“接入多少 MCP Server”，而是能否复用既有 API 治理资产，把工具契约做成可生成、可测试、可审计的供应链。
结语
JSON Schema、OpenAPI、MCP 分别回答“数据长什么样”“服务如何访问”“Agent 如何发现并调用”。把三者塞进同一层会制造重复和漂移；让它们共享契约源、各守边界，才是从工具 Demo 走向生产架构的最短路径。
参考资料
官方文档
- JSON Schema Draft 2020-12 Core [200]
- OpenAPI Specification 3.1.0 [200]
- MCP 2025-06-18 Tools 规范 [200]
- MCP SEP-2106：JSON Schema 2020-12 [200]
开源项目
- modelcontextprotocol/modelcontextprotocol [200] - 本次核验 8,897 stars
- guidance-ai/jsonschemabench [200] - 本次核验 99 stars
行业报道
社区讨论
- HN：MCP explained without hype or fluff [200] - 168 points
- HN：What if you don't need MCP at all? [200] - 237 points
对比基准
- JSONSchemaBench 论文 [200] - 约一万份真实 schema
本文由 AI 生成。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。