Small Composable Browser Tools Outperform MCP for Token Efficiency and Developer Control
Small Composable Browser Tools Outperform MCP for Token Efficiency and Developer Control
Introduction
The debate over whether developers need full‑featured MCP (Model‑Centric Programming) servers for everyday agent tasks has intensified across AI, Twitter, and developer communities. The core question is simple: Can lightweight, composable tools that agents already understand replace heavyweight MCP manifests while saving tokens and preserving flexibility? This article examines a minimalist toolkit built around Bash and tiny Node scripts, compares it to popular MCP implementations, and outlines practical workflows for solo developers and small teams.
Token Efficiency: The Real Cost of MCP Manifests
How MCP Consumes Tokens
Popular MCP servers such as Playwright MCP and Chrome DevTools MCP ship extensive tool catalogs. For example:
- Playwright MCP – 21 tools, ~13,700 tokens (≈6.8 % of Claude’s context window)
- Chrome DevTools MCP – 26 tools, ~18,000 tokens (≈9 % of the context window)
These token counts are incurred before any actual work is performed. When multiple MCP servers are combined, the token overhead multiplies, and agents must parse verbose tool descriptions, leading to confusion and reduced composability.
The Minimal Toolkit Advantage
A lean alternative consists of a concise README (≈225 tokens) plus a handful of Node scripts that leverage Puppeteer Core. Because agents already understand Bash and JavaScript, they can invoke these scripts directly without the need for large skill catalogs. The result is a token footprint that is two orders of magnitude smaller than traditional MCP manifests, aligning with the classic Unix philosophy of small, composable tools.
Inside the Minimal Browser Toolkit
The toolkit includes six scripts, each serving a specific, well‑defined purpose.
start.js
- Launches Chrome with a fresh or cloned profile.
- Kills any existing Chrome process, creates a temporary user‑data directory, and starts Chrome with remote debugging on port 9222.
- Repeatedly attempts to connect via
puppeteer.connectuntil successful, then prints a success message.
This deterministic startup eliminates the need for complex RPC schemas and provides a simple, reliable contract for the agent.
nav.js
- Syntax:
nav.js <URL> [new] - Navigates the active tab (or opens a new tab when
newis specified) and waits for DOMContentLoaded. - Returns a clean status message such as “opened” or “navigated”.
The script mirrors the natural way agents think about page actions: “go to this page” without a proliferation of click, hover, or scroll variants.
evil.js
- Executes arbitrary JavaScript in the page context.
- Usage:
evil.js "document.querySelectorAll('a').length" - Constructs an async function, evaluates the code, and prints results as key‑value pairs (for objects/arrays) or as a scalar value.
By allowing agents to write native DOM code, evil.js removes the token overhead of describing each possible interaction and enables direct data extraction without streaming large results through the prompt.
screenshot.js
- Captures a viewport screenshot of the active page.
- Saves the image to the OS temporary directory with a timestamped filename and prints the file path.
- The agent can then read the image and apply vision models as needed.
Storing images as files rather than embedding them in the prompt drastically reduces token usage.
pick.js
- Provides an interactive visual selector.
- Displays a banner and a highlight rectangle that follows the cursor; clicking selects an element,
Ctrl/Cmd+Clickenables multi‑select,Enterfinalizes, andEsccancels. - Returns structured information for each selected element, including tag, ID, class, trimmed text, CSS selector chain, and a snippet of outer HTML.
This tool bridges human intent and code, allowing agents to generate reliable selectors for scrapers or automation scripts.
Supporting Helper Scripts
Additional utilities (e.g., a cookies helper) round out the toolkit, handling common browser tasks without expanding the token budget.
Building a Seamless Workflow
- Create a dedicated directory (e.g.,
~/agent-tools). - Clone each tool repository into this folder.
- Add the directory to your PATH via a shell alias or environment variable so the agent can invoke the scripts directly.
- Reference the README in the agent’s context only when needed, keeping the prompt lean.
- Set the tools directory as a working directory for Claude or other LLM interfaces, allowing on‑demand inclusion of tool definitions.
By following these steps, agents operate with a minimal command set, avoid constant directory changes, and eliminate the need for massive skill manifests.
When MCP Still Makes Sense
Enterprise environments often restrict raw API or filesystem access. In such cases, an MCP server can act as a guard‑rail‑enforced broker, providing:
- Role‑based permissions
- Auditable data retrieval
- Controlled exposure of internal services
However, even in these scenarios, developers should monitor the token footprint of the MCP server’s tool descriptions. A 13–18 k token manifest still consumes a noticeable portion of the context window, so keeping descriptors concise and off‑loading large outputs to files remains best practice.
Conclusion
The minimalist toolkit demonstrates that small, composable scripts can deliver the same—or greater—functionality as heavyweight MCP servers while dramatically reducing token consumption and increasing developer control. For solo developers and small teams, the recommended approach is:
- Use
start.js,nav.js,evil.js,screenshot.js,pick.js, and supporting helpers. - Keep tool definitions in a tight README and invoke them via Bash.
- Reserve MCP servers for environments that require strict governance or limited API exposure.
By embracing the Unix‑style philosophy of “do one thing well,” agents stay fast, cheap, and adaptable—precisely the qualities needed for modern AI‑augmented development.