MCP（Model Context Protocol，Anthropic 推出的模型/工具连接协议）被拿来和 CLI、REST API、OpenAPI/Swagger（REST 接口描述规范）以及 Skills（可复用的提示词/脚本工作流）比较。原帖主张 MCP 不会死，因为很多公司正在为内部服务或外部产品搭建 MCP server，让 AI agent 通过标准方式发现工具并完成鉴权。评论区则提到，一些 coding harness 已经支持 Tool Search、deferred loading 之类的按需加载机制，原文关于上下文浪费的数字因此显得过时。争论进一步扩展到企业权限、OAuth、审计、移动端和云端 agent 场景：支持者认为 MCP 让非技术用户和受控环境更容易接入服务，反对者则认为它只是给已有 API/CLI 套了一层不够优雅的包装。
评论里最强的支持点是，MCP 在企业里更像一个统一的 agent-facing 接口层：很多内部系统没有公开 API 或 CLI，但公司仍然想把它们安全地暴露给 AI agent。由于它原生支持 OAuth、用户级凭据、审计和中央管理，非技术用户也能在浏览器或移动端客户端里一键接入。多位评论提到，组织更愿意说“给这个服务开 MCP”，而不是让每个团队自己拼 CLI、脚本和鉴权。对他们来说，关键不是协议是否完美，而是能否让 agent 在受控范围内接触到原本接触不到的服务。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
另一派把 MCP 看成是给 LLM 用的 API 目录层，和 OpenAPI/Swagger（REST API 描述规范）、GraphQL，甚至一堆 CLI wrapper 本质相近。批评者认为它只是把工具描述、调用形状和少量交互流程标准化，很多能力用现有 REST、脚本或 Skills 也能做，而且更可组合、可审查。支持者则强调 MCP 不只是 tools，还包含 prompts、resources 和动态分发的交互模型，但反对者觉得这仍然是把旧东西换个名字。争论的核心不是能不能调用，而是是否值得再造一层专门给 agent 的中间协议。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
很多支持者把 MCP 的卖点放在安全边界上：LLM 只拿到预配置的工具入口，凭证和 API key 留在外层，方便做 OAuth、审计和权限回收。对企业来说，这比让 agent 直接进 shell 或乱跑 CLI 更容易过合规，也更适合给外部用户或多个团队统一发放权限。反对者认为真正的边界应该由 OS sandbox、API scopes、chroot、bubblewrap 或 seccomp 来提供，而不是靠 MCP 的 blocklist；MCP 还可能把 injection 和供应链风险带进来。于是争论从“能不能安全”变成“安全应该落在哪一层”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14]
原帖最常被反驳的点是上下文占用：不少评论指出一些 coding harness 已经支持 Tool Search 和 deferred loading，工具定义可以按需加载，文章里的 token 统计很快就过时了。即使如此，大家仍承认很多实现会把所有 schema 和大响应一股脑塞进上下文，尤其是工具数一多就很重。有人提出搜索-执行网关、子 agent、选择性启用工具，或者把复杂流程打包成更小的脚本或技能来缓解。问题因此更多落在 harness 设计，而不是 MCP 规范本身。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
不少人其实不把它看成二选一：个人或本地工作时，CLI、脚本和 Skills 更轻，也更容易和 jq、pipe、临时文件这些 Unix 工具链配合。反过来，云端 agent、手机端、浏览器里的混合使用，以及需要向非技术用户分发能力时，MCP 的标准化发现、OAuth 和集中管理就更顺手。评论里反复提到，MCP 很适合文档型服务和组织级共享，但对 AWS 这类复杂状态系统或高组合性的本地任务未必最优。更像是 API 负责底层能力，CLI 负责人工操作，Skills 负责轻量复用，MCP 负责组织级分发。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
很多评论把这篇文章看成典型的 FOMO 和营销话术：作者自己就在 MCP 相关团队，天然有动机把采用率说得很满。有人直接质疑“every company”这种说法是夸张，拿 NFT、blockchain、WAP 之类的潮流做类比，觉得这更像 mindshare 争夺而不是事实陈述。也有人指出文章没有日期、标题又带有“dead”的挑衅意味，而新版本工具链已经修掉了部分老问题。整体上，大家更像是在质疑叙事和时机，而不是认真的死亡通知。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
MCP（Model Context Protocol）: 面向 LLM/agent 的工具发现与调用协议，常用于把外部服务包装成可调用工具。
OpenAPI/Swagger: REST API 的接口描述规范，能定义端点、参数、返回值和鉴权方式。
OAuth: 授权协议，常用短期 token 让客户端代表用户访问服务，同时便于审计与撤销。
Deferred loading / Tool Search: 按需加载工具定义的 harness 机制，先搜索相关工具，再把必要的 schema 放进上下文。
Skills: 把提示词、说明和脚本打包成可复用工作流的方式，通常更适合本地或项目级使用。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。