Having built my company's MCP server, I have a deeper appreciation for how important well-defined tools can be. It is clear to me that tool availability and coordination is going to be a top (or THE top) focus in the near future, more important than the model itself.
If you ever look at how an LLM greps through a codebase, pulling small slices at a time to gather what it needs, you have a sense of how precise tools can broaden a model's capabilities. If I had today's Sonnet with tooling from 5 years in the future, I expect it would beat Fable 5.2 hands down - that's how dramatic the difference is.
Anthropic/OpenAI have really buried the lede about tooling, baking it into their harnesses and trying to force lock-in. We are still in the AOL days of the internet right now.
In addition to regular unit tests, we use Playwright to test our Electron app and also allow agents to drive our app using Playwright via MCP to validate their work or investigate bugs.
Based on past experience of the extreme fragility of testing against the DOM, I had Claude build an "automation API" for generally interacting with our app. Instead of LLMs needing to have Playwright click buttons or manually fill in forms or things like that, it instead executes scripts against a well defined API which we have our Angular "controllers" attach themselves to on "load" and then detach from on "unload".
So LLMs use pure JavaScript via the API and don't really need to use the DOM to interact with the app, but will do snapshots of the DOM as needed when investigating any bugs or visual issues.
This has worked very well for us, the API (like the rest of our app) is in TypeScript which means that we have a whole bunch static type safety automatically preventing regressions.
A gap in this approach is that the views themselves aren't really tested, we're e.g. testing that the logic called on pressing a button does all the right things like transition the system to new screens, etc, but not that the view is correctly bound to the button. In practice though, we've very rarely found situations where we wished we had automated testing the HTML of a view.
Does any of these handle the case where the site needs you to pass a bot detection that fails if the browser is remote controlled and so need a human to access the same profile via a non-remote controlled browser first?
That's what's stopping me from using most of these things instead of just having the agent drive a browser directly with lower level integrations.
Benchmark for the end 2 end browser tasks…. The other options operate at a different level of abstraction where the actions space also reduce token usage and latency…
Hi HN, I built turbo-browser-mcp (MIT, Node >= 20, playwright-core only) after running multi-step browser agents over MCP and hitting three practical issues: full DOM/accessibility snapshots filling the context window past 90k tokens, 10+ sequential turns per form (plus freezes when agents tried to pass uploaded files as Base64 tool arguments), and occasional accidental clicks on Publish or Submit buttons.
Instead of one MCP call per click or keystroke, it exposes 10 consolidated tools:
- `inspect_compact`: traverses main frame, iframes, and open Shadow DOM (`el.shadowRoot`), stamps `data-tbm-ref` IDs (`f<frameIdx>:e<N>`), caps at `maxChars` (default 4000), and supports `onlyChanged: true` deltas.
- `smart_fill_form`: fills React controlled inputs (native prototype setter + `_valueTracker.setValue`), `contenteditable`, single/multi selects, sliders, ARIA comboboxes, and disk files (`setInputFiles` / `filechooser`) in one turn, with `returnSnapshot: true` to fold the updated DOM into the same response.
- `allowSubmit=false` guard by default across clicks, viewport `{x, y}` clicks (checked via element-at-point), and Enter keys unless `allowSubmit: true` or `--allow-submit` is set.
- `tabs_batch` (`open_many`, `isolatedContext`, `emulate`), `network_session` (`turbo` resource blocking preset, cookies/storageState, route mocks), `page_diagnostics` (console, HTTP filters, downloads), `extract_clean_text`, `evaluate_js`, and `capture_page`.
On the included headless Chromium suite (`npm run benchmark`, exact `tiktoken o200k_base` counts):
- 140-button SaaS toolbar DOM: 18,654 tok HTML (3,568 tok Playwright ARIA) -> 1,135 tok compact (28 ms), or 56 tok on `onlyChanged: true` delta (98.4% smaller than ARIA).
- 10-field complex form + snapshot: 11 sequential turns (574 ms, 12,197 direct / 72,614 cumulative replay tok) -> 1 turn (82 ms, 811 tok, 7x faster, 98.9% cumulative tokens saved).
- 48 KiB PDF upload via disk path vs inline Base64 tool arg: 44,728 tok -> 85 tok (99.8% saved).
- Open 6 tabs (`60 ms` simulated TTFB): 998 ms sequential (6 turns) -> 420 ms parallel `open_many` (1 turn, 2.38x faster); `turbo` media blocker runs 1.53x faster (252 ms -> 165 ms) with 100% media bytes skipped; Markdown article extraction & error-filtered diagnostics save 95.7% and 82.6% tokens respectively.
Attaching via `--mode cdp` reuses an existing Chrome session; `--mode launch` starts a clean Playwright window. Looking for feedback on the 10-tool shape, missing Chrome DevTools diagnostics, and form controls that still trip up programmatic prefill.
Whoa, this looks incredible.
Having built my company's MCP server, I have a deeper appreciation for how important well-defined tools can be. It is clear to me that tool availability and coordination is going to be a top (or THE top) focus in the near future, more important than the model itself.
If you ever look at how an LLM greps through a codebase, pulling small slices at a time to gather what it needs, you have a sense of how precise tools can broaden a model's capabilities. If I had today's Sonnet with tooling from 5 years in the future, I expect it would beat Fable 5.2 hands down - that's how dramatic the difference is.
Anthropic/OpenAI have really buried the lede about tooling, baking it into their harnesses and trying to force lock-in. We are still in the AOL days of the internet right now.
In addition to regular unit tests, we use Playwright to test our Electron app and also allow agents to drive our app using Playwright via MCP to validate their work or investigate bugs.
Based on past experience of the extreme fragility of testing against the DOM, I had Claude build an "automation API" for generally interacting with our app. Instead of LLMs needing to have Playwright click buttons or manually fill in forms or things like that, it instead executes scripts against a well defined API which we have our Angular "controllers" attach themselves to on "load" and then detach from on "unload".
So LLMs use pure JavaScript via the API and don't really need to use the DOM to interact with the app, but will do snapshots of the DOM as needed when investigating any bugs or visual issues.
This has worked very well for us, the API (like the rest of our app) is in TypeScript which means that we have a whole bunch static type safety automatically preventing regressions.
A gap in this approach is that the views themselves aren't really tested, we're e.g. testing that the logic called on pressing a button does all the right things like transition the system to new screens, etc, but not that the view is correctly bound to the button. In practice though, we've very rarely found situations where we wished we had automated testing the HTML of a view.
Hmm you should really benchmark against
https://github.com/browser-use/browser-harness https://github.com/anomalyco/browse https://github.com/vercel-labs/agent-browser
The answer is very likely not a MCP server. browse (anomalyco) is relatively new; but the other 2 are battle tested in production….
Does any of these handle the case where the site needs you to pass a bot detection that fails if the browser is remote controlled and so need a human to access the same profile via a non-remote controlled browser first?
That's what's stopping me from using most of these things instead of just having the agent drive a browser directly with lower level integrations.
None of these do the same thing as the posted MCP. It’s about batching and diff/deltas to reduce token usage and latency.
Benchmark for the end 2 end browser tasks…. The other options operate at a different level of abstraction where the actions space also reduce token usage and latency…
The AI slop is total, and the comments here are pure cinema or bots
Hi HN, I built turbo-browser-mcp (MIT, Node >= 20, playwright-core only) after running multi-step browser agents over MCP and hitting three practical issues: full DOM/accessibility snapshots filling the context window past 90k tokens, 10+ sequential turns per form (plus freezes when agents tried to pass uploaded files as Base64 tool arguments), and occasional accidental clicks on Publish or Submit buttons.
Instead of one MCP call per click or keystroke, it exposes 10 consolidated tools: - `inspect_compact`: traverses main frame, iframes, and open Shadow DOM (`el.shadowRoot`), stamps `data-tbm-ref` IDs (`f<frameIdx>:e<N>`), caps at `maxChars` (default 4000), and supports `onlyChanged: true` deltas. - `smart_fill_form`: fills React controlled inputs (native prototype setter + `_valueTracker.setValue`), `contenteditable`, single/multi selects, sliders, ARIA comboboxes, and disk files (`setInputFiles` / `filechooser`) in one turn, with `returnSnapshot: true` to fold the updated DOM into the same response. - `allowSubmit=false` guard by default across clicks, viewport `{x, y}` clicks (checked via element-at-point), and Enter keys unless `allowSubmit: true` or `--allow-submit` is set. - `tabs_batch` (`open_many`, `isolatedContext`, `emulate`), `network_session` (`turbo` resource blocking preset, cookies/storageState, route mocks), `page_diagnostics` (console, HTTP filters, downloads), `extract_clean_text`, `evaluate_js`, and `capture_page`.
On the included headless Chromium suite (`npm run benchmark`, exact `tiktoken o200k_base` counts): - 140-button SaaS toolbar DOM: 18,654 tok HTML (3,568 tok Playwright ARIA) -> 1,135 tok compact (28 ms), or 56 tok on `onlyChanged: true` delta (98.4% smaller than ARIA). - 10-field complex form + snapshot: 11 sequential turns (574 ms, 12,197 direct / 72,614 cumulative replay tok) -> 1 turn (82 ms, 811 tok, 7x faster, 98.9% cumulative tokens saved). - 48 KiB PDF upload via disk path vs inline Base64 tool arg: 44,728 tok -> 85 tok (99.8% saved). - Open 6 tabs (`60 ms` simulated TTFB): 998 ms sequential (6 turns) -> 420 ms parallel `open_many` (1 turn, 2.38x faster); `turbo` media blocker runs 1.53x faster (252 ms -> 165 ms) with 100% media bytes skipped; Markdown article extraction & error-filtered diagnostics save 95.7% and 82.6% tokens respectively.
Attaching via `--mode cdp` reuses an existing Chrome session; `--mode launch` starts a clean Playwright window. Looking for feedback on the 10-tool shape, missing Chrome DevTools diagnostics, and form controls that still trip up programmatic prefill.