Building an AI Browser

When you write a protocol spec, you eventually have to test it against reality. The MCP discovery spec I'd been working on needed a client — something that would automatically discover MCP servers on websites and actually use them. No manual configuration, no hardcoded URLs. Just load a page and see what's there.

So I built one.

It Started as a Test Harness

The first version was minimal. A Chrome extension that checked /.well-known/mcp.json and /mcp.txt on every page load, logged what it found, and let me call tools from the DevTools panel. That was enough to validate that the discovery spec worked — sites that implemented it were findable, sites that didn't were correctly ignored.

But once you have discovered MCP servers surfaced in a browser, the obvious next step is connecting them to an AI. So I added a sidebar.

The sidebar turned into a proper chat interface. The chat interface needed tool permissions. Tool permissions needed an audit log. Before long I had a full browser extension: sidebar AI chat, automatic MCP discovery, a permission system, a DevTools panel showing live discovery state, and a bridge that exposed everything to external MCP clients like Claude Code.

It grew, but not gratuitously. Each addition came from actually using the previous version and running into something missing.

What Existing Solutions Don't Do

There are a few established ways to bring AI into browser interactions. I'd tried the main ones before building this.

playwright-mcp runs a headless Chromium instance and exposes browser control as MCP tools. It works well for scripted automation — filling forms, extracting data, navigating flows. But headless browsers are brittle in practice. Sites that detect automation behave differently. You lose the session state, cookies, and authentication that your real browser already has. And there's no discovery — you're controlling a browser, not browsing with AI.

Claude's official Chrome extension is a sidebar that gives Claude access to the page you're looking at. It's useful, but it's tightly coupled to Claude specifically. No MCP server discovery, no multi-model support, limited configurability.

What I wanted was different: an AI assistant that lives in my actual browser, with access to my real sessions, and that automatically picks up MCP tools from whatever site I'm on. Not headless. Not locked to one model. Not requiring any setup per site.

What Actually Works Well

The flexibility turned out to matter more than I expected.

Having the AI work inside a real browser session means it has access to things a headless browser never would — authenticated state, cookies set by login flows, first-party data that sites only serve to real logged-in users. When I navigate to a site that has an MCP server, the extension discovers it and the AI can call those tools as me, with my session. That's qualitatively different from running a headless browser alongside my real one.

The multi-model support also changes how I use it. Different tasks suit different models. Long research sessions where I want the model thinking carefully benefit from one setup. Quick lookups benefit from another. Being able to switch without leaving the browser or reconfiguring anything makes this practical for daily use in a way a single-model tool isn't.

The automatic discovery piece is what makes the whole thing feel coherent. I don't manage a list of MCP servers. I just browse. If a site has implemented discovery, the tools appear. If it hasn't, nothing changes. It's the difference between a tool you configure and a tool that works.

What I'm Still Figuring Out

The question I haven't answered yet is what the right use cases are.

There's a version of this that's primarily a power user tool — an AI assistant with full browser access for people who want to automate and extend their browsing. There's a version that's more about specific workflows: research, comparison shopping, reading through documentation with an AI that has context. There's a version that's a developer tool for building and testing MCP servers.

I'm currently using it for all three, which tells me the surface area is right but the focus isn't obvious yet. That's what the personal use period is for.

The other open question is adoption. The discovery spec only delivers value when sites implement it. Right now that means hand-picking sites to test with. At some point it either reaches critical mass or it doesn't.

Current State

The extension works. I use it daily. It's not open source yet — I want to spend more time on the use cases before opening it up, because I'd rather ship something with a clear purpose than something with broad capability and unclear value.

The discovery spec is a separate thing and is already public. If you run MCP servers, you can implement discovery today regardless of what happens with the extension.

For the protocol details, see MCP Needs a robots.txt Moment.