Skip MCP: Tiny Bash + Puppeteer Tools Beat Bloated Browser Dev Servers

Instead of using heavy MCP servers for browser devtools, the author shows how a handful of tiny Bash-invoked Puppeteer scripts (Start, Navigate, Evaluate, Screenshot) can do the job more efficiently. This approach slashes token usage, improves composability, and lets you customize or add tools (like a DOM picker or cookies extractor) in minutes. A simple setup and README make it reusable across agents without the overhead of MCP.

Key Points

• MCP servers for browser automation are often bloated, token-hungry, hard to extend, and not composable across tasks.
• A minimal toolkit (Start, Navigate, Evaluate JS, Screenshot) built with Puppeteer Core and invoked via Bash can cover most browser-agent workflows.
• Relying on the model’s knowledge of Bash and code plus a short README (≈225 tokens) dramatically reduces context cost and confusion.
• CLI tools are composable: outputs can be saved, chained, and reformatted without routing everything through the model’s context.
• It’s trivial to extend with custom tools (e.g., an interactive DOM element picker or a cookies extractor) tailored to the task at hand.

Sentiment

The community is cautiously skeptical of MCP while acknowledging its legitimate use cases. About a quarter strongly agree with the article that MCP is unnecessary overhead, a fifth actively defend MCP's value, and the largest group takes a nuanced position recognizing that the right choice depends on context. The overall trend shows HN shifting from initial MCP enthusiasm toward pragmatic assessment — the article resonated because it challenged premature standardization and championed simplicity, but defenders offered credible counterarguments about distribution, multi-user needs, and standardization value.

In Agreement

• MCP servers waste massive amounts of tokens and pollute context windows, making agents less effective compared to tiny README-based tool descriptions
• LLMs are already trained on CLIs, APIs, and code patterns, so agents work better with familiar interfaces than with MCP tool descriptions that aren't in their training data
• Code-based approaches enable true composability where tool outputs can be piped, saved to disk, and chained without flowing through the model's context
• Simple CLI tools with good help output work as well or better than MCP for developer workflows, as demonstrated by multiple commenters' real-world experience
• Markdown-based approaches like READMEs, Makefiles, and bash aliases serve as lighter-weight tool descriptions that agents can read and follow effectively

Opposed

• MCP provides real standardization value as an RPC protocol for LLMs, and standardization benefits accrue over time across the ecosystem
• MCP excels at credential encapsulation, keeping API keys out of the model context and handling authentication securely for remote services
• Non-technical users benefit from MCP's discoverability and plug-and-play nature since not everyone can write custom Puppeteer scripts or bash tools
• Token overhead criticisms apply to any tool-calling approach, not MCP specifically, so the problem is tool design rather than the protocol itself
• MCP enables distribution and multi-user scenarios where local scripts fail, allowing tools to be shared without relying on users' local environments
• MCP has forced vendors to clean up APIs and think about usability, creating positive ecosystem effects beyond the protocol itself