Source: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/ Author: Mario Zechner Published: 2025-11-02 Saved: 2026-04-19 Title: What if you don’t need MCP at all? Site: mariozechner.at Description: Got Bash and some code interpreter? Skip MCP.
Summary
Mario Zechner argues that many popular MCP servers are too broad and token-heavy for narrow agent tasks. His example is browser automation: instead of exposing an agent to 20+ browser tools plus long tool descriptions, he prefers a tiny set of purpose-built CLI scripts for starting Chrome, navigating, evaluating JavaScript, and taking screenshots.
Key takeaways
- General-purpose MCP servers can be inefficient when the task surface is small.
- Long tool menus and verbose descriptions consume context and can confuse the agent.
- MCP outputs are less composable because results typically route back through the agent context before being persisted or combined.
- Agents already know how to use Bash and write code, so small script-based harnesses can offload complexity into editable code instead of prompt/tool schema overhead.
- Minimal tool harnesses are easy to extend with narrowly scoped additions like DOM picking and HTTP-only cookie export.
- Zechner’s recommended reuse pattern is to keep these tools in a dedicated directory, add them to PATH, and let agents read a short README on demand instead of paying the token cost every session.
Concrete example from the article
The browser-tool README shown in the post exposes just four core commands:
./start.js— launch Chrome with remote debugging, optionally using a copied logged-in profile./nav.js <url> [--new]— navigate current tab or open a new tab./eval.js 'code'— run JavaScript in the active page context./screenshot.js— capture the active viewport
The article then extends this with:
./pick.js "message"— interactive DOM element picker for faster scraper authoring- a cookies tool for reading HTTP-only cookies outside the page context
Why it matters for the wiki
This is a strong articulation of a broader design principle for coding agents: prefer thin, task-specific, composable tool surfaces when the job does not require a heavyweight generalized protocol layer. It complements existing notes here on coding-agent-infrastructure-patterns and multi-agent-workflows.
Notable claims
- Playwright MCP: 21 tools, ~13.7k tokens of tool descriptions
- Chrome DevTools MCP: 26 tools, ~18.0k tokens of tool descriptions
- The bespoke README for the browser-tools harness: ~225 tokens
Relevant excerpts
MCP servers also aren’t composable. Results returned by an MCP server have to go through the agent’s context to be persisted to disk or combined with other results.
Agents can run Bash and write code well. Bash and code are composable.
This efficiency comes from the fact that models know how to write code and use Bash. I’m conserving context space by relying heavily on their existing knowledge.