AINEWS
Google and Microsoft are drafting a way for websites to declare structured tools to AI agents, in a W3C Community Group, not yet a finished standard.
A waiter does not read the menu as a picture and guess. They hand you a list of what the kitchen actually does. The proposed web standard WebMCP wants to give AI agents the same courtesy: instead of an agent scrolling through dozens of <div> elements, picking one it hopes is the date picker, and clicking the green button on faith, the page would declare, in machine-readable form, the tools it actually exposes.
The author's explainer describes it as developed jointly by Google's Chrome and Microsoft's Edge teams inside the W3C Web Machine Learning Community Group, which is the venue for proposals that have not yet entered the W3C standards track. Chrome is already running the proposal behind a trial flag, per the same explainer. That status is the part the headline cannot carry on its own: this is two browser vendors' draft, in a community group, with no commitment to standardization.
The mechanism is the story. Today, when an agent wants to book a table, check out, or look up a tracking number, it has to look at the rendered page and reverse-engineer which element does what. A WebMCP-style page would register a small set of tools — book_table, check_availability, cancel_reservation — with structured inputs and outputs that an agent can call directly. Google's Chrome documentation, quoted in the source, frames the goal plainly: sites can "build and expose structured tools for AI agents" so that agents "know exactly how to interact" with them. The page stops being a picture an agent has to read and becomes a published API surface an agent can call.
That move from implicit to declared opens a consent fork every publisher will have to walk through. A site that registers book_table is choosing to be agent-callable. A site that registers nothing is choosing the status quo, and agents fall back to scraping. A site that registers tools it does not actually want exposed has, in effect, signed a contract on behalf of its users. None of that is settled by the draft. The Community Group document is a tool kit, not a policy. How sites express opt-in, how they revoke it, what audit trail an agent leaves behind, and who is on the hook when a declared tool is wrong are all questions the proposal does not answer.
There is a quieter upside hiding in the Hacker News discussion of the post. If a page can describe its booking flow as a structured API, the same description is also accessible to screen readers, voice assistants, and other assistive technology that today has to scrape the page alongside the agent. Readers using a screen reader do not have to wait for the same site to be retrofitted for accessibility. The AI framing buys an accessibility dividend by accident, and the W3C venue is the right place to make that explicit, if the draft gets that far.
The honest read is shorter than the hype. WebMCP is a single Community Group draft, explained in a single developer blog post, and corroborated only by community discussion. Two vendors are involved, and the standards track has no obligation to pick it up. Chrome can change course. Edge can change course. Sites that do not want to be agent-callable can simply do nothing, and agents that prefer scraping can keep scraping. The proposal is worth tracking because the mechanic is the right one (the page as a declared surface, not a screen) and because the consent questions it raises are the next round of web standards work, whether or not this particular draft becomes the answer.