The Acquisition Blind Spot: Your Next User Might Not Be Human

A new user is knocking

Every interface we have ever shipped was built for a human. The desktop GUI is made for eyes and a mouse. The command line and the API are made for a developer who has read the docs. Even the SDK assumes a person on the other side, reasoning about names and arguments.

Now a new kind of user has arrived: the AI agent. It does not look at your screen, it will not read your documentation, and it never files a support ticket. But it acts on behalf of a real person — and when it finishes a task, it chooses which tool to use. Whoever paves the road for this new user picks up a new channel of distribution. This is the new SEO, the new App Store shelf. And most builders have not noticed it yet.

The doors have always been for people

Line the interfaces up by how close they sit to an agent, and a clear gradient appears.

GUI is the farthest. To use it, an agent has to see — screenshot the page, reason about pixels, guess where to click (this is "computer use"). It works, barely: slow, brittle, broken by the next redesign.

CLI is closer. It is text, which machines love. That is exactly why the command line has always been the substrate for scripting and automation — and why, today, it is quietly becoming a stepping stone for agents too. But the CLI was still designed for a human script author: the agent must parse --help, infer what each flag means, and judge on its own which operations are dangerous. It is a transitional form — friendlier than a GUI, but not the destination.

API / SDK is closer still. It is structured. But the documentation lives somewhere else, and authentication, rate limits, side effects, and business rules are all unwritten conventions that only a human developer is expected to already know.

Every one of these was built for people. The agent can make them work; it cannot make them easy.

MCP: the first door built for the agent

MCP — the Model Context Protocol — is the first interface designed for this new user. It is not just another shell wrapped around your CLI. It is a standard that lets your software describe itself: here are the tools I offer, here is each parameter's type and meaning, here is when to use them. The agent does not read a manual and does not guess — your server hands it the contract directly.

Sitting on top of your existing API or CLI, MCP gives an agent a fast, reliable, and — if you implement it carefully — safe way to use what you have built. Safe, because you decide which capabilities to expose and where the boundaries are, instead of turning a loose agent onto your whole interface. (Careful matters: an over-permissioned tool or an unguarded input is its own risk.)

Two roads to your app

There are two ways an agent can reach a web app, and the difference between them is the whole point.

Browser-use lets the agent operate your interface like a human — it looks, it reasons, it clicks. It is universal, and it is improving fast. It is also slow, fragile, interrupted by any layout change, prone to misclicks, and exposed to prompt injection from the page itself.

MCP lets the agent call your capability directly — fast, precise, and on your terms.

One is the agent fumbling at a door built for someone else. The other is you handing it the key. Browser-use is the universal fallback; MCP is the front door you open on purpose.

The blue ocean is right now

Here is the part most builders will regret missing. We recently measured every live product in our gallery — 2,614 AI-built web apps — for a declared machine interface. About a third already ship an llms.txt, so agents can read them. Only 1.4% expose a callable MCP endpoint, so agents can act on them.

Readable gets you found. Callable gets you used. The gap between those two numbers is open water. Adding an MCP endpoint today is what adding a sitemap was in 2005 — a small move, made early, that compounds as the channel grows.

It is a one-line kind of job

The best part: if you already have the function, exposing it is almost trivial. Here is the whole shape of it —

```ts import { createMcpHandler } from "mcp-handler"; import { z } from "zod";

const handler = createMcpHandler((server) => { server.registerTool( "search_products", { description: "Search live products similar to an idea.", inputSchema: { query: z.string(), limit: z.number().optional() }, }, async ({ query, limit }) => { const results = await yourExistingSearch(query, limit ?? 8); return { content: [{ type: "text", text: JSON.stringify(results) }] }; }, ); });

export { handler as GET, handler as POST }; ```

That is it. You are wrapping a function you already wrote. We stood up our own MCP server — the one that lets any coding agent search 2,600+ live products — in about an hour. The description and the typed schema are the work: they are what turn a private function into something an agent can discover and call correctly.

Not just the web

None of this stops at web apps. A mobile app's features are almost always backed by a server too — so the same move applies: expose that backend's capabilities over MCP, and your app is reachable by agents whether or not anyone opens it on a phone. In the AI era, shipping only a human-facing screen is shipping half a product. The other half is the door you open for the user who is not human.