MCP 为何从一开始就是个错误
Why MCP Was Always a Bad Idea
我参加了一场关于 MCP 的全天活动，虽然演讲者充满热情，但我已对 MCP 感到疲惫。MCP 是为早期不够聪明的 LLM 设计的协议，如今我们已超越它。随着大模型能力增强，它们能直接调用 API、编写脚本，甚至通过 `--help` 发现 CLI，不再依赖 MCP 服务器。许多远程 MCP 服务器只是对现有 API 的包装。现在，拥有终端访问权限的 Agent 能替代大部分 MCP 服务器。我们应转向标准化 HTTP API 和 CLI，利用 `Accept: text/markdown` 等机制优化交互。MCP 已是过去式，是时候让它退休了。
MCP 是为 LLM 还不够聪明的时代设计的糟糕协议，而我们已经超越了它。
HN 评论区
81- simonw
这篇文章完全忽略了 MCP 当下带来的价值。
没错，如果你运行的是全功能的终端代理（如 Claude Code、Codex、Meta Muse、OpenClaw 等），并且拥有不受限制的互联网访问权限，那确实几乎没有理由使用 MCP——直接让它调用 API 就行了。
但如果你想构建一个比那种“YOLO”（孤注一掷）模式更稳健的系统，你会发现自己需要：
1. 精确控制它能访问哪些外部服务
2. 一种认证处理方式，不让代理直接获取 API 密钥
3. 一个合理的 UI，让用户能够连接并认证更多服务
4. 强大的审计日志，记录正在发生的一切
MCP 让提供所有这些功能变得容易得多。
认为 MCP 已过时，仅仅是因为全功能代码代理不需要它，这就忽略了我们要构建的其他所有东西。
- zacksiri
CLI、API 和 MCP 都是有用的连接方式。这取决于你的具体用例。我都用过这三种，发现它们各有优势。
当你只需要一种开箱即用、出错率低的原生方式让代理调用你的服务时，MCP 非常棒，这在某些场景下特别适用。
我还开发了一种基于 MCP 的新方法，称为 ADP（Agent Delegation Protocol，代理委托协议）。它构建在 MCP 之上，其中 MCP 只有一个工具；当代理想要执行某项操作时，只需发出自然语言命令，ADP 引擎就会处理其余部分，包括路由等……将任务分发给正确的子代理，执行任务并返回结果。（稍后会有更多介绍）。
在内部，如果你有一个良好的编排系统，就不需要 MCP，可以直接使用 API，但这些 API 应该是为代理设计的，即基于 DSL，并映射到内部操作。我也是这么做的。
CLI 非常适合测试，但代理经常会出错；它非常适合实验，看看哪些功能开箱即用，哪些不行。
对我而言，完美的方案是 MCP 和 API 的混合体。如果设计得当，API 的成本很低；如果你的工作流是 DAG（有向无环图），那么 API 尤其好用，因为你已经有了确定性的流程，这意味着你可以使用小型 LLM，甚至像 Jev 这样的工具。
所以我的总结是：
CLI - 适合开箱即用、众所周知的功能，以及需要验证输出的场景
API - 适合低成本、大批量、高度重复且需要高可靠性的工作流（注：原文此处截断）
- whazor
MCP 之所以胜出，是因为在 ChatGPT 和 Claude 应用中都有插件商店。这些插件是一键安装的 MCP 服务器，并支持认证。这正是企业用户正在使用的模式。
- doctaj
这与我的经验不符。昨天，我使用 Microsoft 的 Power BI Authoring MCP，从一些 SQL 或 CSV 文件中构建语义模型。那简直太神奇了。
Microsoft 已经在 MCP 中定义了如何做到这一点。将 MCP 添加到机器上非常简单，执行也非常可靠。
替代方案似乎是让模型直接从其文档网站获取文档。如果是这种情况，那么 MS 可能拥有很好的文档，并且可能支持该 Markdown 标题……但这一切都取决于在互联网上找到特定的网页？在我看来，这比 MCP 糟糕得多。
- AndrewDucker
这不仅仅是代理理解 API 的问题，还在于限制它们的访问权限。如果我想以 API 未锁定的特定方式授予对内部服务的访问权限，那么一个提供非常具体查询、并具备保护控制和转换机制的 MCP 就非常有用。