文章探讨了是否真的需要MCP服务器，提出了使用Bash和代码工具替代浏览器开发者工具的方案，包括启动、导航、执行JavaScript、截图等功能，并分析了这种方法的优势。

标题：或许你根本不需要MCP服务器？

核心观点
本文通过浏览器开发工具的实际案例，论证了在多数场景下，直接使用Bash脚本和代码工具链比依赖多功能MCP（Multi-Capability Platform）服务器更高效。作者基于Puppeteer Core构建了仅需225 tokens描述的轻量化工具集，相比主流MCP方案节省了90%以上的上下文开销。

传统MCP服务器的痛点

1. 过度设计

   • Playwright MCP（21个工具/13.7k tokens）和Chrome DevTools MCP（26个工具/18k tokens）包含大量冗余功能
   • 占用Claude等AI模型6-9%的上下文容量

2. 扩展性差

   • 修改现有MCP需要深入理解代码库
   • 输出结果必须通过代理上下文传递，缺乏直接组合能力

极简工具链实践

作者构建的浏览器工具集仅包含4个核心功能： 1. 启动浏览器
start.js支持无痕模式或带用户配置启动（处理Chrome调试限制） 2. 页面导航
nav.js实现标签页控制，等待DOM加载完成 3. 执行JS
eval.js在页面上下文异步运行代码，智能格式化输出 4. 截图工具
screenshot.js生成时间戳命名的临时文件

技术实现
- 每个工具为独立的Node.js脚本（基于Puppeteer Core） - 通过Bash调用，天然支持管道组合 - 平均代码量<100行，输出格式可自由优化

扩展案例

1. 元素选择器
   添加交互式pick.js工具，允许用户点击选择DOM元素并返回结构化信息：

   • 支持多选（Cmd/Ctrl+Click）
   • 自动生成包含父级路径的CSS选择器
   • 输出格式与eval工具兼容

2. Cookie提取
   快速实现的cookies.js可获取HTTP-only cookies，满足特殊爬取需求

效率对比

| 指标 | 自定义工具集 | 传统MCP方案 | |---------------|-------------|-------------| | 上下文占用 | 225 tokens | 13-18k tokens | | 功能扩展速度 | 分钟级 | 小时级 | | 输出处理 | 直接文件操作 | 必须经上下文 |

系统化应用建议

1. 目录结构
   建立~/agent-tools统一存放各工具集，通过PATH环境变量集成
2. 命名规范
   使用<功能域>-<工具名>.js避免冲突（如browser-tools-eval.js）
3. 文档管理
   通过@README.md引用实现按需加载，替代自动发现机制

结论

对于特定场景的需求，轻量级CLI工具链在以下方面具有显著优势： - 上下文效率：减少90%+的token消耗 - 开发敏捷性：快速迭代定制功能 - 组合自由度：原生支持Bash管道和文件操作

完整代码库可作为实践参考，该方案同样适用于其他需要精细化控制的代理场景。

（注：本文保留了关键代码示例和技术细节，删减了部分非核心的脚本实现和推广性内容）

评论内容总结

支持MCP的观点

1. MCP作为插件平台

   • MCP为LLM公司提供插件系统，使其成为开发者构建应用/插件的平台，而非API提供者。
     引用: "MCP was created so llm companies can have a plugin system... they become the platform that we build apps/plugins for" (评论1)
   • 简化远程服务集成（如Linear、Notion），避免重复认证和API调用的额外工作。
     引用: "I like MCP for _remote_ services... Claude has the relevant access to access the remote data" (评论16)

2. 安全与便捷性

   • 封装API凭证，避免模型直接接触敏感信息；接口变更灵活。
     引用: "They can encapsulate (API) credentials... Contrary to APIs, they can change their interface whenever they want" (评论20)
   • 作为轻量网关管理认证和网络安全，适合非本地开发场景。
     引用: "MCP’s job is to manage the auth, networking, and security boundaries" (评论18)

反对MCP的观点

1. 冗余与过度设计

   • LLM已内置工具调用功能，MCP增加复杂性且缺乏主流模型支持。
     引用: "LLM's have function / tool calling built into them... No major models have any direct knowledge of MCP" (评论11)
   • 现有CLI工具（如gh、sentry-cli）和REST API已足够，无需额外抽象层。
     引用: "You only need a bash tool that can run shell scripts and cli tools!" (评论17)

2. 框架依赖与锁定风险

   • MCP类似LangChain，试图通过模糊概念绑定用户，实际未解决核心问题（如上下文管理）。
     引用: "The owners of these frameworks are incentivized to drag people into them to attain vendor lock-in" (评论14)
   • 本质是REST的重复造轮子，XML/REST已解决自描述和模式定义问题。
     引用: "MCP is yet another waste of effort trying to recreate what we had with REST over 20 years ago" (评论19)

中立/替代方案

1. 渐进式探索与CLI优先

   • 通过技能（Skills）和CLI工具实现渐进式功能扩展，更简单且可组合。
     引用: "You don’t need MCP. You need Claude Skills" (评论6)
   • 文件系统与AI CLI结合（如Agent Folder Share）提供更直接的操作方式。
     引用: "Browser → FS → AI CLI = perfection with nothing but files!" (评论9)

2. 场景化适用性

   • MCP适用于快速集成外部功能的轻量场景，但不适合需要代码执行的高自由度需求。
     引用: "MCP shines when you want to add external functionality to an agent quickly" (评论13)
   • 企业级系统可能因预定义工具集而边际效益递减，甚至引发安全问题。
     引用: "The benefits become much more marginal for enterprise AI systems... sometimes with security as a primary casualty" (评论5)

关键分歧点

• 支持方强调MCP的插件化、安全封装和低摩擦集成；
• 反对方认为其冗余、存在锁定风险，且CLI/REST更成熟；
• 中立方建议根据场景选择，或采用Skills/文件系统等替代方案。