工具架构
MCP、CLI 与 API 都只是接口，没有一种能赢下所有场景
正确问题不是哪种技术更新，而是能力在哪里运行、谁需要发现它、数据如何验证，以及你愿意承担多少运维成本。
Alejandro Sánchez约 9 分钟
CLI：容易携带，也容易观察
CLI 很适合终端、脚本和 CI，可以直接处理本地 filesystem，也容易用通用工具调试。问题在于，如果输出只面向人类且不稳定，每个消费者都要重新解析。
qzx diagnoseProject . --jsonAPI：明确的网络边界
当能力本来就是服务、需要集中认证或被大量远程客户端使用时，API 很自然。代价是网络、可用性、凭据和服务器运维。
MCP：面向 AI 客户端的发现与契约
MCP 为兼容客户端提供发现工具和 schema 的共同方式，尤其适合减少每个客户端与每个服务器之间的专用集成。
不要复制核心逻辑
如果同一操作要同时提供 CLI 与 MCP 接口，让核心实现独立于传输方式。这样测试与语义可以共享，每个适配器只处理自己的协议和体验。
常见问题
哪种接口最简单？
取决于环境。终端中 CLI 很直接，服务之间 API 很自然，而兼容客户端需要发现工具时 MCP 更合适。
可以同时使用三种吗？
可以。保持一个规范的核心操作，再通过不同适配器暴露能力，可以避免重复业务逻辑。
结构化结果为什么重要？
它能让软件和代理更可靠地区分成功、错误、数据和下一步，而不是猜测人类文本。