WebMCP spec changes and what to update in your code

Where the spec stands

WebMCP is a Draft Community Group Report of the W3C Web Machine Learning Community Group, first published on 13 August 2025 and edited by engineers from Microsoft and Google. It is not a standard yet and it changes month to month. This page tracks the API-visible changes in the spec's own history (the index.bs commit log) as of 4 September 2026, with the code change each implies. The declarative (HTML form) API is still marked as to-be-specified and follows the separate explainer.

September 2026

• 3 Sep — consequentialHint added to ToolAnnotations. A third boolean beside readOnlyHint and untrustedContentHint, for tools whose effects warrant user confirmation (purchases, deletions). *Do:* set it on every mutating tool; the inspector's annotations check expects it where the name or description implies consequence.

August 2026

• 19 Aug — AbortSignal integration with tool execution; in-flight executions survive unregistration. execute() receives { signal }; a tool unregistered mid-call finishes its current call. *Do:* honor the signal in long-running executes.
• 17 Aug — executeTool() takes an object, not a JSON string. *Do:* if you built a test harness that stringified arguments, pass the object.
• 14 Aug — executeTool() specified; RegisteredTool.inputSchema becomes an object (was DOMString); exposedTo validated before the abort algorithm registers. *Do:* read inputSchema as an object from getTools(); expect registration to reject an invalid exposedTo synchronously.

July 2026

• 21 Jul — getTools() specified; annotations moved into its own object. Annotations are tool.annotations.readOnlyHint, not tool.readOnlyHint. *Do:* move top-level hint booleans into an annotations object — the inspector reads only the nested form.
• 20 Jul — Tool visibility algorithm clarified (which documents see which tools, given exposedTo and Permissions Policy). *Do:* nothing, unless you rely on cross-origin visibility; re-test it.

June 2026

• 17 Jun — registerTool() rejects when its signal is already aborted. *Do:* create the controller before registering; don't reuse one you've aborted.
• 11 Jun — ModelContextClient removed for now. The client-side (agent) interface left the spec; discovery is getTools(). *Do:* drop any dependence on it.
• 8 Jun — registerTool() returns a promise. Registration is async and can reject (duplicate name, empty description, invalid schema). *Do:* await it and handle rejection; a swallowed rejection is a tool that silently never existed. A private-browsing section joined the security & privacy considerations the same day.
• 5 Jun — registerTool() gated on document.domain being disabled. *Do:* if a legacy page still sets document.domain, registration fails; remove the setter.

May 2026

• 28 May — Security & privacy considerations ported into the spec. Tool poisoning, output injection, misrepresentation of intent, privacy leakage through over-parameterization, same-origin violations; mitigations include input length limits and the untrusted/consequential annotations. *Do:* read it; it is the rationale behind half of the inspector's checks.
• 27 May — modelContext getter moved from Navigator to Document. document.modelContext is the entry point; navigator.modelContext is legacy. *Do:* const mc = document.modelContext ?? navigator.modelContext; until the browsers you target have all moved — the inspector flags pages that reference only the old location.
• 20 May — toolchange event and the tools Permissions Policy specified. Registration changes fire toolchange on the context; embedding a page in an iframe requires allow="tools" for its tools to be visible. *Do:* if your tools live in an embedded widget, ask the host page to delegate the policy.
• 19 May — ModelContext scoped to Document; detached documents handled. Each document owns its tools; tools die with the document. *Do:* re-register after a full navigation; single-page apps keep theirs.

Earlier: the shape that was removed

The original August 2025 explainer registered tools through navigator.modelContext.provideContext({ tools: [...] }) and had a clearContext(); both are gone in favor of per-tool registerTool() / unregisterTool() with AbortSignal, and title joined the tool dictionary for display names. If your code still calls provideContext, it registers nothing in a current implementation. The inspector's live scan reads tools through getTools() and reports what a current browser would actually expose, which is the fastest way to find out whether a legacy integration still works.

Related guides

• WebMCP vs MCP: what's the difference? — Same vocabulary, different transport, hosting, and trust model — and why most sites end up with both.
• Writing WebMCP tool descriptions agents select correctly — The description is the only thing an agent reads before choosing. Here's what belongs in it — and what must not.