TL;DR
| Factor | AICODESIT browser capability | Standard MCP browser tool |
|---|---|---|
| Format | One compressed capability prompt | ~29 separate tool schemas |
| Measured size | 913 characters (~230 tokens) | ~50,000 characters (~12,500 tokens) |
| Actions covered | Open, read page, scroll, click, screenshot | Same core actions, plus many rarely-used options |
| Loaded when | Only when the Browser capability is enabled on a step | Loaded as part of the full MCP tool list |
How we got these numbers
Rather than repeat a marketing claim, we tested this ourselves. We built AICODESIT's browser agent on agent-browser, the open-source browser automation CLI from Vercel Labs — a genuinely good tool, and the same one powering the underlying automation in our own feature. We ran its MCP server locally, called tools/list, and measured the raw JSON returned:
- 29 tools in the default "core" profile
- ~50,000 characters of raw JSON tool-schema definitions
- ~12,500 tokens, by standard token-estimation (characters ÷ 4) — and that's before the model receives a single system instruction or user message
That number isn't a criticism of agent-browser itself — a general-purpose CLI reasonably exposes a large, flexible tool surface (cookies, network routing, tabs, frames, dialogs, and more) for every possible use case. The cost only shows up when all of that gets loaded into a model's context on every single call, whether the current task needs three of those tools or none of them.
What we built instead
Our agent harness takes a different approach across the board — not just for the browser tool. Instead of exposing dozens of granular tool schemas, we compress each capability (file editing, database access, search, and now browsing) into a single, purpose-written instruction block that only gets injected into the prompt when that specific capability is enabled on a step.
For the browser capability specifically, that's a 913-character, ~230-token instruction covering the five actions that actually matter for real work: open a URL, read the page's structure and colors, scroll by percentage, click an element by reference, and take a screenshot. No cookie management, no network interception, no frame or dialog handling loaded by default — because most tasks never touch them, and the ones that do can ask for more specific handling in plain language instead of a fixed schema.
Why the difference is this large
MCP tool definitions are verbose by design — each tool ships a full JSON Schema with descriptions, types, defaults, and enum values for every parameter, repeated across dozens of tools that mostly do variations of "interact with the page." A capability-prompt approach describes the same underlying actions once, in natural language, and lets the model apply that instruction across open/read/scroll/click/screenshot without re-explaining the mechanics each time.
The tradeoff is real: a full MCP tool surface gives you fine-grained access to every edge case a general-purpose browser automation tool supports. Our compressed capability trades that long tail for a fraction of the token cost on the actions that cover the vast majority of real usage — reading a competitor's page, checking colors and copy, clicking through a flow, and confirming visually with a screenshot.
Why this matters for you
- ~12,000 tokens saved before any work happens, on every single call where the browser capability would otherwise be loaded
- The savings compound across a pipeline run that opens, reads, scrolls, clicks, and screenshots in the same task
- Bring-your-own-key users pay for this directly — 12,000 fewer tokens per call is 12,000 fewer tokens billed by your model provider
Try the browser capability yourself. Start building for free →
Related: AI Browser Agent — browse, click, and screenshot real websites · AICODESIT vs Claude Code — token efficiency compared · Total control over your AI agent