The Safe WebMCP Pilot: Which Website Actions Should Agents Be Allowed to Take First?

The safest first WebMCP pilot is not a one-click checkout.

It is a task a user could already complete without risk, but would rather not complete manually: narrow a catalog, find the right support path, identify an available appointment, or run a diagnostic. These actions let a team test whether structured agent tools are clearer and more reliable than screen-scraping without making a bad agent decision expensive.

That is the right starting point because WebMCP changes the interface between a website and an agent, not the underlying responsibility. A website can expose structured tools with clear inputs and outputs, so an agent does not have to infer what a button or form field means from the DOM. Chrome describes WebMCP as a progressive enhancement and an active proposal; it is available through an origin trial, not a reason to lower the bar for production safeguards. (WebMCP)

The question for a pilot is therefore not, “What can an agent do?” It is, “Which actions can an agent do while a wrong, repeated, or manipulated call has limited consequences?”

Start With Actions That Are Useful, Bounded, and Easy to Undo

Early tools should have four properties:

• A clear user intent. The tool maps to a real request such as “show laptops under $1,000” or “find an appointment next week.”
• A narrow effect. It reads data, changes a temporary view, or prepares a draft rather than committing a business transaction.
• An observable result. The page visibly shows the selected filters, proposed slot, support form, or diagnostic result.
• A safe recovery path. The user can change the result, abandon it, or start over without a support ticket or financial reversal.

Chrome’s own examples point in this direction: product search and refinement, support-form navigation and field mapping, complex date selection, and developer diagnostics. It separately calls out purchases as sensitive actions for which a site can request user interaction with a confirmation dialog. (WebMCP)

That produces a practical pilot order:

The table is a design principle, not a compliance checklist. A search tool can become sensitive if it queries private health records. An appointment selector can become consequential if it reserves scarce capacity. Classify the action by the data it exposes, the state it changes, and the cost of being wrong—not by the friendly name of the button.

Make the First Tools Single-Purpose

A broad tool called manage_account looks convenient to a developer and ambiguous to an agent. It could include a password change, address update, plan cancellation, or email preference change—actions with very different consequences. An early pilot should expose smaller verbs that make the boundary obvious.

Chrome’s guidance makes the same case: a tool should consist of a single function, overlapping tools make tool choice harder, and registration should follow the page state in which a tool is actually useful. Clear names should distinguish a preparatory action from an immediate execution. (WebMCP best practices)

Prefer this progression:

• search_products over shop;
• filter_results over find_the_best_option;
• start_support_request over contact_support;
• find_available_slots over book_appointment;
• run_read_only_diagnostics over fix_my_site.

Good tool names state what happens. Good schemas make it difficult to call the tool with vague or overloaded instructions. Use explicit types, enums for controlled choices, and plain-language parameter names. If an agent needs to calculate a hidden ID, guess what a label means, or combine five unrelated decisions into one call, the tool is doing too much.

A basic availability tool, for example, can return options but refuse to commit one:

await document.modelContext.registerTool({
  name: 'find_available_slots',
  description:
    'Find appointment times that match the requested date range and service. Returns options only; it does not book an appointment.',
  inputSchema: {
    type: 'object',
    properties: {
      service: { type: 'string', enum: ['consultation', 'repair'] },
      startDate: { type: 'string', format: 'date' },
      endDate: { type: 'string', format: 'date' },
    },
    required: ['service', 'startDate', 'endDate'],
  },
  annotations: { readOnlyHint: true },
  execute: async ({ service, startDate, endDate }, { signal }) => {
    return findSlots({ service, startDate, endDate, signal });
  },
});

WebMCP’s Imperative API supports tool registration with a name, description, JSON-schema input, and an execution function. It also supports annotations such as readOnlyHint and untrustedContentHint, plus cancellation through an AbortSignal. Those details are useful not because annotations create security by themselves, but because they make a tool’s contract explicit and give the implementation a chance to stop unnecessary work. (Imperative API)

Put a Human Checkpoint Before Commitment

The rule for consequential actions should be simple: agents may prepare; users must commit.

A user confirmation should be required before an action that:

• spends money, starts a subscription, or creates a recurring charge;
• submits a legal, medical, financial, employment, or other sensitive form;
• changes account access, security settings, addresses, or recovery details;
• deletes, cancels, publishes, sends, or shares information outside the current session;
• makes a reservation or operational change with a material cancellation cost;
• runs a repair that alters customer data, infrastructure, or production configuration.

Do not hide that checkpoint behind a tool description. Render a confirmation in the site’s own interface, summarize the exact effect in human terms, and show the user the final items, price, recipient, time, and any irreversible consequences. A dialog that says “Continue?” after an agent has already committed the change is not a confirmation; it is a status message.

Chrome’s agent-security guidance recommends treating tools as state-changing unless their description or readOnlyHint says otherwise, and calls for user confirmation where needed. It also notes that browser agents may work within an authenticated session, where an apparently ordinary action can carry real account authority. (Agent security considerations for WebMCP)

Treat Tool Output as Data, Not Instructions

A safe pilot needs a boundary in both directions. Teams often focus on what the agent can send to their server, then forget that the agent also reads results from pages and tools.

Search results, support tickets, reviews, product listings, and error messages can contain untrusted text. An attacker can try to place instructions in that content in the hope that an agent will follow them. This is a form of indirect prompt injection, and it matters more when an agent has an authenticated session and callable tools.

The website cannot solve an agent’s entire prompt-injection problem. It can make a safer contract:

• return structured fields rather than an unbounded HTML or prose blob;
• cap result size and paginate where practical;
• clearly mark fields that may contain user-generated or third-party content;
• never place operational instructions in a tool response;
• validate permissions and intent on the server for every action, not only in the agent-facing schema.

Chrome recommends defense in depth for WebMCP agents, including token limits, recognition of untrusted content, cross-origin restrictions, and confirmation. Its warning is worth taking seriously: tool descriptions and real-time outputs can carry malicious text, and model-only defenses cannot guarantee correct handling of indirect prompt injection. (Agent security considerations for WebMCP)

Keep Authority Local to the Task

The narrowest pilot has narrow authorization as well. A filter_results tool should not incidentally expose saved searches. A diagnostic tool should not receive production administrator credentials. A support intake tool should submit only to the current account’s case flow, with server-side authorization that remains correct even if the client is modified.

This matters in embedded experiences, too. Chrome says cross-origin iframe tool registration is disabled by default and requires both a Permissions Policy and explicit origin gating. That is a useful model for pilot design: make exposure an intentional allowlist, not an ambient property of every page where an agent might appear. (Imperative API)

Registration should also be contextual. Expose find_available_slots while availability is visible; remove it when the user is no longer in that flow. Expose start_support_request where the account context is known; do not register it broadly across public pages. Fewer, better-scoped tools reduce the chance of a wrong selection and make audit logs intelligible.

Measure the Pilot for Safety and Usefulness Together

The launch decision should not be based only on task completion. A fast, incorrect, or surprising action is worse than a slow form.

Track at least these pilot measures:

• completion rate for the intended, bounded task;
• successful result rate after user review;
• confirmation shown, confirmed, edited, and abandoned rates for sensitive paths;
• cancellation, error, duplicate-action, and recovery rates;
• tool calls rejected by authorization or input validation;
• support contacts that indicate confusion, surprise, or unintended changes;
• time saved compared with the ordinary interface.

Review recordings or test transcripts only with appropriate privacy controls. More importantly, build adversarial cases into evaluation: ambiguous requests, stale page state, a mid-flow permission change, duplicate calls, cancellation, and malicious text inside returned content. If the tool cannot fail safely in those cases, it is not ready for more authority.

Expand by Consequence, Not by Novelty

A sensible rollout climbs a ladder:

1. Read and navigate: search, filters, status lookup, availability, diagnostics.
2. Prepare: prefilled support drafts, wishlists, comparison sets, proposed bookings.
3. Request confirmation: booking, case submission, data sharing, account changes, checkout.
4. Commit after explicit consent: only when the user sees and accepts the exact result.

That order is less flashy than an autonomous purchasing demo. It is also how a team learns whether its schemas, authorization, auditability, and human handoff actually work before they touch costly decisions.

WebMCP is promising precisely because it can replace brittle imitation of a UI with a more explicit contract. The contract should begin with actions that earn trust: searchable, reviewable, cancelable, and visibly under the user’s control. Let the agent save the clicks first. Let the human keep the consequences until the system has proved it deserves more.