You ask Claude Code to log into a SaaS dashboard, scrape a table, and email the result. It opens the Playwright MCP server, takes a screenshot, navigates, takes another screenshot, clicks a button, takes another screenshot. Forty turns in, the agent stops mid-task with "context limit reached." Your usage dashboard shows you just spent 180,000 input tokens on what should have been a 30-line script. This isn't a bug in MCP. It's the shape of MCP token usage when the tool happens to be a browser. E

What Is MCP Token Usage and Why Does It Matter for Browser Tasks?

MCP token usage is the count of input and output tokens an LLM consumes when it interacts with a Model Context Protocol server. Every tool call sends three things into the model's context: the tool's description schema, the arguments the agent picks, and whatever the tool returns. For most MCP servers — a database adapter, a Git wrapper, a Linear client — the return value is a few hundred tokens of JSON. For a browser MCP server, the return value can be a 1.5 MB PNG screenshot, a 30 KB accessibility tree, or a full DOM dump.

That asymmetry is the entire problem. The Anthropic and OpenAI pricing pages don't separate "browser MCP tokens" from "regular MCP tokens" — but on a real workload, the browser variant is 5-10× more expensive. And it gets worse: every screenshot stays in the conversation context for the rest of the session, which means turn 20 is paying for turn 3's screenshot all over again, every single API call.

If you're using Claude Code, Cursor, Codex, Roo Code, or any other agentic IDE with Playwright MCP or Chrome DevTools MCP, this is the dominant line item on your bill — and the dominant reason your agent gives up halfway through long tasks.

Where the Tokens Actually Go

Most "reduce MCP token usage" advice is generic ("be concise", "use dynamic toolsets") and doesn't break down what's specific to browsers. Here's what we see when we audit a real Claude Code session running Playwright MCP for 40 turns:

That last row is the punchline. The model is doing 3-8% of useful thinking and 92-97% of re-reading its own browser history. Reducing MCP token usage is mostly an exercise in cutting the cost of carrying that history forward.

Pro Tip: Open your last long Claude Code or Cursor session and check the input-token count on the final turn. Compare it to the total tokens spent. If the ratio is above 4:1, you're paying for screenshot replay, not reasoning.

Why Screenshot-Heavy Loops Burn Context Fastest

A 1280×720 PNG screenshot through Claude's vision API encodes to roughly 1,600 input tokens. A 1920×1080 screenshot encodes to about 2,400. That's already 4-6× the cost of a typical text tool result. But the real damage is compounding.

When Playwright MCP returns a screenshot, the screenshot is not "consumed" after the agent reads it. It stays in the conversation history as a base64-encoded image attached to that turn. Every subsequent API call sends the entire history back, which means:

• Turn 1: 1 screenshot in context = 2,400 tokens
• Turn 5 (4 more screenshots): 5 screenshots in context = 12,000 tokens
• Turn 20 (15 more screenshots): 20 screenshots in context = 48,000 tokens
• Turn 40: 40 screenshots in context = 96,000 tokens

By turn 40, the agent is paying 96,000 tokens every turn just to re-read images it already understood and acted on 30 turns ago. This is the core mechanic behind AI agent context bloat in browser workloads, and it's why Playwright MCP token costs feel non-linear: doubling the task length quadruples the bill.

The same loop in a non-browser MCP server doesn't have this shape. A database MCP returning JSON results gets compacted by the model's reasoning layer — the agent extracts the row it cares about and the rest fades out of attention. Screenshots resist that compaction because the model can't easily summarize an image into a token-cheap form on the fly.

The "wait for visible" anti-pattern

The most expensive habit we see in browser agent code is using screenshots as a substitute for explicit waits. The agent calls browser_navigate, then browser_screenshot, then reasons about whether the page has loaded, then calls browser_screenshot again. Each retry doubles the screenshot tax. A wait_for_selector call returning a single boolean costs 12 tokens. The screenshot-and-look-again pattern costs 2,400+ per attempt.

Tool Description Overhead: The Quieter Cost

Even before any browser action runs, the model has already paid for tool descriptions. Playwright MCP exposes 25+ tools by default — browser_navigate, browser_click, browser_type, browser_screenshot, browser_press_key, browser_wait, and so on. Each tool ships with a JSON schema describing its parameters, often 200-500 tokens per tool. That's 5,000-12,000 tokens loaded every single API call just to remind the model that these tools exist.

Speakeasy reported a 100× reduction by lazy-loading tool definitions for OpenAPI servers. The principle applies to browser MCP, but few browser servers implement it yet. Until they do, the practical move is to disable tools you don't need in your MCP config:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp", "--enable-tools=navigate,click,type,wait_for_selector,evaluate"]
    }
  }
}

Cutting from 25 tools to 5 saves 4,000-9,000 tokens per turn. Over a 40-turn session, that's 160K-360K tokens you're not paying for.

Pro Tip: Most agentic IDEs let you scope MCP tool exposure per workspace. If you only do form-filling tasks in one project, configure that project to expose four tools, not twenty-five. Claude Code's .mcp.json and Cursor's mcp.json both support this.

Pattern 1: Replace Screenshots With Targeted DOM Queries

The first lever is the highest-impact one: stop returning screenshots when you don't need vision.

Browser MCP servers default to screenshots because they're idiot-proof — the model can always read pixels. But on most production tasks, you don't need pixels. You need to verify a selector exists, extract a string, or confirm a navigation succeeded. All three are answerable with a 50-token text return.

The rule we use: screenshots are a debugger, not a sensor. Use them when you genuinely don't know what's on the page and need the agent to reason visually. Don't use them as confirmation-of-action.

In Playwright MCP, the cheap-by-default tools are browser_evaluate (run a JS snippet, return a string) and browser_wait_for_selector (return when a selector appears). Build your prompts to prefer these. If you can't constrain the model through prompting, configure the MCP server to disable browser_screenshot entirely on tasks that don't need visual reasoning — most do not.

Pattern 2: Use a CLI for Repeatable Operations, MCP for Exploration

This is the pattern that flips the economics. MCP is great when the agent is exploring — it doesn't know the page structure, can't predict the right selectors, and needs to react turn-by-turn. MCP is terrible when the agent is executing — it knows exactly what to do, and the per-turn screenshot tax becomes pure waste.

The fix is to keep MCP for the discovery phase, then collapse the execution phase into a single CLI call. A CLI command returns one tool result with the final state. Forty turns of MCP collapse into one turn of CLI:

The BrowserAct CLI is one example of this pattern: the agent uses MCP to figure out what to do, then commits the workflow to a single CLI invocation that executes headlessly and returns one consolidated result. Vercel's agent-browser, microsoft/playwright's --save-trace mode, and any custom wrapper that emits one summary instead of N screenshots work the same way.

Pro Tip: When you find yourself running the same MCP sequence twice in a session, that's the signal to extract it into a CLI command. Discovery is what MCP is for; rerunning known workflows is not.

Pattern 3: Compact Screenshots Before They Hit Context

If you must keep screenshots in the loop — say, for a visual-regression task or a dashboard your agent has never seen — three compaction tricks cut their cost without losing useful signal:

1. Crop to the relevant region. A full-page 1920×1080 screenshot of an admin panel where the agent only cares about a 400×300 status widget is 6× more expensive than necessary. Most browser MCPs accept a clip parameter; use it.
2. Drop screenshot resolution to 1280×720 or lower. Vision models in Claude and GPT-4o handle 1280×720 fine for UI tasks. The token cost difference between 1920×1080 and 1280×720 is roughly 40%.
3. Convert to JPEG with quality 70-80. PNG is lossless and 2-3× larger. JPEG at 75% quality still reads correctly to the model on UI screenshots.

A naive 1920×1080 PNG screenshot is 2,400 tokens. A 1280×720 JPEG at quality 75 cropped to the relevant region is often 600-900 tokens — a 60-75% reduction with no functional loss.

Pattern 4: Compile Repeatable Browser Workflows Into Skills

The end game for any browser workflow you'll run more than five times is to compile it into a skill — a named, parameterized command the agent invokes by reference instead of by step-by-step browser actions.

A skill replaces 40 turns of Playwright MCP with a single tool call: run_skill("amazon_product_lookup", {asin: "B07XYZ"}). The skill itself runs as backend code (a Playwright script, a CLI wrapper, an API call) and returns just the structured result. The agent's context never sees the navigations, the screenshots, or the intermediate DOM — only the final JSON.

This is the pattern behind ClawHub and similar AI-agent skill marketplaces: instead of agents reinventing browser automation every session, they call pre-built skills that have already solved the navigation, the captchas, the login state, and the data extraction. From the agent's perspective, the Amazon Product API is a 50-token tool call that returns a structured product object. From the cost perspective, it's the difference between $0.02 and $2.00 per query.

The same idea applies to internal workflows. If your team runs the same "scrape competitor pricing across 5 SaaS landing pages" routine weekly, build it once as a skill, then have the agent call it. You stop paying for browser automation tokens entirely; you pay for the structured output the skill emits.

When to Stop Optimizing

A common failure mode is over-engineering token reduction on workloads that don't justify it. If your agent runs once a week, takes 20K tokens, and produces a result you actually use, the dollar amount is rounding error. Don't refactor.

The patterns in this guide pay off when:

• You're hitting context-window limits mid-task (the structural problem)
• You're running the same workflow more than 10×/week (the economic problem)
• You're shipping a product where users pay per-task and your margins are MCP-token-heavy (the business problem)

If none of those apply, the right answer is to leave Playwright MCP on, accept the cost, and revisit when the workload changes.

Comparison: MCP vs CLI vs Skill for Browser Automation

For teams making the call between approaches, here's how the three patterns stack up on the dimensions that matter for production browser automation token cost:

The decision tree we'd give a team starting today: explore with MCP, productize with CLI, scale with skills. Each step takes you from "expensive but flexible" to "cheap but specific."

Key Takeaways

• Browser MCP servers cost 5-10× more tokens than non-browser MCP servers, mostly because every action emits a screenshot or DOM snapshot that stays in context forever.
• Screenshots in conversation history compound: turn 40 pays for every screenshot from turns 1-39 on every API call. This is why MCP token usage feels non-linear in browser tasks.
• Disabling unused MCP tools cuts 4,000-9,000 tokens per turn just from schema overhead.
• For repeatable workflows, switching from MCP to a CLI cuts 80-95% of token cost; switching to a compiled skill cuts 99%.
• Use MCP for exploration, CLI for production, skills for high-volume — don't try to do all three with one tool.

Conclusion

Reducing MCP token usage in browser automation isn't about writing terser prompts or tweaking model parameters. It's about choosing where in the loop the browser state lives. When it lives in the agent's context window, you pay for it forever. When it lives in a CLI process or a skill backend, you pay for it once.

The teams shipping production browser agents in 2026 aren't using Playwright MCP for everything — they're using it for the 5% of work that genuinely needs an exploring agent, and they've moved the other 95% into CLI commands and skills that the agent calls by name. The token bill drops by an order of magnitude, the context-window failures stop, and the agent gets faster because it's no longer re-reading 40 screenshots on every turn.

If your agent is hitting context limits on real browser tasks, the fastest experiment is to swap one repeated MCP sequence for a single BrowserAct CLI call and measure the difference. You'll see the bill drop the same day.