What Site Capabilities for Agents Means: How WebMCP Is Heading for a W3C Standard

At TPAC 2026 in Dublin last month, the W3C’s members reached what its president called “broad consensus” on something new: an Agentic Web Working Group.

In his October newsletter, published November 5, W3C President Dominique Hazaël-Massieux described the group’s draft charter as offering to bring the ideas incubated in WebMCP into a new “site capabilities for agents” deliverable, on the Recommendation track. That’s the W3C’s path to an official web standard.

If you’ve been following WebMCP, this is the moment it starts to grow up. If you haven’t, it’s the moment to start. Either way, there’s a new term you’ll be hearing a lot, and it’s worth knowing exactly what it does and doesn’t mean yet.

What W3C Agreed at TPAC 2026

TL;DR W3C members agreed that the web needs a working group for AI agents, and roughly what it should cover. A draft charter for that group would take WebMCP’s ideas onto the standards track under the name “site capabilities for agents”. The group isn’t chartered yet.

The groundwork was laid a week before TPAC. On October 21, the W3C Strategy Team published a discussion paper, W3C and the State of the Web in the AI Era, written by Philippe Le Hégaret, W3C’s VP of Technical Strategy. Its top recommendation was to charter an Agentic Web Working Group with an explicit scope for security and privacy, agent identity and delegation, and the relationship between WebMCP, HTML and ARIA.

TPAC (October 26 to 30) is where that recommendation met the membership. According to the newsletter, the outcome was:

• Broad consensus on the need for, and the scope of, an Agentic Web Working Group.
• Good progress on the draft charter, including the plan to turn WebMCP’s ideas into a “site capabilities for agents” Recommendation-track deliverable.
• Identity and delegation now written explicitly into the draft charter’s scope.
• Active work on the WebMCP specification itself, at the Web Machine Learning Community Group’s TPAC meeting.

Separately, on October 27, W3C picked a WebMCP polyfill as the second pilot project in its new Open Source Program. More on that below.

The draft charter at a glance

Source: DRAFT Agentic Web Working Group Charter

What “Site Capabilities for Agents” Actually Is

Strip away the standards language, and it’s a simple idea: a standard way for a website to tell an AI agent what it can do.

Today, an agent using your site has to work it out from the interface. It reads the page, finds the search box, guesses which button submits the form, and hopes nothing moves. That’s slow, it burns tokens, and it breaks every time you redesign. (We cover how agents get around today in Playwright MCP: How Agents Drive a Browser.)

WebMCP flips that around. Your page declares its capabilities as tools, such as search products, book a table or request a quote, each with a name, a description and a schema for its inputs. An agent in the browser asks the page what it offers, then calls those tools directly. For the full background, read our guide What Is WebMCP?

W3C’s own framing of the new group’s scope says it plainly. In a W3C talk on AI and web standards, Le Hégaret listed the group’s first job as “describing the site capabilities and relevant context for agents (WebMCP)”.

So “site capabilities for agents” isn’t a different technology from WebMCP. It’s the standards-track home for the same idea.

PRO TIP: Use both terms for now. “Site capabilities for agents” is the name in W3C’s newsletter, but the draft charter’s deliverables list and every spec, browser doc and GitHub issue still say WebMCP. Until a first Working Draft is published, you can’t be sure which name sticks.

From WebMCP to a W3C Standard: What Changes, What Stays

WebMCP today is a Draft Community Group Report from the W3C Web Machine Learning Community Group, edited by engineers from Microsoft and Google. That status matters. The spec itself says it isn’t a W3C Standard and isn’t on the Standards Track. Community Group work is incubation: anyone can contribute, but there are no patent commitments and no formal cross-browser review.

Moving into a Working Group changes that.

What’s likely to stay

The core model has been stable for most of 2026: a page registers tools, an agent discovers them, the agent calls them, and the user stays on the page, signed in, watching it happen. There are two ways to expose tools:

• Imperative: JavaScript calls registerTool() with a name, description, input schema and a function to run.
• Declarative: you add attributes like toolname and tooldescription to an existing HTML form, and the browser turns the form into a tool.

What’s likely to change

Plenty is still open. The API already moved once this year, from navigator.modelContext to document.modelContext. The declarative section of the spec is still marked as a TODO. And W3C’s own strategy paper lists the declarative-versus-imperative model, human handoff and tasks that span several pages as open gaps.

The path into a Working Group hasn’t been smooth either. Earlier this year, WebKit engineers objected to moving WebMCP into the existing Web Machine Learning Working Group. A dedicated Agentic Web group is partly the answer to the question of where this work should live.

The takeaway: build on the idea, not on the exact method names.

Agent Identity and Delegation: Why They Were Added

Exposing tools is only half the problem. The other half is trust.

When an agent calls your place order tool, two questions matter: who is this agent, and who is it acting for? Right now the web has no standard answer to either.

That’s why the draft charter now covers agent identity and delegation, alongside permissions, policies and transparency about what agents did. The W3C strategy paper sets out what that work should protect:

• Consent for consequential actions. A purchase or a booking needs more than a generic “Allow” dialog that people click through without reading.
• Visibility. The person should be able to see what the agent did on their behalf.
• Choice of agent. Sites and browsers shouldn’t lock people into one assistant.
• Delegated authority without shared passwords. Agents should be able to prove they’re allowed to act without holding the user’s credentials (heise has a good summary).

W3C’s Security Interest Group is also being asked for a WebMCP-specific threat analysis, including fake tools. As the paper notes, there’s no padlock for tools yet.

For site owners, this means the rules for which agents can do what on your site are coming. The sites that already separate safe actions from risky ones will find those rules easiest to adopt. If you sell online, the same trust questions sit behind agentic commerce.

The Accessibility Angle: WebMCP, HTML and ARIA

This is the part of the story most coverage will miss, and it matters a lot.

One of the new group’s jobs is to host the discussion on how WebMCP, HTML and ARIA relate to each other. That’s because agents already lean on the accessibility tree, the same structure screen readers use, to understand pages. (We explain how in The Best AI Agents.) It’s tempting for site owners to start writing for agents inside accessibility attributes.

W3C is pushing back on that. The strategy paper recommends guidance that:

• Instructions aimed at agents must not degrade the accessibility tree.
• ARIA must not become a channel for prompt injection. The ARIA Working Group is asked to draft guidance against agent-oriented misuse of ARIA, including prompts hidden in aria-label.
• When a person’s needs and an agent’s needs conflict, the person wins.

In practice, that leaves a clear division of labor. Accessible HTML and ARIA describe your interface for people, and agents benefit from that too. WebMCP describes your capabilities for agents, without touching what assistive technology reads.

PRO TIP: If you’ve added text to aria-label or hidden elements to steer AI agents, take it out. It makes your site worse for screen reader users today, and it’s exactly what W3C is drafting guidance against.

What Site Owners Should Do Now

You don’t need to wait for the standard. Almost everything that makes a site ready for WebMCP also makes it ready for whatever “site capabilities for agents” becomes. (For how this fits alongside SEO and GEO, see SEO vs GEO vs AEO vs Agent Readiness.)

1. List the three to ten things your site exists to do

Search, filter, add to cart, book, request a quote, check an order. These are your capabilities. Write a one-line description of each, as if explaining it to a new colleague.

2. Start with your forms

The declarative approach turns an existing form into a tool with a couple of attributes. A form with real labels, proper input types and clear error messages is already most of the way there. A form built from divs isn’t.

3. Mark what reads and what changes things

Tell agents which tools only look things up and which ones change something, like placing an order or deleting an account. Put a human confirmation step in front of anything consequential. That’s where the identity and consent work is heading anyway.

4. Keep agent instructions out of your accessibility layer

Accessible names should describe the interface for people. Tool descriptions are where agent-facing detail belongs. 

5. Experiment, behind feature detection

You can try WebMCP today through Chrome’s origin trial or the W3C-backed polyfill. Wrap it in feature detection so nothing breaks for visitors whose browsers don’t support it, and expect to update your code as the spec changes.

6. Test your site the way an agent sees it

Before and after you add any tools, check what an agent actually gets from your pages:

• Inspect your accessibility tree. Open your browser’s developer tools and look at the accessibility tree. Every button, link and form field should have a clear name and the right role. If it’s unclear to a screen reader, it’s unclear to an agent.
• Check your tools, if you’ve added any. Confirm each one shows up with a sensible name, a plain description and the inputs you expect, and that your site still works normally in browsers without WebMCP support.
• Run an automated accessibility scan. It catches the common problems that trip up people and agents alike, such as unlabeled buttons, missing form labels and div-built controls, so you know what to fix first.

Timeline: What to Watch Next

Three things to watch:

1. Advisory Committee review. W3C members vote on the charter. No date is set yet; W3C lists the end of the charter refinement phase as unknown.
2. The polyfill. The pilot’s first goals are an npm package and progress on two features, lifecycle events and declarative support. A maintained, W3C-backed polyfill makes it much safer to ship WebMCP before every browser supports it.
3. The first Working Draft. That’s when the name, the API and the scope become concrete. It’s also the moment the “site capabilities for agents” label either sticks or gets replaced.

WebMCP isn’t a finished standard, and it won’t be for a while. But it’s no longer just an experiment either. W3C has agreed it belongs on the standards track. Sites that expose their capabilities clearly, and keep their interfaces accessible, will be ready whatever the final version is called.

Site Capabilities for Agents FAQs