When it comes to MCPs, everything we know about API design is wrong (blog.fsck.com)

Anthropic Claude Code user built a lightweight Chrome MCP called superpowers-chrome after running into major practical limits with existing browser MCPs (notably Microsoft’s Playwright and similar Chrome MCPs). The Playwright MCP ships ~21 fine-grained tools and already costs ~13,678 tokens of context just to load; its tools can return entire DOM snapshots that exceed response token limits, causing repeated failures. The author initially tried driving Chrome with raw DevTools JSON‑RPC and then a small chrome-ws CLI “skill” (zero dependencies) — both token‑efficient but cumbersome because each browser action required a manual shell approval. That led to building a compact MCP optimized for LLMs: a single, stateful use_browser-style endpoint (action, selector, payload) with progressive disclosure, auto-starting browser/tabs, CSS or XPath selectors, and conventions like appending “\n” to submit forms. The full MCP config weighs only ~947 tokens at startup. The significance is design‑level: APIs for LLMs should prioritize human-friendly, forgiving interfaces over strict, rigid RPC hygiene. Good names, descriptive guidance, implicit state, error‑recovery behavior, and the ability to return partial/related results make tools far more usable to models that are “undertrained” about your API. superpowers-chrome is an example that trades pure RPC orthodoxy for practical robustness and token efficiency, showing that small, pragmatic MCPs can outperform monolithic, exhaustive toolsets when driving real-world web tasks.