最近我越来越强烈地感觉到一件事：
很多 Agent 系统到了后面，真正先撑不住的，不是模型能力，也不是工具数量，而是工具描述本身。
这话听起来有点绕。明明我们接 MCP，就是为了让模型更好地用工具。结果工具一接多，schema 一铺开，最先被吃掉的反而是上下文窗口。你本来想给 Agent 加能力，最后干成了给它塞说明书。
这就有点像什么呢？
本来你是想给新同事配一套顺手的工具箱，结果你先给了他 300 页设备手册。理论上没毛病，工程上已经开始让人皱眉了。
所以这篇文章我不准备聊 MCP 对不对。MCP 当然是对的，它解决的是标准化工具暴露的问题。我要聊的是另一个更现实的问题：
当工具越来越多时，怎么让 Agent 既看得见能力，又不被工具描述本身拖死？
一、MCP 为什么会占用大量上下文窗口？
这个问题其实不用讲太复杂。
MCP 本质上就是把工具的名字、描述、参数、返回结构这些信息，以一种统一的方式暴露给模型。工具少的时候，这套机制非常优雅；但工具一多，问题就来了：
- 每个工具都带一段描述
- 每个参数都带 schema
- 工具数量一上来，描述体积就会迅速膨胀
于是，大规模工具暴露下，Token 成本会快速上升。
而且这还不只是钱的问题。更麻烦的是，业务上下文、用户问题、历史对话，本来就要抢窗口；现在工具描述再来分一大块，模型真正能拿来思考问题的空间就更紧了。
说白了，MCP 的问题不是协议不好，而是：
当工具规模上来之后，直接把整份能力描述裸喂给模型，成本会越来越高。
这时候，就得想办法换一种暴露方式了。
二、OpenClaw 的解法：用 mcporter 把 MCP 变成 CLI
OpenClaw 这边给出的一个很有意思的思路，就是 mcporter generate-cli。
它干的事情，简单说就是：
把原本给 MCP 用的工具描述，转换成一套 CLI 命令面。
也就是说，Agent 不再一开始就吃下整份庞大的 schema，而是先看到一个顶层命令入口。然后它可以像人类一样：
- 先看顶层
help - 再进入相关子命令
- 再看具体参数说明
- 最后执行命令
这个变化的关键在于，它把原来的“全量注入”变成了“按需探索”。
以前是：
先把所有工具说明都塞进上下文，再让模型决定用哪个。
现在更像是：
先告诉模型这里有一棵命令树，需要的时候自己沿着树往下看。
这样做的好处非常直接。
1）省上下文
最明显的收益，就是不用把所有工具 schema 一次性放进模型窗口里。
你只需要暴露一个 CLI 入口，剩下的信息让 Agent 在运行时通过 help 渐进式获取。这样上下文里保留的是当前任务真正相关的那一小部分，而不是一整片工具海。
2）保留 MCP 的完整能力面
mcporter 的价值不在于“重新发明工具协议”，而在于它站在 MCP 之上做了一个更适合 Agent 消费的投影层。
底层还是 MCP server，能力还是那套能力，只是对 Agent 来说，消费方式从“读 schema”变成了“用 CLI”。
3）工程接入成本低
这一点很关键。
如果你已经有 MCP server，那么用 generate-cli 相当于可以很快获得一个可探索、可调用的命令面。你不用再手工为每个工具重写一层 CLI，也不用额外维护一套和后端可能逐渐脱节的命令文档。
所以 mcporter 主要省的，其实是工程接入成本：
- 已有 MCP server，马上变 CLI
- 少写一层胶水
- 快速扩大可用能力面
当然，这套方案也不是没有代价。
mcporter 生成出来的 CLI，往往是能用，但不一定特别好用。因为它本质上还是从 schema 自动映射出来的，所以很容易继承底层工具定义的“机器味儿”：
- 参数名偏技术化
- 某些命令结构不够自然
- 复杂参数仍然可能需要 JSON
- 从调用准确性看，CLI 有时甚至会比原生 MCP 更脆，尤其是在 shell quoting、复杂嵌套参数这些地方
所以如果你问我，mcporter 解决了什么？
我会说，它解决的是：
如何以最低成本，把 MCP 从“模型上下文里的工具描述”变成“运行时可探索的工具入口”。
这已经很有价值了。
不过，如果再往前走一步，你会发现还有一条更“产品化”的路。
让我们看看 Google 是怎么进一步处理这个问题的。
三、Google Workspace CLI 的解法：把能力树做成更适合 Agent 探索的产品层
Google Workspace CLI 这条路，和 mcporter 有相似之处，但味道明显不一样。
它的核心思路不是把所有接口说明一股脑给模型，而是先暴露一个顶层 CLI，然后让 Agent 通过 help 逐步进入能力树：
- 先暴露一个顶层 CLI
- Agent 通过
help - 再进入子命令
- 再看参数说明
- 按需逐步探索能力树
这套方式最有意思的地方在于，它不是简单换个壳，而是在命令空间组织方式上更照顾 Agent 的认知习惯。
换句话说，它更像是专门为 Agent 使用体验设计的一层 CLI 产品层。
1）从 token 视角看，为什么它和 mcporter 都省？
因为两者本质上都在做同一件事：
把一次性注入整份接口描述，改成运行时按需拉取局部说明。
这就像原来你要先把整本字典背下来再说话，现在变成“需要哪个词再翻哪一页”。
对于上下文窗口来说，这种差别是非常实在的：
- 不再全量暴露能力描述
- 只在当前任务需要时获取局部 help
- 避免模型在超大的平面工具列表里乱看一圈
所以，mcporter 和 Google Workspace CLI 在 token 视角下其实是同路人。
2）但 mcporter 的问题也很明显：自动生成的 CLI，往往“能用，但不一定好用”
这点前面已经提了一下，这里单独拎出来说，是因为它正好衬托出 Google 这套方案的价值。
自动生成 CLI 最大的优点是快，但副作用也很明显：
- 它忠实映射后端，不一定忠实映射“用户意图”
- 它描述的是能力，不一定描述的是任务
- 它适合机器完整暴露，不一定适合模型高效调用
尤其在复杂参数场景下，CLI 这层有时会比原生 MCP 更脆。因为原生 MCP 本来就是结构化调用，到了 shell 世界里，转义、嵌套、引号这些东西都开始变得很“工程现实主义”。
3）Google Workspace CLI 的优势：更适合“渐进式发现”
这一点我觉得特别关键。
LLM 有一个很现实的特征：
它更擅长沿着层级树逐步探索，不擅长一开始就理解一个超大的工具平面列表。
Google Workspace CLI 恰好顺着这个特点来设计。
它做的不是“把所有方法罗列出来”，而是把接口能力组织成一棵更适合探索的树。这样 Agent 可以先确定大方向，再不断缩小范围，而不是一开始就面对一大片同级工具名。
4）它还可以被人为优化成“任务语言”
这一步比自动生成更进一步。
Google Workspace CLI 不只是动态发现服务，它还加入了一些人工设计的辅助命令，比如：
+send+reply+agenda+meeting-prep
这些命令的意义，不只是“简化参数”，而是把底层 API 的表达方式，重新包装成更接近任务意图的语言。
比如你让 Agent 去“准备会议”，和让它自己从一堆底层接口里推导出：先查 calendar、再查参与人、再查相关文档，这完全不是一个认知负担。
前者像是在给它任务按钮，后者像是在让它自己读 API 地图。
5）help 也可以写得非常 agent-friendly
这是 Google Workspace CLI 这类方案的另一个优势。
自动生成的 schema 更像“能力定义”，而人工优化过的 help 可以更像“行动指引”：
- 命令更短
- 示例更贴近任务
- 说明更贴近意图
- 默认路径更明确
这对 Agent 特别友好，因为它更接近“我要做什么”，而不是“底层接口长什么样”。
如果要用一句话概括这一章，我会这么说：
mcporter 更像 MCP 的 CLI 投影层；Google Workspace CLI 更像动态 CLI 平台之上，再加了一层面向 Agent 体验优化的产品层。
四、如果站在 Agent 系统设计角度，我会怎么选？
这里有一个特别容易被忽略，但我觉得很关键的点：
两者省的，其实不是同一种成本。
这也是为什么你很难简单地下结论，说谁绝对更优。
mcporter 主要省的是工程接入成本
它的优势非常朴素，也非常实用：
- 已有 MCP server，马上变 CLI
- 少写一层胶水
- 快速扩大可用能力面
如果你已经接了一堆 MCP 服务，或者你正在搭一个通用工具平台，那 mcporter 这种方案的价值就非常大。因为它让你不用每来一个工具域，就重新做一轮 CLI 产品设计。
Google Workspace CLI 主要省的是模型认知成本
它更强调的是另一件事：
- 更好的命令组织
- 更少一次性描述
- 更符合 Agent 探索习惯
- 更少“理解后端接口”的负担
它不是先追求“所有能力都快点暴露出来”，而是更在意“暴露出来之后，Agent 好不好理解、好不好走通”。
所以哪个更优？
答案并不是单一的，而是：
看你想优化哪一种成本。
如果你现在最缺的是“接入效率”，那 mcporter 很有吸引力。
如果你现在最缺的是“Agent 调用体验”和“高频任务的成功率”，那 Google Workspace CLI 这种 help 渐进式发现 + 人工辅助命令的思路，会更值得学。
如果让我来设计，我会怎么做？
我的选择其实不是二选一，而是分层。
第一层：MCP / API 作为标准能力层
先把工具能力标准化，保证覆盖完整性。这一层是基础，没有它，后面所有优化都容易变成散装脚本。
第二层：自动生成 CLI，作为低 token 接入层
这里可以用 mcporter 这样的方案，快速把能力投影成一个 Agent 可探索的 CLI 面。
第三层：对高频场景做人工优化 helper
当某些任务使用频率足够高，比如发消息、查日程、做摘要、准备会议，那就值得再往上做一层“任务语言”封装，把它们从底层接口提升成明确动作。
说得直白一点：
- MCP 保证完整性
- 生成式 CLI 保证低成本接入
- 人工 helper 保证高频体验
这三层放在一起，我觉得才是一个更成熟的 Agent 工具体系。
结语
所以回到文章标题。
如果你也在为 MCP 占用巨大的上下文窗口而烦恼，我的判断是：
问题不在 MCP 本身，而在于我们不能一直把它当成“直接给模型看的最终形态”。
当工具规模上来之后，协议层标准化是一回事，让 Agent 低成本理解这些能力又是另一回事。
mcporter 给出的答案是：先把 MCP 变成 CLI；Google Workspace CLI 进一步给出的答案是：不仅要变成 CLI，还要把 CLI 设计成更适合 Agent 渐进探索和任务调用的形态。
从这个角度看，CLI 化不是倒退，反而像是一种很现实的重新分层。
毕竟工程世界里，真正好用的系统，往往都不是“把所有能力都摊开”，而是让使用者在正确的时间，只看到他需要看到的那一小部分。
而 Agent，大概也一样。
