tools Permissions Policy. Declarative attributes, testing surfaces,
browser-agent mediation, cancellation, and output-schema behavior may continue
to change.
Chrome offers WebMCP through an origin trial beginning in Chrome 149. Local
development uses the dedicated chrome://flags/#enable-webmcp-testing flag.
Track the Chrome WebMCP overview
for current availability.
Implementations should track the current Community Group draft,
keep domain operations separate from the browser registration adapter, use
feature detection, and test both native and polyfill paths. MCP-B extensions
must remain clearly distinguished from the standard surface.
The current proposal defines document.modelContext. Navigator-based model
context APIs are not part of that surface; MCP-B retains them only as
compatibility shims. Adapter boundaries reduce migration cost.
See Try the native Chrome preview and
Test native and polyfill.
Upstream sources to track
Use first-party sources for compatibility decisions:
MCP-B follows those boundaries by making
document.modelContext the primary
surface, using getTools() for discovery, feature-detecting Chrome’s optional
executeTool() extension, using AbortSignal for cleanup, and keeping legacy
helpers as compatibility APIs.
outputSchema is not part of the current W3C/Chrome WebMCP tool dictionary.
MCP-B keeps it as helper metadata for TypeScript inference, structured MCP
responses, and package/runtime adapters. Do not rely on native browser WebMCP
to validate tool output against it.