A page declares what it can do; an app asks who is asking

Sources cited in this piece · WebMCP, Draft Community Group Report, 16 October 2026, published by the W3C Web Machine Learning Community Group; editors Brandon Walderman (Microsoft), Khushal Sagar (Google), Dominic Farolino (Google) — primary source, quoted verbatim · the refusal list and its reasons: 10月14日 豆包手机助手《屏幕自动化操作声明协议》(SAEP) 拒绝操作清单, reported by 中国经济网 and 中国妇女网 on 15 October 2026, with analysis quoted from 《中国新闻周刊》 — secondary Chinese-language reporting, quoted verbatim and labeled as such · the 28 October W3C breakout session "Integrating WebMCP into WebExtensions" is noted from the W3C calendar.

In a single week, two fronts of the same war opened — and they are arguing about the same missing layer. On the web side, a W3C community group published a specification that lets a page declare, in JavaScript, what an agent may do with it. On the phone side, an agent assistant published a list of more than 150 applications that refuse to let an agent operate them at all. One front asks what can this page do for an agent; the other asks who is actually pressing the buttons. Both questions are live, and neither has a standard answer yet.

1. What WebMCP is, in the draft's own words

The document is dated 16 October 2026 and it is a Draft Community Group Report, published by the W3C Web Machine Learning Community Group, edited by Brandon Walderman (Microsoft), Khushal Sagar (Google) and Dominic Farolino (Google). Its abstract is one sentence: “The WebMCP API enables web applications to provide JavaScript-based tools to AI agents.” Its status section is equally terse, and worth quoting because it is so often elided: “It is not a W3C Standard nor is it on the W3C Standards Track.”

The introduction explains the mechanism in the sentence that will be quoted for years: “Web pages that use WebMCP can be thought of as Model Context Protocol [MCP] servers that implement tools in client-side script instead of on the backend.” Concretely, a page calls document.modelContext.registerTool() with a name, a natural-language description, a JSON schema for input, and an execute callback; the browser agent obtains a view of those tools by taking an observation; and the draft is candid that the wire format is not its business — “Despite the name of this API (i.e., WebMCP), this specification does not prescribe the format in which tools are exposed to the browser agent.” The draft also carries three optional annotations a tool author can attach: readOnlyHint, untrustedContentHint, and consequentialHint — the last of which the spec describes as a signal “that the tool performs a consequential action, such as booking a flight or transferring money.” A W3C breakout session scheduled for 28 October 2026 is listed on the W3C calendar under the title “Integrating WebMCP into WebExtensions.”

2. The concession inside the specification

Here is why this draft matters to us more than any press release could. In section 6.3.2, “Misrepresentation of Intent,” the editors state the problem without softening it: “There is no guarantee that a WebMCP tool's declared intent matches its actual behavior.” And then, one line later, the sentence that should be printed on the wall of every agent team: “This creates a fundamental trust gap: agents rely on natural language descriptions to decide whether to invoke a tool and whether to prompt the user for permission, but cannot verify the tool's actual effects before execution.”

The draft then lists what it calls the current gaps, and the four bullets read like a specification for the second pillar: “No verification mechanism: Agent implementers cannot verify that tool implementations match their descriptions”; “Semantic ambiguity: Natural language descriptions are subjective and open to interpretation”; “No behavioral contracts: Unlike typed APIs, tool behaviors cannot be statically analyzed or verified”; and the one that names the actual posture of the industry — “Agent trust assumptions: Agents must assume good faith from site developers.” The baseline the draft assumes makes the stakes concrete: “Identity inheritance: Agents are able to inherit user identity and authentication context from the browser. When an agent visits a website, it carries the user's logged-in credentials and session state.” So the tool that gets called is called as you.

3. The other front: 151 apps that said no

Two days before the draft, on 14 October 2026, a phone agent assistant in China published the latest version of its refusal list. The reporting is consistent across outlets: the assistant's Screen Automation Execution Protocol (SAEP) had completed a 30-day public comment window, and a list of applications that declare refusal was published alongside it. 中国经济网 puts the number at 151 applications; other outlets describe it as “more than 150.” The breakdown reported is 65 from the Tencent ecosystem, 23 from Alibaba's, 14 from Kuaishou's, 11 from Meituan's, and 34 independent applications; named among them are WeChat, QQ, Taobao, Alipay, Meituan, Kuaishou, Pinduoduo, Xiaohongshu, WPS, DeepSeek, Kimi, and applications from several banks and carriers.

Two things about this list are worth separating from the noise. First, what was refused is narrow: the refusal is about a GUI agent reading the screen and simulating taps and swipes on the app's behalf — the applications still install, open, and work when a human uses them. Second, and this is the part that belongs in this essay, the stated reason is not protectionism as such. A report in 《中国新闻周刊》 quotes an engineer's account of the reasoning: the assistant operates applications through screen automation without clear authorization from the application side, and “App无法确认操作者究竟是手机持有者本人还是豆包智能体,抑或是被木马、黑客控制的智能体。一旦出现风险,责任很难界定” — the application cannot confirm whether the operator is the phone's owner, the assistant's agent, or an agent controlled by a trojan or an attacker; and once something goes wrong, liability is hard to allocate. Another analysis quoted in the same coverage puts it more bluntly: what the platforms refuse is not the technology, it is being bypassed.

4. Where the two schemes sit in this

Put the two fronts together and the shape of the gap stops being abstract. On the browser side the page has been given a vocabulary to declare capability and has used it well; what it has not been given is a way to establish which agent is calling, or to re-check the declaration at the moment of execution. On the phone side the application is being asked to accept an unattributable touch and has answered the only way it can, which is no. Both are waiting on the same two rows.

RTTP (rttp://) answers where and when — the first row. Under our scheme the caller's name is not asserted in a description field; it is computed: SHA-256(canonical_authority)[:16], a function of the authority the agent acts for. A declaration in natural language can be edited, and a name in a registry can be claimed by whoever got there first; a derived name cannot be made to point at an authority it was not computed from. That is the property the browser front is missing when it asks “which agent called,” and it is arithmetic rather than policy.

IQA (iqa://) answers whether — the second row, and the exact row the WebMCP draft lists as “No verification mechanism.” An attestation envelope carries the statement with an Ed25519 signature; standing is a 120-second lease with four states (ghost, probation, radiant, genesis), so a fact has an expiry and gets re-checked rather than being trusted indefinitely; malformed input fails closed; and verification is local arithmetic, which is what makes the three offline tests — disconnection, survival, explanation — meaningful. On the phone front, this is the difference between an application receiving a touch and an application receiving a signed statement of who is acting, on whose authority, that it can check without asking anyone.

Credit where it is due: consequentialHint is the right instinct. A signal that an action is consequential is the beginning of the conversation this industry needs to have. But a hint is a statement by the same party whose behaviour is in question; it is not a proof, and the draft's own gap list says so. The honest summary of the week is that the side declaring capability and the side refusing to be operated are both, correctly, pointing at the same absence.

The web is learning to declare what it can do. The phone is learning to demand proof of who is asking. Two fronts, one week, one missing layer — and this week both sides said the missing piece out loud, in their own vocabularies, four days apart. That is not a coincidence. It is the same row asking to be filled.