同一个工具，不同的调用方
CLI 把功能暴露给敲命令的人。MCP server 把功能暴露给决定调什么的模型。它们常常包装的是完全相同的逻辑——区别在于另一端是谁、以及它对接口的需求。
终端前的人类会读帮助文本、记住参数、用自己的判断力解读输出。模型需要工具以一种它能推理的结构化方式被描述：这个工具做什么、接受哪些参数、返回什么。MCP 提供这种结构化描述；而 CLI 的 --help 是写给眼睛的，不是写给调度器的。
为什么不干脆让模型跑 CLI 命令
给模型 shell 访问、让它调你现有的 CLI，这很诱人。它在 demo 里能用，实操中有风险。CLI 的表面是非结构化的——模型得自己拼命令字符串、解析自由文本输出、猜错误含义，每一样都容易出错。
更重要的是，shell 访问是一种粗糙而危险的能力：一个能跑一条命令的模型，通常能跑任何命令。MCP server 只暴露你选定的那些操作，带类型化参数和明确结果，这比指望模型拼对咒语既更安全也更可靠。
CLI 仍然是对的答案的时候
如果主要使用者是人，就建 CLI。脚本、CI 流水线、交互式终端使用，都是命令比「为模型设计的协议」服务得更好的场景。不是每个工具都需要 MCP 接口，给一个没有模型会调的工具加一个，是白费力气。
很多工具正当地两个都要：给人用的 CLI，给 agent 用的 MCP server，底层共享同一套核心逻辑。这是合理的架构——两个接口服务不同调用方，谁也不让谁变得多余。
为你的工具做决定
问谁来调。终端和脚本里的人类：CLI。对话里选择动作的模型：MCP server。两种受众都有：在共享逻辑之上两个接口都建。
如果你是在为模型使用包装一个现有 CLI，忍住「直接 shell 出去调它」的冲动。把你真正想让模型执行的操作，建模成带类型化输入的正经 MCP 工具——你会得到更可靠的行为，以及比把整条命令行交出去小得多的影响面。