The Agent Breakpoint

Before I sign up for a tool now, I check one thing: can my agent use it?

Most of my work runs through Claude Code. My setup talks to Supabase, PlanetScale, Cloudflare, Slack, Jira and Mobbin. When two services do the same job, I pick the one my agent can reach. Not on principle. The other one just leaves more of the work to me.

Last month I asked Claude to update the projects on my LinkedIn profile. LinkedIn gives agents no way in, so it drove Chrome like a person would: find the field, click, type, save. Characters went missing as it typed, so it switched to setting the values with JavaScript. It got there. It was also the web on a 2008 phone, pinch and zoom, done by a machine.

We’ve been here before.

#The phone did this to us first

The iPhone shipped in 2007 with a real browser, and it rendered desktop sites. You pinched, zoomed and scrolled sideways. It worked, which is why nobody rushed.

Then came m.example.com: a second, smaller site, built next to the real one. It usually did less. “The mobile site can’t do that, switch to desktop.”

In May 2010 Ethan Marcotte wrote “Responsive Web Design” in A List Apart. One site, fluid grids, flexible images, media queries. Same product, laid out for whatever screen showed up.

Nobody had to adopt it. People just drifted toward the sites that worked on their phone. In April 2015 Google made it official with its mobile-friendly ranking update, and in October 2016 mobile and tablet passed desktop in worldwide browsing.

Agents are on the same path, a few years in:

Here’s the idea in one widget. Keep making the window narrower and, past the last phone, the screen disappears and only the actions are left.

#Responsive, for something with no screen

Responsive design never changed what a product did. It changed how the product was presented. Same here. An agent doesn’t want a different product, it wants the same actions as names with typed inputs instead of a layout.

The useful part of responsive design carries over as it is: one product, many presentations, and the rules in one place. The CLI, the MCP server and the web page shouldn’t each reinvent permissions. They’re views.

Each of those views serves a different place an agent lives. You probably don’t need all of them.

#Start with what you already have

Semantic HTML. Browser agents read the accessibility tree, the same structure screen readers use. Real buttons, labelled inputs and headings in order help an agent for free. Accessibility was the first time we built for something other than eyes.

Docs an agent can read. Markdown versions of your docs pages, and an llms.txt at the root that points to them. This site has one and an OpenAPI file for exactly this reason.

An API with scoped tokens. Everything below is built on it. A token that can be read-only, or limited to one project, is what lets someone hand it to an agent without worrying.

#A CLI, for agents in a terminal

Coding agents like Claude Code and Codex live in a shell, and they’re already good at gh, wrangler and stripe. A CLI is the cheapest interface you can give them. Nothing is loaded into the model’s context until it’s used, --help is the documentation, and output pipes into the next command.

What makes a CLI good for agents is mostly what makes it good in CI:

• Non-interactive by default. A prompt waiting on a TTY hangs the agent.
• --json on every command that prints data.
• Exit codes that mean something.
• Errors that say what to do next, not just what went wrong.
• Auth from an environment variable.

There’s a running argument about whether CLIs beat MCP. Anthropic’s own code execution with MCP post showed one workflow going from 150,000 tokens to 2,000 when the agent wrote code against tools instead of loading every definition up front. My read is simpler: a CLI serves agents that have a shell, and most agents don’t have one.

#An MCP server, for agents in chat apps

Most people will never run your CLI. They use Claude or ChatGPT in a browser or on their phone, with no terminal. A remote MCP server with OAuth means someone adds your product as a connector, signs in, and it works there.

When I built Flaremender I gave it one, so Claude, Cursor or Claude Code can ask for tests, runs and repairs without opening the dashboard.

The common mistake is the m.example.com version: one tool per REST endpoint, ninety tools, each with a full schema the model has to read before it does anything. Fewer tools, built around the tasks people actually do, work better:

• Name tools after tasks, and write descriptions for a reader who has never seen your product.
• Return what the next step needs, not the whole database row.
• Mark what’s read-only and what’s destructive. MCP has annotations for both, and clients use them to decide when to ask the user first.

#WebMCP, for agents in the browser

This is the newest of the three and the least settled. A page registers its own actions as tools, and a browser agent calls them inside the session the user is already signed into.

There are two ways to do it. The imperative one is JavaScript:

document.modelContext.registerTool({
  name: "list_invoices",
  description: "List invoices, optionally by status.",
  inputSchema: {
    type: "object",
    properties: {
      status: { enum: ["draft", "sent", "overdue", "paid"] },
    },
  },
  annotations: { readOnlyHint: true },
  execute: ({ status }) => invoices.list({ status }),
});

The declarative one is a few attributes on a form you already have:

<form
  toolname="create_invoice"
  tooldescription="Create a draft invoice for a customer."
  action="/invoices"
>
  <input
    name="customer"
    required
    toolparamdescription="Customer name, as it appears in the customer list."
  />
  <input name="amount" type="number" required />
  <button>Create draft</button>
</form>

Without toolautosubmit, the agent fills the form in and the user presses the button. That’s a good default: the agent does the typing, the person still makes the decision.

This is the one that feels like responsive design. Same page, same code, same session, no second server and no second sign-in. The page just describes itself.

It’s also early. The spec is a draft from a W3C community group, with editors from Google and Microsoft, and it isn’t on the standards track. Chrome opened an origin trial in version 149, and no browser turns it on by default. The entry point moved from navigator.modelContext to document.modelContext this year. Build against it for one flow, not for your whole app.

#Where the analogy breaks

Responsive design reflowed the same interface. Agents need a different one. That makes this less like 2010 and more like the open-API years of the 2000s, and we know how part of that went. Twitter ended free API access in 2023, and Reddit’s new API pricing shut down Apollo the same year. APIs got closed when they stopped helping the business.

The incentives are different. A phone user still saw your ads and your upgrade banner. An agent skips both. For products that earn from attention, being easy for agents to use is a real cost, and some will choose not to. For products that earn from usage, which is most SaaS, an agent is a customer that never gets tired of your workflow.

An agent in your session can do what you can. The WebMCP spec says plainly that defending against manipulation is mostly the agent’s job, not the page’s. Tool output is input to the model, and input can carry instructions. So on your side: scope tokens, mark the consequential actions, default to read-only, and keep an audit log of what agents did.

#What I’d build first

• A developer tool: a CLI with --json, then an MCP server.
• A SaaS app people sign in to: a remote MCP server with OAuth, built around five or six real tasks.
• A consumer site: semantic HTML and good labels now. Try WebMCP in the origin trial on the one flow people repeat most.
• Everyone: Markdown docs, llms.txt, and tokens that can be scoped down.

Nobody wrote angry letters to sites that didn’t work on their phone. They used them less, then stopped. I think agents go the same way. I’m not going to drop a service because my agent can’t use it. But when there are two, I already know which one I’ll pick.