mcpc：把整个 MCP 生态装进一个 Shell 命令

如果你让 AI Agent 接过 MCP 服务器，多半见过这样的场景：Agent 的系统提示里塞进三十个工具定义、每个都带一屏 JSON Schema，模型每轮对话都在"选工具"上烧掉几千 token；真正执行时又因为某个参数格式不对反复重试。开发者社区最后给出了一个流传很广的结论——"MCP 不好用，CLI 更好"。

Apify CEO Jan Curn 在三周里写了约 300 个提交、烧掉 300 美元 Claude Code 额度之后，决定正面挑战这个结论。他做的不是又造一个 MCP 服务器，而是造了一个通用 MCP 命令行客户端：mcpc。

一个"翻译层"的想法

mcpc 的核心命题很简单：MCP 生态越滚越大，客户端要追的协议特性就越多——工具、资源、提示词、异步任务、技能扩展、OAuth 2.1、企业级授权……但绝大多数 Agent 的运行环境里本来就有 Shell。与其让 Agent 记住几十个函数签名，不如把 MCP 的每项操作映射成一个符合直觉的子命令，让 Agent 只读 --help 就能上手。

 ┌──────────┐   Bash()   ┌────────┐    MCP    ┌────────────┐
 │ AI agent │ ─────────► │  mcpc  │ ────────► │ MCP server │
 └──────────┘            └────────┘           └────────────┘
                                     Sessions, OAuth, Tools,
                                     Resources, Prompts,
                                     Tasks, Skills, x402, ...

这个思路和 Anthropic 提出的 code mode 完全同频：把"提示词里堆工具定义"换成"生成代码去调用工具"。区别是 Anthropic 让模型写 JS，mcpc 直接用最通用、最不会被模型写错的语言——UNIX shell。

覆盖度是它真正的护城河

mcpc 支持最新的 MCP 2026-07-28 协议版本，同时兼容 2025-11-25；传输层同时支持 stdio 与 Streamable HTTP。这不是重点，重点在于它把那些通常被客户端忽略的能力也做了：

• 异步任务：tasks-list / tasks-get / tasks-result / tasks-cancel，长耗时的 MCP 任务不再阻塞对话。
• 技能扩展：skills-list / skills-get，可以直接读取服务端下发的技能文件。
• 企业级授权（ID-JAG）：由企业 IdP 签发令牌，不依赖浏览器 OAuth 流程。
• client credentials 与 动态客户端注册（DCR）：机器到机器登录，无人工干预。
• x402 支付协议：实验性支持，让 Agent 自己完成基于加密钱包的按次付费调用。

作者在 README 里维护了一张横向对比表，把自己的项目和 15 个同类 MCP CLI 客户端逐项打分。按他的统计口径，mcpc 是唯一同时支持 tools / resources / prompts / tasks / skills 五项 + 异步任务 + 技能 + x402 的客户端，连官方的 modelcontextprotocol/inspector 都没覆盖 skills 和 tasks。

三个设计取舍，决定了它是"能用"还是"好用"

第一是持久会话。 mcpc connect mcp.apify.com @test 之后，这个会话就一直活着，多个服务器可以并行保持连接。这意味着 OAuth 只需登录一次，配置、会话、令牌在同机所有 Agent 之间共享——这是 MCP 客户端生态里目前少见的完整度。

第二是渐进式工具发现。 mcpc grep <pattern> 可以在所有活跃会话的工具与指令中检索，只把相关的拉进上下文。工具数量从 5 个涨到 500 个时，这是唯一可行的路。

第三是给 AI 沙箱用的代理模式。 mcpc proxy 会把 MCP 服务器连接包一层，把凭据留在本地、只让沙箱里的代码看到受控的出口。README 里专门引用了一份 2026-09 的安全评审文档，说明这条链路是经过审视的。

上手门槛：比想象中低，但有前提

mcpc 是纯 CLI，没有 Web UI。安装只要一条命令：

brew install mcpc
# 或者
npm install -g @apify/mcpc

要求 Node.js >= 22.12 或 Bun。凭据默认走操作系统钥匙串（macOS Keychain / Linux Secret Service），无头服务器上回落到 ~/.mcpc/credentials.json（权限 0600）。

真正上手要注意的是语法。它用 arg:=value 表示键值参数（注意是 := 而不是 =），这跟大多数 CLI 的习惯不同：

mcpc @test tools-call search-actors keywords:="website crawler"

--json 模式输出结构化结果，可以直接接 jq、xargs 组成 shell 流水线，这是它被称为"code mode 客户端"的核心原因。

争议与局限

需要客观指出几个问题：

1. 本质是"外壳"，不是智能体。 mcpc 自己不调用任何 LLM（对比表里 LLM 一栏它是唯一的"—"）。它提供的是给 Agent 用的接口层，能力上限取决于你接入的模型。
2. := 语法是自定义约定。 Agent 偶尔会写成 = 导致参数被误解析为位置参数，好在错误信息做得比较到位。
3. 版本迭代非常激进。 当前 npm latest 是 0.7.0，同时 0.8.0-beta.2 已在分发，协议版本本身也在 2026-07-28 这样的大版本间跳跃。生产环境锁定版本是必要的。
4. 社区规模仍小。 22 位贡献者（其中还包括 renovate 与 claude 机器人），约 805 次提交，主要由作者一人驱动。相对 IBM/mcp-cli 这类有企业背景的项目，长期维护的确定性要弱一些。
5. x402 支付功能标注为实验性，涉及真实资金，不建议在未充分测试时使用。

行业意义：CLI 作为 Agent 与 MCP 之间的中间层

mcpc 折射的是 2026 年 AI 工程的一条清晰趋势：工具调用的接口正在从"函数调用"向"代码执行"迁移。Anthropic 的 code mode 博客、Cloudflare 的 code mode 实现、Cursor 的动态上下文发现，加上 mcpc 自己的实践，共同指向同一个结论——把能力交给 Agent 时，一个通用编程接口胜过几十个专用函数。

有意思的是 mcpc 把 MCP 从"远程标准接口"重新拉回"本地命令行接口"的形态：MCP 依然负责服务发现、认证、支付和权限控制这些远程治理问题，而 CLI 承担 Agent 侧的实际交互。两者的分工不是替代，而是互补——正如作者在 Motivation 里写的："CLI 是 Agent 与 MCP 之间完美的本地接口。"

从发布节奏看（创建于 2025-12，至今约 10 个月，1073★、103 fork、29 open issues、latest 0.7.0），这个由商业公司孵化、协议跟进最紧的项目，很可能成为 MCP CLI 赛道的事实标准之一。

结论

如果你需要手动调试 MCP 服务器、想用 shell 脚本编排 MCP 工作流，或者希望给 Agent 一个"万能 Bash 入口"而不是几十个函数——mcpc 值得装一个试试。它用最小依赖换来了目前最完整的协议覆盖，代价是自定义语法和仍偏早期的版本成熟度。

npm install -g @apify/mcpc
mcpc login mcp.apify.com
mcpc connect mcp.apify.com @test
mcpc @test tools-list