WebMCP turns websites into AI tools - what to do now

WebMCP landed in Chrome with not much fanfare and one big claim: any website can now hand AI agents a clean set of tools to call, instead of making them squint at the page like a tourist reading a foreign menu. Google ships it as a Chrome 149 origin trial. The official Chrome docs call it “a proposed web standard” that helps you “build and expose structured tools for AI agents” and “annotates HTML form elements so that agents know exactly how to interact with page features.” Tallyfy runs it on tallyfy.com today.

Here’s the part worth sitting with for a second. Exposing a tool is the part that just got easy.

The hard half is everything that happens after the agent calls more than one of them. Does step two wait for step one to finish? Who signs off before money moves? What happens when the agent calls a tool, the result comes back wrong, and there’s no defined next move? WebMCP answers none of that, and it was never meant to. It gives an agent a cleaner door to knock on. It does not tell the agent which rooms to visit, in what order, or who’s allowed to let it into the room with the safe.

That distinction, between a tool an agent can call and a process it has to follow, sits at the center of how AI and work actually fit together, and WebMCP just made it impossible to ignore.

What WebMCP actually does

Strip away the protocol talk and WebMCP is simple. A website registers named tools, like “search templates” or “book a demo,” and an AI agent running in the browser can call those tools directly. No screen-scraping. No guessing which button does what. The site author declares the tool, its inputs, and what it returns, and the agent basically calls it like a function.

That’s a real shift from how agents work today. Most browser agents read the rendered page and try to act on pixels, which is slow, clunky, and breaks every time you ship a redesign. WebMCP replaces that guesswork with a contract. One developer on the Hacker News thread announcing it put the intent plainly: WebMCP is “designed for website owners to open direct access to agents by embedding MCP tools onto their own websites.”

That said, worth clearing up one common confusion. WebMCP is not an anti-scraping shield. The same thread is blunt that adversarial data extraction from competitors’ sites is “not solvable with WebMCP.” It’s an opt-in surface you build for agents you want to serve, not a wall against the ones you don’t.

There are two ways to declare those tools. You can register them in JavaScript, the way the snippet below does, or you can annotate existing HTML form elements so an agent reads them as structured actions instead of a wall of unlabeled inputs. Either path lands in the same place: the agent stops reverse-engineering your interface and starts calling declared functions with known inputs and known outputs. For a search box or a booking form, that’s a real upgrade over pixel-watching. The browser becomes a place where an agent can act on purpose rather than poke around and hope.

Here’s the actual call Tallyfy registers on tallyfy.com, trimmed down:

// Live on tallyfy.com behind the Chrome 149 origin trial.
document.modelContext.registerTool({
  name: 'search_templates',
  description: 'Search Tallyfy public workflow templates by keyword.',
  inputSchema: {
    type: 'object',
    properties: { query: { type: 'string' } },
    required: ['query'],
  },
  annotations: { readOnlyHint: true },
  execute: async ({ query }) => {
    // find matching templates, return a short text list
    return matches.map((t) => `- ${t.title}: ${t.url}`).join('\n');
  },
});

The API is document.modelContext.registerTool, and execute hands back a string the agent can read. If you’ve seen navigator.modelContext or window.webmcp in an older blog post, skip it. Those names are out of date. Feature-detect document.modelContext and register your tools when it’s there.

One tool call is the easy part

So an agent can call your search tool. Great. Now ask it to do something a person actually wants done, and watch where it gets stuck.

Take a customer who wants an agent to “set up a new vendor.” That’s not one tool call. It’s collect the vendor’s details, check them against a do-not-pay list, route the file to finance for approval, create the record only after sign-off, then notify the requester. Five tools, in a fixed order, with a human gate in the middle and a state that has to survive if the laptop closes at step three. WebMCP can expose all five tools beautifully. It has nothing to say about the order, the gate, or the surviving.

This is the gap that keeps tripping up the “just connect an agent to it” projects. The tool surface gets cleaner and everyone assumes the job got easier. The job didn’t change. Coordinating several tools across people, with a record of who did what and a way to recover when something fails, is the same work it always was. WebMCP made the first inch easier and left the mile alone.

Watch an agent try to run that vendor setup with no process underneath and the failures are boringly predictable. It calls the approval tool before it’s collected the details, because nothing told it the order. Then it retries a step it already finished, because it lost track of where it was. It sails right past the human gate, because a gate that lives in a prompt instead of in the process is a suggestion, not a stop sign.

And if the tab closes halfway through, it has no idea whether it was at step two or step four. None of these are intelligence failures. They’re coordination failures, and a sharper model doesn’t fix a single one of them.

Your agent still needs a process to follow

The tooling that lets an agent act is arriving fast. The structure that tells it what to do still has to be built by someone, and that someone is you.

That structure is a workflow: a defined sequence of steps, each with an owner, an input, and a rule for what comes next. Point an agent at one step of a process and it inherits the order, the approval gates, and the audit trail for free. Skip the process and the agent has to improvise the coordination itself, which is exactly the part it’s worst at. We’ve written before about why an AI agent needs a workflow engine underneath it, and why it’s safer to bind agents to a defined workflow than to let them roam. WebMCP doesn’t change that conclusion. It sharpens it, because a cleaner tool surface makes it even more tempting to skip the process and just let the agent wing it.

Picture a support site with three clean WebMCP tools: look up an order, start a return, issue store credit. An agent calls all three flawlessly. Then a customer asks for credit on an order that’s well outside the return window. The tools all still work perfectly. Not one of them knows the policy, knows this case needs a manager, or records why the credit got granted. The process knows that, or it’s supposed to.

Drop those same three tools inside a defined return workflow and the policy check becomes a step, the manager sign-off becomes a gate, and the reason becomes a line in the audit trail. Identical tools, a completely different level of trust. The tools were never the missing piece.

It helps to keep two surfaces straight, because people blur them constantly. WebMCP tools live in the browser and run when a person is on your page with an AI agent open. That’s one surface. A Model Context Protocol server is a different one: an authenticated endpoint that connected AI clients call directly, with no browser involved. Tallyfy runs both.

The in-browser WebMCP surface is four read-only tools. The authenticated server exposes 100+ tools to clients that log in. Same company, two doors, two very different jobs. Confusing them is how teams end up building the wrong thing.

What this means if you run operations

You don’t need to write a line of WebMCP code to care about this. Within a year, the procurement portal, the ticketing tool, and the onboarding app your team uses will all be agent-targets, whether their vendors planned for it or not. So the question on your desk isn’t “should we adopt WebMCP.” It’s “when an agent reaches one of our tools, is there a defined process behind it, or just a button it can press?”

In conversations with operations teams, one worry keeps surfacing: that AI will act faster than anyone can check it. A cleaner tool surface makes that worry sharper, not softer. An agent that can call your “issue refund” tool in one shot is genuinely useful and genuinely dangerous, depending entirely on whether that call runs inside a process with a sign-off step or fires straight into your billing system.

So which is it for your refund tool right now?

For most teams, honestly, it’s a button. The refund logic exists, the approval lives in someone’s habit of “checking with finance first,” and nothing enforces the order. That worked fine when a human was the one clicking, because the human carried the process in their head. Hand the same button to an agent and the unwritten process evaporates, because the agent never learned it. This is why the move toward AI mediated by an MCP server matters more than the tool surface itself: the agent should reach your work through a layer that already knows the rules, not through a raw key to every function you’ve ever shipped.

Here’s the reframe that actually helps. Stop thinking about exposing tools and start thinking about exposing processes. A tool is “issue a refund.” A process is “read the request, check the policy, route anything over a threshold to a human, then issue the refund and log it.”

The second one is safe to hand an agent. The first one is a fast way to lose money. A live status view and an approval gate aren’t nice-to-haves bolted on after the agent works. They’re the thing that makes letting the agent act defensible in the first place.

Where to put your attention first

Resist the urge to expose everything to agents this quarter. Turns out the teams that win here aren’t the ones with the most WebMCP tools. They’re the ones whose underlying processes were already defined, so adding an agent is a small, safe step instead of a leap.

Start with the unglamorous part. Pick the two or three processes where an agent would genuinely save time, like vendor intake, ticket triage, or first-draft document review. Map each one as a real sequence of steps with owners and a rule for what’s irreversible. Mark the steps that need a human to sign off. Only then decide which tools to expose, and to which surface, the in-browser WebMCP layer or an authenticated MCP server.

There’s a sequencing question hiding in that last sentence, and it’s worth answering on purpose. The in-browser surface fits when a human is on your page and wants their AI assistant to act on it, like a customer searching your templates or booking a call. The authenticated server fits when a connected AI client reaches your data with no browser in the picture, like an agent pulling a status update into a chat thread. Plenty of teams will want both before long. But neither one decides the order your tools run in or who approves what, which is the whole reason the process has to come first.

Will WebMCP matter? Yes, more every month, as agents become a normal way people reach your software. But it’s plumbing for the simple part of the problem. The harder part, the coordination, the state, the proof of who did what, is workflow infrastructure, and that’s the part worth building first. Get the process right and WebMCP is a quick win on top of it. Skip the process and a clean tool surface just lets your agent fail faster.