What Is WebMCP? Tools, Security, and SEO

WebMCP gives a web page a structured way to tell an AI agent, “These are the actions this site supports, these are the inputs, and this is how to call them.”

That can make an agent workflow more reliable than guessing from pixels or clicking through an unfamiliar interface. It does not make the site rank higher, replace an API, or remove the need for ordinary web accessibility and security.

Short answer: Use WebMCP when a browser agent needs a small set of well-defined actions inside the user's current page and session. Keep the normal UI as the source of truth for people, reuse existing application and server policy, separate read tools from consequential writes, and test the full authenticated workflow. Treat the API as experimental: the current specification is a W3C Community Group draft, not a finished web standard.

This guide reflects the public WebMCP draft and browser documentation reviewed on August 26, 2026.

What WebMCP Is

The current WebMCP draft specification extends Document with document.modelContext. A page can register an imperative tool with:

• A stable name.
• A human-readable title and description.
• A JSON Schema input contract.
• An execution callback.
• Optional annotations.
• Registration options such as an abort signal and exposed origins.

The draft also points to a proposed declarative WebMCP path for forms, but that section is still a TODO and its normative details are incomplete. The intended direction is for a browser to synthesize a tool contract from ordinary form controls rather than requiring every action to be registered in JavaScript.

The basic lifecycle is:

1. The page registers a tool.
2. An eligible agent discovers the tools exposed from the active document.
3. The agent selects a tool and supplies structured inputs.
4. The browser mediates the invocation.
5. The page executes existing client-side logic and returns a result.
6. The agent uses that result to continue the user's task.

The specification does not require the browser to expose those tools through the Model Context Protocol transport. A browser can connect them to an agent through MCP, proprietary function calling, or another mechanism. “WebMCP” describes the page-facing web API, not a promise that every page becomes a conventional remote MCP server.

The Current Status Matters

WebMCP is early.

The specification explicitly says it is not a W3C Standard and is not on the W3C Standards Track. Chrome announced an early preview of WebMCP in February 2026 and an experimental origin trial beginning with Chrome 149 in its agentic web updates. Experimental support and debugging tools are useful for testing, but they are not universal browser availability.

Plan for change:

• Feature-detect the current API.
• Make unsupported browsers a clean no-op.
• Keep tool registration behind a small adapter.
• Test against the live draft and target browser, not a copied code sample.
• Avoid presenting experimental support as a universal customer capability.

Older articles and prototypes may use navigator.modelContext. The current draft defines document.modelContext. If implementation guidance and the live draft disagree, use the live draft and record the version or review date in your engineering notes.

A Minimal Imperative Tool

A read-only tool can look like this:

const modelContext = document.modelContext;

if (window.isSecureContext && typeof modelContext?.registerTool === 'function') {
  const lifecycle = new AbortController();
  function cleanupOrderStatusTool() {
    window.removeEventListener('pagehide', cleanupOrderStatusTool);
    lifecycle.abort();
  }

  // Establish a fallback before asynchronous registration begins.
  window.addEventListener('pagehide', cleanupOrderStatusTool, { once: true });

  try {
    await modelContext.registerTool({
      name: 'get-order-status',
      title: 'Get order status',
      description: 'Read the current status for one order the signed-in user can access.',
      inputSchema: {
        type: 'object',
        properties: {
          orderId: { type: 'string', minLength: 1, maxLength: 64 },
        },
        required: ['orderId'],
        additionalProperties: false,
      },
      annotations: {
        readOnlyHint: true,
        untrustedContentHint: true,
      },
      async execute({ orderId }, { signal }) {
        return getAuthorizedOrderStatus(orderId, { signal });
      },
    }, { signal: lifecycle.signal });
  } catch (error) {
    cleanupOrderStatusTool();
    console.error('WebMCP tool registration failed', error);
  }

  // In a component, bind the same callback to cleanup or unmount before
  // awaiting registration instead of relying only on pagehide.
}

Create the cleanup callback before awaiting registration and keep it for the lifetime of the page or component that owns the tool. Call it during real cleanup, including registration failure, not immediately after successful registration.

The schema helps an agent construct an input. It should not be your only validation. Validate the runtime value again, reject unexpected properties, enforce length and type limits, and let the server decide whether the signed-in user can access the requested order.

WebMCP, MCP, Accessibility, And SEO Solve Different Problems

These layers are complementary.

Google's generative AI optimization guide says sites do not need special AI markup to appear in Google's generative Search features. WebMCP should not be marketed as such markup. It is an interaction contract for agents operating a page.

Keep the agent-friendly website checklist as the baseline. A clear button, label, heading, error, and success state remain useful when WebMCP is unavailable and when an agent needs visual or accessibility-tree evidence.

Start With User Jobs, Not Every Endpoint

A deep WebMCP tool should represent a complete user job.

Good candidates:

• Read the status of a current order, Run, booking, or support case.
• List a concise set of records the user can already view.
• Start one bounded workflow after explicit confirmation.
• Apply a well-defined filter and return a reviewable result.

Weak candidates:

• One tool for every internal REST endpoint.
• Generic “execute request” or “run query” tools.
• Tools that accept raw URLs, code, or unconstrained instructions without a real product need.
• Tools that duplicate buttons but omit the UI's validation and policy checks.
• Huge read tools that return an entire private record when the next decision needs three fields.

Choose the smallest tool surface that lets the agent complete a meaningful task. Fewer, deeper tools are easier to describe, authorize, test, and maintain.

Design Inputs For Safe Inference

Agent-generated arguments are untrusted inputs.

For each tool:

• Require an object rather than accepting arbitrary primitives.
• Use stable IDs obtained from a prior scoped read tool.
• Declare required fields.
• Reject additional properties.
• Bound string lengths and integer ranges.
• Use enums where the set is closed.
• Avoid free-form URLs unless the action truly needs them.
• Treat a schema default as documentation, then apply a server or runtime default explicitly.
• Pass cancellation through to network requests.

Do not let a model invent account, workspace, project, or record IDs and rely on the client to catch the mistake. Give the agent a read-only context tool that returns the IDs the signed-in user can currently access, then verify the selected scope again on the server.

Separate Read Tools From Consequential Writes

The draft defines readOnlyHint and untrustedContentHint annotations.

readOnlyHint: true tells an agent that a tool is intended only to read. untrustedContentHint: true tells the client that returned data should receive heightened security handling because it can contain untrusted content.

Both are hints. They do not replace:

• Authentication.
• Authorization.
• CSRF and origin protections where relevant.
• Server-side validation.
• Rate limits and cooldowns.
• Plan or entitlement checks.
• Credit, inventory, or budget checks.
• Idempotency.
• User confirmation.
• Audit logging.

For a write action, make the consequence explicit in the tool title, description, and input. If the action can spend money, consume credits, send a message, publish content, or change account state, require a confirmation field and keep the final policy decision on the server.

Do not use a boolean confirmation as a security boundary. It is an acknowledgement inside the tool contract. The authenticated backend still decides whether the action is allowed.

Reuse The Signed-In Session Carefully

WebMCP is valuable partly because it can operate in the page the user already opened. That also means the tool can sit near private state.

Use the same access path as the visible product:

1. Obtain the current session through the application's normal authentication helper.
2. Send requests to the same protected server routes the UI uses.
3. Recheck ownership and entitlements on every call.
4. Return only the fields required for the agent's next step.
5. Never return access tokens, secrets, raw provider payloads, or unrelated private records.

Avoid building a parallel “agent API” that skips product policy. A WebMCP callback is another client of the application, not a trusted backend.

Treat Tool Results As A Prompt-Injection Boundary

The WebMCP draft's security section calls out tool metadata poisoning and output injection. A tool description can contain malicious instructions, and a legitimate tool can return user-generated content containing instructions aimed at the agent.

Design for that boundary:

• Keep tool descriptions factual and short.
• Do not interpolate user content into tool descriptions or schemas.
• Mark outputs containing user, provider, community, or web content as untrusted.
• Return structured fields instead of large narrative blobs where possible.
• Limit result counts and field lengths.
• Keep identifiers, status, and navigation paths separate from free text.
• Do not let a returned instruction authorize a second action.
• Require fresh confirmation for consequential writes.

An annotation can help a supporting client handle untrusted output. It cannot make the output safe by itself.

AEO Table's Bounded WebMCP Example

AEO Table currently registers four tools inside the authenticated dashboard when the browser exposes the current API.

This design uses the product model consistently: a Task is the monitoring configuration, and a Run is one execution. The write tool does not accept an arbitrary query set or provider payload. It starts an existing Task the user already owns.

The implementation also:

• Feature-detects document.modelContext and becomes a no-op when unavailable.
• Uses an abort signal to unregister tools with the page lifecycle.
• Rejects unknown input fields and bounds identifiers and list sizes.
• Scopes every request to Brands and Tasks in the current workspace.
• Keeps user and provider-derived data marked as untrusted content.
• Refreshes visible UI state after a newly created Run.

That pattern is more important than the exact tool names. Agent actions should deepen the existing product contract, not create a second product hidden behind tool calls.

Test The Workflow, Not Just Registration

A registration unit test is necessary but insufficient.

Use this test matrix:

Chrome's agent-ready developer toolkit describes testing agent interactions with current browser tooling. Preserve the browser version, flags or origin-trial state, tool list, invocation inputs, server response, visible UI result, and console errors. “The tool registered” is not proof that the user job completed safely.

Measure Agent Readiness Separately From Search Visibility

WebMCP adds an execution surface. SEO and AEO measure discovery and answer presence.

For WebMCP, useful product metrics include:

• Eligible agent sessions.
• Tool discovery rate.
• Invocation attempts.
• Validation failures.
• Authorization failures.
• Confirmed write rate.
• Successful completion rate.
• Duplicate prevention rate.
• Time to completion.
• UI fallback rate.

For AI search visibility, keep separate measures:

• Brand mentions.
• Competitor mentions.
• Citations and source domains.
• Answer framing.
• Channel and market differences.
• Detectable referral visits.

Do not claim that adding a WebMCP tool improved rankings, citations, or referrals because both changed after release. Use the AEO content experiment protocol for causal claims and keep agent completion evidence in its own lane.

Common Mistakes

• Calling a Community Group draft a completed W3C Standard.
• Shipping navigator.modelContext from an obsolete example without checking the current draft.
• Treating WebMCP as a ranking signal, crawler directive, or special AI schema.
• Removing semantic labels or visible controls because a tool exists.
• Exposing every backend endpoint as a shallow tool.
• Trusting client-side workspace IDs without server ownership checks.
• Returning access tokens, raw provider responses, or full private records.
• Marking a write tool as read-only to reduce confirmation friction.
• Assuming readOnlyHint or untrustedContentHint enforces policy.
• Letting a tool retry a charge, booking, message, or Run without idempotency.
• Testing only a happy-path invocation in one experimental browser build.

A Practical Adoption Sequence

1. Choose one high-value user job that already works through the UI.
2. Map its existing authentication, authorization, validation, limits, and success state.
3. Add one scoped read tool that returns safe IDs and concise context.
4. Add one bounded action tool only if the job requires it.
5. Require explicit acknowledgement for consequential work.
6. Reuse the same server routes and policy checks as the UI.
7. Add lifecycle cleanup and unsupported-browser fallback.
8. Test invalid input, unauthorized scope, retries, cancellation, and UI reconciliation.
9. Run the workflow through a supported browser agent.
10. Measure task completion separately from search and answer visibility.

The Bottom Line

WebMCP can make a browser agent more precise because the page exposes the actions it actually supports. The durable implementation is not the one with the most tools. It is the one with a small, well-scoped surface that reuses the product's existing authority boundaries and remains safe when the model, input, or returned content is wrong.

Keep semantic HTML and the visible UI intact. Feature-detect the experimental API. Treat annotations as hints. Keep the server authoritative. Then verify the same user job through both the agent path and the human path.

Create a free AEO Table account to run a stable AI visibility Task, inspect concise Run and Report evidence, and evaluate an authenticated WebMCP workflow where supported.