已有一套业务系统，也有能查任务、改状态的 CLI。现在想让 Codex 帮忙处理工作，还要再开发一个 MCP Server 吗？
只看“能不能调用接口”，很难找到增加一层服务的理由：CLI 可以请求业务 API，MCP Server 也可以。
真正需要比较的是：现有命令能否满足使用要求？新增 MCP 后，能减少哪些接入和维护工作？
下面用“查询我的待办”贯穿两条路径，再看个人使用、多人使用和多个 AI 客户端这三种条件下，选择会怎样变化。本文是选型分析；CLI 命令已核对本机帮助，业务查询与对应 MCP 方案没有做对照实测。
1. 先把三者放回各自的位置
Codex 是使用工具完成任务的 AI 编程代理；CLI 是命令行接口；MCP 是连接 AI 应用与外部能力的协议。本文只讨论 MCP 中的工具调用。
它们可以组成这样的关系：
图 1：调用关系示意；两条路径共享业务能力，业务授权仍需实现。
这是两条可选择的接入路径，可以共存。另一个容易混淆的名字是 Codex CLI：它是 Codex 的命令行客户端；业务 CLI 则是 Codex 可以调用的工具。
2. 同一个查询，MCP 到底多提供了什么？
已有 CLI 时，从命令入口开始
以禅道 CLI 为例，本机安装的 zentao-cli 0.3.1 提供了这个帮助入口：
zentao my tasks --help
其中列出了 --browseType、--pick 和 --format 等参数，可以组合为：
zentao my tasks --browseType=unclosed --pick=id,name,status --format=json
它表达的是查询当前账号下未关闭的任务，保留编号、名称和状态，以 JSON 输出。这里的“未关闭”沿用 CLI 的筛选语义，不能直接当成“全部未完成工作”。
本次只运行了版本与帮助检查，没有执行上面的业务查询，也没有取得真实任务结果。 该操作的帮助还列有最低服务端版本要求，实际使用前仍需确认登录身份、服务器兼容性及返回范围。
这条路径中，Codex 需要知道命令怎么写、哪些参数有效、怎样读取结果。CLI 则负责处理凭据、请求业务服务、报告错误。
如果命令帮助清楚，JSON 输出稳定，失败时也能判断原因，这已经是值得复用的基础。换成 MCP 并不会自动改善后端数据的质量。
接入 MCP 时，多出一份标准工具契约
同样的查询，可以设计成一个 MCP 工具。下面是工具描述片段，不是禅道现有 MCP 的接口，也不是已经实现的服务：
{
"name": "list_my_tasks",
"description": "查询当前已认证用户未关闭的任务",
"inputSchema": {
"type": "object",
"properties": {},
"additionalProperties": false
}
}
这个工具把查询范围固定在服务端：当前用户、未关闭任务。客户端通过 MCP 的 tools/list 获取描述，再用 tools/call 调用。Server 需要把调用转换成业务请求，并将结果或错误返回。
这里的变化是：工具的发现、输入描述和调用方式有了共同协议。 CLI 也能提供结构化输出和参数校验；MCP 的价值在于让支持它的客户端按共同约定接入，而不用各自重新理解一套命令入口。
上面的参数设计还有一个限制：AI 没有传入 userId 的入口。但这只减少了输入面，不能代替权限控制。Server 仍要把可信登录身份映射到业务账号，后端仍要检查该账号有权读取哪些数据。
3. 一个人使用：先看现有 CLI 卡在哪里
如果只有自己用 Codex，CLI 已经安装好，账号也能正常访问业务系统，新增 MCP 的收益需要具体说明。
可以先检查一次查询是否满足这些要求：
- 能确定使用了哪个账号，返回的确实是该账号可见的数据；
- 能区分空结果、认证失败、权限不足与网络故障；
- 能处理分页，避免把第一页说成全部任务；
- 输出可以稳定解析，不依赖人去猜表格含义。
这些问题没有解决时，包一层 MCP 很可能只是把原来的缺口带过去。
在这个条件下，优先完善 CLI 通常更直接。等到出现明确的接入问题，再判断 MCP 是否值得增加。这个判断来自已有资产和新增维护成本，不是两种方案的性能测试结论。
4. 几十个人使用：先算身份和部署的账
假设团队有 50 位员工，都要查询自己的任务。人数本身不能决定必须使用 MCP。
如果每个人已有受管理的工作环境，CLI 的安装、升级和个人登录都容易维护，继续使用 CLI 仍然是候选方案。
如果大家使用不同设备，不方便逐台管理命令环境，而目标 AI 客户端又支持远程 MCP，那么集中部署服务就值得评估。它能把工具实现和服务更新集中起来，但同时引入登录接入、服务可用性、监控与运维工作。
尤其要分清两件事：
- 客户端通过认证，证明它可以访问 MCP 服务；
- 某位员工可以读取哪条任务，需要业务授权继续判断。
MCP 的 HTTP 授权规范提供了协议层的授权流程约定，具体的账号映射、租户隔离和数据权限仍要实现。把 50 个人接到一个共享管理员账号上，不会因为用了 MCP 就获得个人权限隔离。
这个场景要比较的是：逐个维护 CLI 环境的成本，与集中维护服务、登录和权限的成本。
5. 多个 AI 客户端使用：MCP 的复用价值更明确
当工具不仅供 Codex 使用，还要接入其他支持 MCP 的客户端时，共同协议开始带来更直接的收益。
例如，“查询我的待办”只维护一份工具名称、描述、参数约束和服务端实现。接入另一个兼容客户端时，可以复用这份契约。CLI 仍可保留，继续服务人工操作和脚本，两者共享业务 API 或业务模块。
不过，支持 MCP 不等于所有客户端行为一致。至少要分别验证：
- 是否支持计划采用的本地或远程连接方式；
- 登录和凭据续期能否正常完成；
- 工具返回错误或超时时，用户能否识别；
- 如果以后增加写操作，确认与权限限制是否按预期执行。
如果眼下只有一个客户端，而其他客户端只是可能会用，先为未来建设完整 MCP 服务，也可能增加当前负担。
6. 开工前，先写清楚新增 MCP 的理由
图 2：三种使用条件下的选型思路；多人使用并不直接等于必须部署 MCP。
可以用这张表收束选择：
| 当前条件 | 优先动作 | 需要补的证据 |
|---|---|---|
| 一个人使用，已有可用 CLI | 先复用 CLI | 真实查询、身份、错误与分页是否可靠 |
| CLI 结果不稳定或权限不清 | 先修工具或业务接口 | 缺口是否已经解决 |
| 多人使用，维护本地环境有明显负担 | 比较受控 CLI 与远程 MCP | 登录、隔离、部署及运维成本 |
| 多个兼容 AI 客户端需要同一套业务工具 | 优先评估 MCP | 各客户端连接、认证和调用验证 |
真正开工前，补完一句话会很有用：
新增 MCP，是为了让 ______ 客户端复用 ______ 能力，减少目前 ______ 的接入或维护工作。
如果暂时填不出具体对象和具体工作，就先把现有 CLI 路径验证完整。如果需求已经明确，再为它建设工具契约和服务。
对于“查询我的待办”，下一步最有价值的证据是一次真实查询：用什么身份、返回了什么、范围是否完整、失败能否识别。等两条路径都实现并验证过，才有依据讨论它们在具体环境里的效果差异。
参考资料
文中的 MCP 工具是设计示例；没有完成业务 CLI/MCP 对照测试、多用户部署或跨客户端验证。
