Fixed browser tools are safer and hit a wall: a multi-step interaction becomes a dozen round trips, each carrying the page state back into the model's context, and anything the tool author did not anticipate is simply unavailable. Handing over the Browser instance removes the wall entirely — a login flow, a scrape with retries, a wait on a custom condition is one call. What you give up is any boundary on what the code does, since arbitrary JavaScript with a browser handle can navigate anywhere and read anything the browser can. That is a reasonable trade for a local development machine and a poor one for anything shared, and it is worth deciding which you have before attaching it.
A browser automation server that takes the opposite approach from the usual one: rather than exposing predefined actions, it exposes a single execute tool that runs arbitrary JavaScript in a Node VM with the Puppeteer Browser instance as a global.
- execute runs your code with `browser` in scope and `return` for the result, so a whole workflow is one call rather than a sequence of round trips.
- The full Puppeteer API is reachable, including the parts a fixed tool set never covers — request interception, frame handling, evaluating in page context, waiting on arbitrary conditions.
Nothing to supply. The code runs on the machine the server runs on, with a real browser attached.
One command — npx pptr-mcp