工程师在使用编码代理（coding agents）对接不熟悉的 API 时屡遭挫折，这一过程以手动组装上下文为特征，且该上下文极易迅速过时。核心问题在于将 prose 文档作为 API 契约的传输机制，由此引发文档陈旧、重复产生 token 成本以及缺乏强制执行等问题。prose 文档仅提供一个快照，很快便过时；迫使在每次对话中重新上传相同信息；且无法在运行时错误发生前验证调用。结构化的解决方案是向代理提供基于 MCP（微服务契约协议）服务器的可调用工具形式的 API 契约，该契约直接由 OpenAPI 文档生成。这种方法将每个 API 操作转换为具有定义输入模式的工具，从而实现结构化发现和预飞行验证。与 prose 不同，MCP 工具允许代理立即进行错误纠正，集中管理认证，并确保所有关联代理共享一处更新的契约。流式操作也变得可用，因为工具负责打开流并收集事件。本地开发利用基于规范文件的本地 MCP 服务器；共享环境则可使用带版本锁定和用户级 token 的托管 MCP 端点，强调通过 token 作用域实现最小权限访问。MCP 在涉及对内部 API 的重复集成工作、包含大量小型操作的复杂环境、强制执行要求高的领域（如计费）以及快速迭代的规范场景中真正具有优势。然而，它并非叙事性文档或高性能 SDK 的通用替代品。MCP 不适用于一次性探索、性能关键型或批量客户端，以及未在 OpenAPI 规范中明确定义的操作。维护良好的 OpenAPI 文档至关重要，因为工具的准确性完全取决于规范本身。理想的架构是维护一份单一的 OpenAPI 文档，并从中衍生出三种不同的渲染形式：供人类学习的渲染文档、用于生产代码的生成式 SDK，以及用于代理集成与探索的 MCP 服务器。这种方法可避免不同团队和工具间出现冗余描述。