Standards

Three open standards let a website offer something useful to an AI agent. People mix them up constantly, mostly because two of them have MCP in the name. They solve different problems, and a site can adopt all three.

The short version. A web skill tells the agent how to use your site. WebMCP gives it functions on the page instead. Remote MCP lets it skip your site and talk to your backend. If you only do one, do the web skill: it is the cheapest and it works in the most places.

Side by side

Web skills

Works now

Write down how your site works.

What: A markdown file of plain-English steps, published at a well-known path on your domain.
Strength: Works with any agent in any browser today. The only thing you maintain is the text.
Catch: The agent still drives your UI, so it can be thrown by a redesign.
Cost: An afternoon

WebMCP

Chromium only

Hand the agent a function instead of a page.

What: Your page registers typed JavaScript functions that the browser passes to its agent.
Strength: The agent calls your code instead of reading your markup, so it cannot misread your interface.
Catch: Needs a browser that implements it, and the page has to be open.
Cost: A day, if you already have the functions

Remote MCP

Works now

Skip the page entirely.

What: A server that exposes tools over HTTP, which an agent connects to as a client.
Strength: Works without a browser at all. Best for reads, and for anything your API already does well.
Catch: It is a service you have to run, secure and version. It cannot see the page the user is on.
Cost: A week and ongoing

Which should you pick?

Start from what you already have, rather than from the technology.

If people get stuck in one of your flows, a cancellation or a claim or a form with a non-obvious order, write a web skill. You are writing down something you already know, and your support tickets are the evidence that it needs writing down.
If your app is a canvas, an editor, or a dashboard where the DOM is not really the model,WebMCP suits you better. The functions already exist. Clicking will never match calling them.
If you already have a decent API for order status or inventory or availability, aremote MCP server is mostly a wrapper over what you ship today, and it answers when nobody has your site open.
If none of that applies yet, go and fix your HTML. Real<button>elements, real links, labelled inputs, headings in order. All three standards work better on a page a screen reader can already handle, so that effort survives whichever one you pick.

Why bother at all

Agents will attempt your site whether or not you help them. What you control is whether they work from a screenshot and a guess, or from something you wrote.

The gap shows up when things go wrong. An agent that misreads a cancellation screen and cancels the wrong plan produces a support ticket with your name on it. Telling it which flows are safe to automate, and where it has to stop and ask, costs less than handling the aftermath.

There may be an upside as well, though it is harder to bank on. Agents that can use your site reliably will probably keep using it, and nobody yet knows what that traffic is worth. The protection against the downside is the part you can count on today.

This site does all three

We publish all three ourselves, at the locations any other site would use. It keeps us honest. If our own advice stops working, our own pages are the first thing to break.

/.well-known/agent-skills/index.jsonfour skills, including a ping you can use to check your own setup
/.well-known/mcp.jsonpoints at our MCP server
document.modelContext.registerToolruns on every page here, so a WebMCP browser gets typed tools for searching the directory