Until now, a coding agent debugging a webpage has been working blind. It writes the CSS, but it can’t see how the page renders — so you become the sensor: you open the console, copy the error, paste a screenshot, relay the DOM. WebKit’s Safari MCP server cuts you out of that relay by connecting the agent directly to a browser window — DOM, network requests, screenshots, console output — over Model Context Protocol.

The interesting part isn’t the demo, it’s what it does to the agent loop. An agent’s tool use is only as good as the observation it gets back, and browser state has been the hardest observation to feed it. Give the agent its own eyes and the human stops being the bottleneck in the see-fix-verify cycle. That’s the same pattern I keep hitting in production agentic work: the model was rarely the limit; the missing sensor was.

But raw browser access is a double-edged tool surface. A DOM dump can be hundreds of kilobytes, a screenshot is thousands of tokens, and “debug more autonomously” quietly assumes the agent knows when to stop looking. Without a tight contract on what each call returns, you trade the human-relay tax for a context-budget tax — and an agent that re-screenshots the same broken layout five times isn’t autonomous, it’s stuck in a more expensive loop. The eval question the HN thread mostly skips: not can the agent see the page, but does giving it sight actually raise the fix-on-first-try rate, or just the token bill?

My bet: the teams that win with this won’t be the ones that expose the most browser state — they’ll be the ones that expose the least the agent needs to close the loop. What’s the smallest observation that would’ve saved your last debugging round?