Frontend interview: How would you safely expose WebMCP tools to browser agents?

Question

An ecommerce checkout page wants to trial WebMCP so a browser agent can filter products and fill forms. How would you define tools, limit permissions, preserve user control, and verify that the agent does not invoke high-impact actions incorrectly?

Context and boundaries

WebMCP is a proposed web standard. Chrome documentation describes declarative HTML-form tools and imperative JavaScript tools, and Chrome 149 provides an origin trial. This question is about progressive enhancement in a browser tab with a human in the loop. WebMCP is not presented as a stable backend protocol that runs without a browser context, nor as a replacement for server-side authorization.

Clarify first: Which actions only search and fill, and which place an order or charge money? Should tools be visible only to the top-level page or also to a cross-origin iframe? Must the user confirm again before final submission? What happens when the agent does not support WebMCP or the origin trial ends?

What the interviewer is testing

The interviewer is testing whether you can turn agent actuation into a frontend contract: clear tool descriptions and input schemas, existing login, CSRF, business authorization, and user confirmation still in the path, least-privilege cross-origin exposure, and evaluations for tool choice, parameters, and results.

30-second answer

Split the journey into read-only, reversible, and irreversible actions. Use declarative or imperative tools for search and fill, while order submission keeps server authorization and explicit confirmation. Expose only necessary fields, default to the current page and origin, and require explicit Permissions Policy for cross-origin iframes. Before release, evaluate tool selection, parameter validation, error handling, and refusal paths, while keeping the normal UI as a fallback.

Step-by-step deep dive

1. Risk tiers: search, filter, and fill are low-risk or reversible; place-order, pay, and address changes are high-impact and must not run automatically just because an agent has a tool.
2. Contract: each tool gets a stable name, agent-facing description, JSON input schema, and structured result. Enumerations, ranges, currency, and inventory versions are validated on both client and server.
3. Reuse business logic: the callback calls existing form state and domain functions instead of copying a request path that bypasses the UI. Before execution, check login, CSRF, cart version, price, and inventory.
4. Permission boundary: expose by default only to the top-level window and same-origin contexts. Share with a cross-origin iframe only when Permissions-Policy and the iframe allow attribute explicitly permit it, and do not return unnecessary personal data.
5. User control: let search and fill show a visible change. Require an in-page confirmation and summary for order, payment, or deletion; the tool result states whether the action completed, awaits confirmation, or was refused.
6. Progressive rollout: enable internal accounts behind a local flag or origin trial first. Provide capability detection, the normal UI, and a DOM-automation fallback when WebMCP is unavailable; log tool version, result, and refusal reason.
7. Evaluation and monitoring: build a task set for tool-choice accuracy, valid-parameter rate, completion, false invocation, refusal correctness, and confirmation coverage. Set a zero-false-invocation gate for high-impact tools and revoke registration on anomalies.

Model answer

I would split checkout into search, fill, and submit. Search and fill are reversible, so WebMCP can improve agent targeting. Order and payment remain subject to existing server authorization, price and inventory checks, and page confirmation. WebMCP is experimental; the Chrome 149 origin trial is suitable for controlled validation, not a replacement for backend permission.

The tools expose only the fields needed for the current journey and reuse existing form and domain logic in their callbacks. The input schema constrains item IDs, quantities, and address formats; the server checks login, CSRF, inventory, price, and order idempotency again. By default I expose tools to the top-level page and same-origin agent. If a cross-origin iframe is required, I configure both the permission policy and iframe allow, and never return the whole account profile.

const controller = new AbortController();

document.modelContext?.registerTool({
  name: "cart_set_quantity",
  description: "Set the quantity of one visible cart item; never submits an order.",
  inputSchema: {
    type: "object",
    properties: {
      itemId: { type: "string", minLength: 1 },
      quantity: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["itemId", "quantity"]
  },
  async execute({ itemId, quantity }) {
    const result = await setVisibleCartQuantity(itemId, quantity);
    return { content: [{ type: "text", text: result.summary }] };
  }
}, { signal: controller.signal });

Even if an order tool exists, it returns “user confirmation required” and cannot charge money itself. Each call records the tool version, parameter-validation result, and page state. The evaluation set covers wrong items, excessive quantity, stale price, declined confirmation, and WebMCP unavailability. WebMCP is therefore revocable progressive enhancement; business authorization and user intent remain in the existing path.

Common mistakes

• Describing an early-trial WebMCP feature as a stable backend API.
• Exposing a universal tool that can pay, delete an account, or change any address directly.
• Validating the schema only in the browser and skipping server checks for login, inventory, price, and idempotency.
• Sharing tools with cross-origin iframes by default or returning the full user profile as a tool result.
• Providing no normal UI, capability detection, revocation path, or agent evaluation set.

A strong answer covers the tool contract, server authorization, origin isolation, user confirmation, fallback, and quantitative evaluation. “Add descriptions to buttons” does not demonstrate safe actuation.

Follow-up questions and responses

Why not register order placement as a WebMCP tool too?

You can register a tool that prepares an order summary, but final submission should require page confirmation and server authorization. A tool call does not prove that the user agreed to pay and cannot bypass price, inventory, or fraud checks.

How do you restrict tool exposure to a cross-origin iframe?

Do not expose it to cross-origin contexts by default. If required, use an explicit Permissions-Policy and iframe allow configuration, then limit readable and writable data at the tool layer. Log origin, page lifecycle, and revocation.

What if the agent sends schema-valid but business-invalid parameters?

Reject invisible items, stale state, and values outside the current user’s scope in the client, then repeat business validation on the server and return a structured refusal. Do not turn strings into arbitrary actions or silently rewrite parameters.

How do you prove that the agent understands the tools?

Use a fixed task set and real pages to measure tool choice, valid-parameter rate, completion, false invocation, and refusal correctness. Set a zero-false-invocation gate for payment and deletion, and rerun evaluations after API changes.