Handrive hit the Hacker News front page yesterday with 40 MCP tools for AI automation, and the Show HN comments read exactly like you would expect. People were impressed by the breadth, the ambition, the sheer coverage of integrations. And then someone asked how to use it to submit a form on their company’s internal portal. Silence.

This is the split I keep coming back to. MCP has become the default answer for “how do I connect my AI to things,” and for a specific category of problems it genuinely works well. But the category is narrower than the hype suggests, and the gap between what MCP covers and what people actually need gets wider every time I look at it.

The plumbing problem

MCP, Anthropic’s Model Context Protocol, lets you give an LLM access to external tools through a standardized server interface. Querying a Postgres database requires an MCP server. Creating GitHub issues requires a different MCP server. Slack messages, calendar events, file system access — each one is a separate integration with its own configuration, authentication, and failure modes.

So when someone builds a collection of 40 MCP tools, what they have actually built is 40 separate API integrations that each need credentials, each need a running server process, and each handle one specific backend operation. That is real engineering work and it enables real automation for developer workflows, data pipelines, infrastructure management. I do not want to dismiss it.

But notice what is missing from every MCP tool collection: anything that interacts with a web page the way a human does.

The form in front of you

I spent last Tuesday trying to update vendor information in a procurement system that my company has used for three years. The system has no public API, no webhook support, and an internal REST endpoint that requires a VPN connection plus a session cookie that expires every 20 minutes. An MCP tool cannot touch this. No API means no integration means no automation, full stop.

And this is not some obscure edge case — it is the default state of most enterprise web applications, internal tools built on platforms like ServiceNow or Oracle or custom React apps that were never designed for programmatic access, because they were designed for people sitting at browsers, which is exactly where a browser agent operates. Dassi runs in Chrome’s side panel and interacts with whatever page you have open through the DOM, inheriting your logged-in session, reading what you read, clicking what you would click. The vendor form took about 90 seconds.

Different tools for different layers

The open-source browser agent launches keep accelerating alongside MCP adoption, and I think that is because people are figuring out that these solve fundamentally different problems operating at different layers of the stack. MCP lives at the API layer, where data is structured, endpoints are documented, and authentication follows predictable patterns like OAuth flows and API keys. Browser agents live at the presentation layer, where the interface is whatever HTML the server happened to render and authentication is “I already logged in this morning.”

Neither replaces the other, but the marketing around MCP-based automation implies a universality that does not exist. When the Handrive thread talks about “AI automation,” it means automating API calls across SaaS products that expose programmable interfaces. When someone struggling with their expense report talks about AI automation, they mean “please fill out this damn form for me.” Those are two different desires wearing the same label.

The 41st tool you actually needed

What strikes me about the trajectory of MCP tool collections is how they keep growing horizontally, adding more integrations, more services, more API connectors, without ever crossing the boundary into the browser itself. You can get an MCP tool for Notion, for Linear, for Google Drive. But you cannot get one that reads the Notion page you are already looking at and pulls the specific table you highlighted, because MCP was not built for that interaction model.

A browser agent works with your existing tabs and your existing sessions. It does not need Notion’s API to read a Notion page, because the page is right there. It doesn’t need Google’s OAuth flow to draft a reply in Gmail, because you are already logged in.

The MCP ecosystem will keep growing, and for teams building serious data infrastructure it probably should. But for the rest of us just trying to get through a browser-shaped workday, 40 API integrations is a strange answer to a problem that starts and ends with the tab you already have open.