Make the web adaptable to the person using it.

Why WebMCP, not browser automation?

Browser automation forces agents to infer UI semantics from DOM and pixels, then perform fragile sequences of clicks and typing. WebMCP lets the website explicitly declare structured capabilities and schemas, so an agent can invoke typed, validated operations instead of guessing how the interface works.

1. Human need is expressed.
2. Agent discovers site capabilities via WebMCP.
3. Agent negotiates an accessibility profile.
4. User approves reversible remediation.
5. Site adapts live; agent verifies.
6. Human task completes.

What was previously difficult

Before WebMCP, an agent saw DOM plus pixels and had to infer what each control does, which adaptations are possible, how to modify them, and whether the change worked. With WebMCP, the agent sees structured capabilities, schemas, and current state — and can discover, select, invoke, and verify.

Any site can opt in

The Partner site demo is a plain static HTML page this app does not render. It became agent-adaptable by adding one <link rel="a11ymcp-manifest"> and one <script src="/a11ymcp-adapter.js">. The adapter reads the site-declared manifest and registers the same discover → negotiate → approve → adapt → verify tool flow on document.modelContext.

Try it on any page

Make a new bookmark with this as its URL, then run it on any website:

javascript:(function(){var s=document.createElement('script');s.src='https://a11ymcp.vercel.app/a11ymcp-probe.js?'+Date.now();document.body.appendChild(s);})();

It reports what the page looks like to an agent: whether WebMCP is available, how many tools the page registers, and whether it declares an accessibility capability contract. On almost every site today the answer is none — which is the point.

The probe deliberately does not adapt the page it runs on. Changing someone else’s site uninvited is exactly the overlay behaviour A11yMCP exists to replace, so the probe reads and reports, and adds nothing but its own dismissible panel.