@svpino: MCP 并没有消亡。对于那些总说“但 MCP 会在你的上下文里塞垃圾”的人,这个抱怨已经过时了:现……
摘要
为 MCP(模型上下文协议)辩护,反驳其会向上下文注入垃圾信息的批评。指出 Claude Code、Codex 和 Cursor 等现代工具已实现渐进式披露,并按需加载 MCP 工具,使该抱怨过时。作者认为 MCP 最适合需要身份验证和可发现性的云端托管平台。
MCP 并没有消亡。对于那些总说“但 MCP 会在你的上下文里塞垃圾”的人,这个抱怨已经过时了:你现在用的工具都不会受此影响。看看 Claude Code、Codex 或 Cursor:它们都实现了渐进式披露,并按需加载 MCP 工具。到了 2026 年,MCP 几乎不会触及你的上下文。对于本地代理,只要存在文件系统和 shell,命令行工具就是更好的选择。但如果你需要接入一个要求身份验证和可发现性的云端托管平台,没有什么比 MCP 更合适。我为此专门录了一个视频来解释。
相似文章
MCP已死?
对模型上下文协议(MCP)的技术批评,指出其消耗过多的上下文窗口令牌、运行可靠性低,且与现有CLI/API方法重叠。Quandri技术栈的测量显示上下文使用率达10.5%。
我从来都不是 MCP 的粉丝,也没用过它。我以前很喜欢 OpenAPI 规范,也一直很喜欢 API,但 MCP 给我的感觉和当初 GraphQL 给我的感觉一样。
一位开发者认为,MCP(模型上下文协议)重蹈了 GraphQL 的设计覆辙——冗长、难以缓存、不安全,还以拙劣的方式重复发明现有的 Web 标准——并警告称,低效的实现将让用户消耗更多 token,花费更多金钱。
Pi.dev:你们不是说不用 MCP 吗
Earendil 解释了 Pi 为何推翻此前「不用 MCP」的立场,将 Model Context Protocol 支持纳入核心,认为现代 MCP 搭配 Codemode 风格的 JavaScript 沙箱,能够解决长期存在的工具组合难题。该文还详细介绍了相关改动如何改进工具元数据、实现延迟工具加载,以及 Jev 的集成。
Kent C. Dodds:所有MCP反对者请听好!是时候承认**这个问题**值得解决,而MCP**这个方案**也足以迭代演进,而非被取代了…
Kent C. Dodds 为Model Context Protocol(MCP)辩护,认为它解决了重要问题,并且是一个值得演进而非被替代的优秀方案。
问HN:谁在生产环境中使用MCP?
一位Hacker News用户询问关于Model Context Protocol (MCP)在生产环境中的使用情况,评论中讨论了其优势以及来自现实世界应用的示例,如用户界面更新和开放数据倡议。