For thirty years, “user” meant a person with eyes, a mouse, and patience. Browsers render pixels. DOMs are trees built for layout engines. JavaScript mostly exists to make things look and feel right to a human sitting in front of a screen. Now a second kind of user is showing up — agents — and they don’t need any of that.
Why should you care? Cloudflare marked this year as the moment bot and agentic traffic passed human traffic online for the first time in the internet’s history — its Radar data now shows roughly 57% of web requests coming from automated systems, a crossover CEO Matthew Prince had predicted for late 2027 (announced June 2026). It happened 18 months early, and the curve is still climbing. Yet most agents aren’t equipped to handle the modern web properly. There are two options.
A static fetch: raw HTML back, no clicks, no JavaScript, nothing beyond whatever the server sent in the first response. Or
a full headless browser: render the page the way a human’s browser would, take a screenshot, process it through an LLM, pay ten to a hundred times the tokens — and it will still be painfully slow.
All you wanted was to read and fill the form.
Modern websites are built for humans, not machines #
Even with having a perfect tool, you’d still hit a deeper problem: most of the modern web is unreadable by machines. Not for lack of precedent. Accessibility standards have existed for decades, and tools like Playwright now lean on accessibility trees for exactly this kind of agentic use. But on most websites accessibility was an afterthought, bolted on at the end if at all, so the machine-readable layer that could have been there mostly isn’t.
In addition to that, if you open the source of almost any modern web page you’ll find div soup: layers of nested, semantically empty markup whose only job is to give CSS and JavaScript something to grab. Fade-ins, scroll animations, all sorts of CSS tricks that look good but carry zero — or even negative — semantic meaning. It works for humans. For anything else trying to read the page, it’s noise at best and invisible content at worst.
The frustrating part is that none of this requires new inventions to fix. Semantic HTML has existed for years already. So has JSON-LD — a block of structured data embedded in the page that declares what it contains in machine terms, invented because search engines couldn’t infer meaning from presentation markup. Schema.org Actions extend it from describing things to describing what you can do with them. We had all of it and mostly stopped bothering once visual design became the whole priority. And now there’s WebMCP — designed specifically for agents this time, not search engines. Where JSON-LD describes what a page contains, WebMCP lets a page hand an agent actual tools: “here’s a search, here’s an order form, here’s how to call them.” Its declarative API does this in plain markup, no rendering required.
So the fix isn’t a redesigned internet. Sites need to expose what they already know about themselves in forms machines can parse, and agents need a client that actually reads those forms instead of ignoring them. Both sides have to move. I think the best way to start is with the client. It’s the one piece every agent passes through no matter which site it’s hitting, and it’s the piece we could ship now.
What we’ve built #
Agent Navigator is a live agentic browser and MCP layer, and it’s free. It parses the DOM, but that’s where the resemblance to a browser ends: no JavaScript execution, no CSS tree rendering, no headless Chromium waiting in the background. It’s significantly lighter than headless Chrome.
What it does instead: it fetches the page, prefers server-rendered structured content, and parses JSON-LD (including Actions) and declarative WebMCP out of the box. When it finds them, it converts them into callable tools. Your agent doesn’t get a wall of markup to interpret. It gets search_catalog
, submit_order
— whatever the site declared — as tools it can invoke directly.
The obvious downside is that a non-rendering client can’t handle every site, and that’s true. It isn’t supposed to. It’s not meant to process JavaScript, CSS, or animations at all — it’s designed to extract the essential information from a page and provide the fundamental capabilities to interact with it, and nothing more. Think of it like VS Code when only JetBrains and Sublime Text existed. They were opposite ends of the code-editing spectrum: JetBrains the full-blown IDE with everything built in, Sublime the fast, minimal editor that stayed lightweight by leaving the heavy machinery out — but required a lot of customization and constant maintenance. VS Code landed in between and became the default. It handled the common case so well, so cheaply, that both extremes became the exception you reach for when you actually need them. Same approach is used here. Most pages an agent touches don’t need a browser. They need a client that takes the web for what it already is, and escalates to the heavy machinery only when there’s no other way.
How to start #
The browser is exposed via a simple MCP server. There’s nothing to install and nothing to manage — no sandbox, no session management, no browser processes to babysit.
Just connect your agent to the MCP URL and it gets six simple tools: navigate, extract, discover, call_webmcp_tool, call_jsonld_action, and submit_form
.
Give it a try and add token-mindful browser capabilities to your agent, for free: https://agent-navigator.onrender.com/mcp