How Accessibility Tree Formatting Affects Token Cost in Browser MCPs

Token cost in browser automation MCPs has become a real topic — articles like "Playwright MCP Burns 114K Tokens Per Test" have been making the rounds. Tools are approaching this from different angles: Playwright MCP's --output-mode file option saves snapshots to disk instead of returning them in LLM context, Vercel's agent-browser compresses DOM state to a fraction of the original, and some tools add vision-based fallbacks for layout understanding. I've been working on WebClaw , an open-source Chrome extension-based browser MCP. It takes the accessibility tree approach like Playwright MCP, but with a more compact format. I wanted to measure the actual difference — not guess, but measure — so I set up a side-by-side test. How I Measured Versions tested: Playwright MCP: @playwright/mcp v0.0.68 ( npx @playwright/mcp@0.0.68 --headless ) WebClaw: webclaw-mcp v0.9.0 + Chrome extension v0.9.0 Measured: February 26, 2026 I registered both Playwright MCP and WebClaw as MCP servers in the same C