If you’ve read about our Semantic Agent and how it works, you know that it comes with a set of predefined skills and the ability to learn new ones. And that’s a powerful set of capabilities that out of the box make it a radical improvement – at least a 32X improvement – in the price-performance for browser agents.
So an agent-maker could simply replace their agent with our Semantic Agent and get all those benefits.
But there’s an alternative that any agent-maker could consider, and that’s to make their own agent better. The advantage of this route is that it’s more flexible and future proof.
Introducing WebMCP
WebMCP is a proposed new standard put forward quite recently by Google and Microsoft. It proposes how websites can expose their capabilities to autonomous agents. Developers do so by explicitly defining “tools” in their code, tools that are intended explicitly for AI agents to use. (It’s part of a larger contract-driven development trend in AI coding.)
Architecturally speaking, WebMCP does this via two primary interfaces:
- Declarative API. This allows developers to annotate native HTML forms with attributes like toolname and tooldescription, explicitly telling agents how to interact with them.
- Imperative API. This allows developers to author custom JavaScript to expose complex, multi-step workflows to agents.
For WebMCP to become the universal standard, however, millions of developers need to manually annotate existing forms (for the Declarative API) and write custom JavaScript for complex UI patterns (for the Imperative API).
That’s a lot of work. And here we have a classic chicken-and-egg problem. Without a critical mass of WebMCP-enabled websites, AI providers won’t fully optimize for it. Yet if AI providers don’t commit deeply, developers will lack the incentive to do all the manual work on their end.
To break this gridlock, we need a way to implement these agentic contracts automatically.
An auto-population approach
It turns out, we think we can do the WebMCP work required for developers, and do it at runtime as the agents hit the developer’s site, without the developer needing to lift a finger.
We call our approach Semantic Auto-Population, and it executes as an overlay in the browser.
Imagine an agent visiting a website. During page load, the browser queries our backend cache. If the page contains standard accessible components (like properly structured WAI-ARIA comboboxes or data grids) or workflows that have been successfully cached already as learned skills, the browser automatically injects the corresponding Declarative and Imperative WebMCP tools directly into the web page’s DOM.
This instantly enables highly reliable, WebMCP-compliant capabilities across a massive swath of the internet. It transforms legacy, human-centric interfaces into structured, agent-ready APIs in real-time, all without requiring heavy validation logic to run on the client’s machine.
But it doesn’t fix the problem at the source. It turns out we have an idea for that, too.
Making the source agent-ready
As an accessible development company, we’ve been leading our industry for years in building tools that can automatically assess a site’s defects with respect to how well elements and especially interactable elements are described. So we’ve already built a tool – we call it an Agentifier – that scores a website automatically for “agent readiness,” and it generates a detailed report of all the semantic problems for a website that would prevent semantic auto-population. This information is deliverable to developers in the usual ways, as a report with fix instructions.
But that’s just the usual way. We can also deliver this exact same capability as an MCP server or plugin for AI coding assistants. That means developers can instruct their AI coding agents to read the feedback from Evinced and autonomously remediate the issues we report. In the process, the coding agent can take live instruction from Evinced on how to generate and apply the necessary WebMCP HTML annotations and JavaScript snippets directly to the local codebase.
Suddenly, we have a way to fix the codebase itself, in a way that prepares every site for the agentic future. And still with minimal hassle for developers.
The 100X opportunity
So our hypothetical agent-maker now has two ways to get a 32X price-performance advantage vs. peers, and neither require much work from developers. So far so good.
But there’s actually even more opportunity, and this one has to do with accessibility.
When we built our Agentifier tool and did our research, we noticed something hidden inside the average 32X price-performance improvement that we reported above. For sites inside that average with high semantic structure, the average PPI was well over 32X. Even more importantly, we discovered that by diagnosing a site with the Agentifier and fixing just a few key semantic issues—like properly defining a role or state—the performance gains skyrocket. In these cases, the price-performance improvement exceeded 100X.
In effect, if website owners could also fix even some of the accessibility of their websites using existing Evinced tools, the performance advantage for our hypothetical agent-maker could be enormous. But why would website owners do the work? It’s another chicken-and-egg problem.
We can think of two ways through. Either will work by itself or they can be used in combination.
First, the work to improve the accessibility of websites is now at a state where it can also be run inside agentic coding workflows. Indeed, our MCP Tools product is set up for exactly this. So instead of a developer having to manually create WebMCP tools, they can use our MCP Tools to both automatically fix their accessibility issues and the needed WebMCP tools will be created automatically.
Second, if our agent-maker has enough influence with website owners, or simply if website owners see the agentic bandwagon coming, they could choose to act sooner. Websites that act sooner will be privileged in some way, as agent-makers will want to steer traffic toward experiences that they know will be better for end users. If you ask an agent to book you a trip to Paris, that agent may well have a choice about which website to use for that request. A website that has already been vetted to have high accessibility (and compatibility with WebMCP) would naturally get that business.
The future is machine-readable
So agent-makers have a clear and reliable path to outperformance now, and a reasonable path toward even higher outperformance in the future.
The future of the web isn’t just about what humans can see; it’s about what machines can understand. We think our Semantic Agent and the tools and strategies we’ve laid out here will get agent-makers there faster. And the win-win here is that these improvements will simultaneously make the web better for humans, too.