Designing Website Tools for AI Agents with WebMCP

WebMCP is a September 2026 draft for exposing website functions to browser agents as structured tools

Direct answer

WebMCP is a September 2026 draft for exposing website functions to browser agents as structured tools. It can describe inputs and connect agent requests to page functionality, but a tool description is not evidence, authorization, or proof that a task succeeded. Start with narrow read-only tasks, validate every argument on the server, keep consequential actions behind explicit user review, and return stable structured results. Maintain the ordinary human interface and accessible semantic HTML because support remains experimental and agents use several interaction modes. GEO teams should treat tool readiness as a separate layer from content retrieval, citation visibility, and commerce integration.

A readable page is not yet an executable service

A product page may explain every option clearly while forcing an agent to infer how dropdowns, buttons, validation, and results fit together. The agent can attempt to operate the interface through screenshots, the DOM, or the accessibility tree. It can still select the wrong variant or miss a validation message.

WebMCP addresses a different problem from content publishing. Its draft specification describes a JavaScript interface through which a web application exposes functionality as named tools with natural-language descriptions and structured input schemas. An agent can invoke the tool rather than reconstructing the action from pixels alone.

As of September 14, 2026, the document is a Draft Community Group Report. It explicitly says it is not a W3C Standard and is not on the W3C Standards Track. Chrome’s February 2026 announcement describes an early preview for prototyping participants. Those labels should remain attached to any implementation plan.

Calling a site “WebMCP ready” today should therefore mean that it has a tested experimental implementation for an identified environment. It should not imply universal browser or assistant support.

WebMCP adds a tool contract

The draft describes declarative and imperative forms. The declarative approach connects standard operations represented through HTML forms. The imperative API supports more dynamic behavior through JavaScript tool registration. Both aim to give an agent a clearer contract than raw interface actuation.

A tool contract answers several practical questions: What is the operation called? What does it do? Which arguments are accepted? Which values and types are valid? What result or error comes back? Those are interface questions, not proof that the underlying business facts are correct.

For example, a find_compatible_models tool might accept an equipment identifier, market, and required temperature range. The server still needs an authoritative compatibility record. If the database contains an outdated mapping, a perfectly valid tool call can return the wrong product.

Tools and readable evidence should therefore complement each other. The tool can return a model identifier, compatibility status, source-record version, and explanatory URL. The public page can explain testing conditions and exceptions. A user or agent can then inspect the basis of the result instead of receiving an opaque success flag.

Separate discovery from action

Content discovery asks what information is available and relevant. Tool discovery asks which operations the site offers. Execution changes or retrieves state through an interface. Confirmation establishes what actually happened. These are four distinct stages.

A citation to a shipping policy does not book a shipment. A successful product-search call does not add an item to a cart. A submitted form does not prove that a downstream quote was created unless the response and later record establish it.

This separation prevents a common reporting error in agentic GEO. A team may improve article citations and describe the site as more actionable, although no tool has been invoked. Another team may expose a tool and assume its existence improves search visibility. Neither conclusion follows without additional evidence.

Use a stage-specific record:

This table is an editorial systems model. The WebMCP draft supplies tool mechanisms; it does not prescribe this reporting framework.

Choose the smallest useful operation

Broad tools create ambiguous authority. A tool called manage_account hides whether it reads preferences, changes an address, or closes the account. Narrow operations make permissions, validation, and review easier to understand.

Begin with read-only tasks that remove repetitive interface work. Product filtering, service-area lookup, configuration validation, appointment availability, and order-status retrieval can be candidates when their data access rules are clear.

Then isolate consequential operations. Creating a support ticket, submitting a quote request, reserving inventory, and placing an order have different effects. They should not be bundled into a single search tool merely because they appear in one human journey.

The draft includes annotation hints for read-only, untrusted-content, and consequential characteristics. A hint helps an agent reason about a tool. It is not a security boundary. The server must still authenticate the caller where required, authorize the operation, validate arguments, enforce business rules, and protect sensitive output.

Design a tool around an auditable task

1. Write the user goal and the exact state change or retrieval required.
2. Define the smallest operation that completes that task without unrelated authority.
3. Specify typed inputs with units, markets, versions, and allowed values where they affect the result.
4. Define success, validation failure, authorization failure, conflict, and temporary failure separately.
5. Return a stable identifier, effective result, source version, and next allowed action where appropriate.
6. Require explicit user review before a consequential commitment.
7. Log the request and server outcome under the organization’s privacy and retention rules.
8. Test direct calls, repeats, cancellation, stale state, invalid combinations, and partial downstream failures.

The server should treat tool arguments as untrusted input, even when a browser agent generated them from the page’s own content. Client-side schema validation improves usability but does not replace server-side checks.

Use idempotency controls where repeated submission could duplicate a consequential operation. The exact implementation depends on the application. A request identifier, expiration policy, and server record can help distinguish a retry from a new order or ticket.

Do not return “success” when only the browser-side handler completed. If a quote service times out after receiving the request, expose an indeterminate or pending state with a lookup identifier rather than inventing a completed quote number.

Keep user review meaningful

A user cannot meaningfully approve “continue” without seeing the important values. Before a purchase, booking, deletion, or submission, present the item, quantity, price basis, market, recipient, and other consequential terms. If a value can change between planning and execution, refresh it at confirmation.

Avoid preselecting an irrevocable action through a descriptive tool call. A search request can prepare a cart or a draft, but the final commitment should be its own operation. This allows the agent and the interface to explain what will happen.

OpenAI’s agent safety guidance recommends keeping untrusted data separate from instructions, using structured outputs, applying approvals to tool operations, and evaluating workflows. Those recommendations concern OpenAI agent systems. They reinforce a general design principle but do not define browser-wide WebMCP behavior.

The WebMCP permissions-policy integration described in the draft governs access to the proposed API under a policy-controlled feature. That browser mechanism should not be mistaken for the user’s business authorization to buy, disclose data, or modify an account.

Preserve the human and accessible interface

An experimental tool layer should not become the only path through the service. Users need a clear interface for reviewing inputs, correcting errors, completing tasks manually, and understanding the resulting state. This also provides a fallback when the browser or agent does not implement the draft.

The web.dev guide on agent-friendly website design explains that agents can use screenshots, HTML, and the accessibility tree. It recommends semantic interactive elements, explicit labels, stable layouts, and visible state changes. These practices also improve the human interface and assistive-technology support.

Accessible HTML is not a substitute for a tool contract, and a tool contract is not a substitute for accessibility. A labeled address form communicates purpose to people and interface agents. A structured address-validation tool can expose a bounded operation. Both depend on the same business rules and should return consistent results.

Test the ordinary path after adding the tool. The page should still work with keyboard navigation, assistive technology, and conventional form submission according to the site’s support requirements. A tool implementation that bypasses visible error handling can create two inconsistent products on the same URL.

Return results an agent can verify

A good result is structured enough to distinguish status, data, and explanation. Avoid a single prose string such as “Everything is all set.” It hides which item was changed and whether the operation is final.

For a fictional quote-request tool, the result might contain a request identifier, accepted configuration, submission time, status, expected next step, and a human-readable URL. If a product combination is invalid, return the conflicting fields and allowed alternatives rather than silently substituting a different configuration.

Do not claim a real-time value if the result came from a cached source without an applicable timestamp. Return source freshness where it matters. For a lookup spanning regional catalogs, include the market in the result so a US item is not presented as available in the UK or Europe.

OpenAI’s web-search API documentation shows how another tool system exposes calls, source information, and citations. It is not a WebMCP implementation guide. It does illustrate why an audit should retain tool results and source identity rather than only the final natural-language answer.

Test failure modes as first-class behavior

The happy path is rarely the hardest path. Test an expired session, revoked permission, unsupported market, stale inventory, network timeout, duplicate request, page navigation, and cancellation during execution. Verify that each produces a truthful state.

Use a test matrix that pairs operation type with consequence and failure state. A read-only lookup can often retry safely. A payment or deletion retry may require a prior-status check. The tool description should not be relied upon to make a non-idempotent operation safe.

Measure task completion at each stage. Useful engineering measures include valid-call rate, server success rate, duplicate-operation rate, confirmed completion, and recovery from expected errors. Useful content measures include whether the result explanation preserves conditions and links to the correct evidence.

Do not report tool calls as conversions unless the defined business event occurred. A call to calculate shipping is not an order. A draft support ticket is not a resolved issue. Preserve the status transition that the metric claims to count.

Decide whether WebMCP belongs on the roadmap

Prioritize a prototype when users repeat a structured website task, the underlying service has clear business rules, and the organization can support experimental browser behavior. Delay it when the data is unreliable, the operation cannot be authorized safely, or ordinary accessibility and forms remain broken.

For Xindar’s English-market GEO work, WebMCP can be evaluated as an emerging action layer after crawlability, evidence quality, and site task design are in order. This is a strategic fit statement, not a claim that the current Xindar site or a client deployment implements the draft.

Frequently asked questions

Is WebMCP a W3C standard?

No. The September 14, 2026 publication identifies itself as a Draft Community Group Report and says it is outside the W3C Standards Track.

Will WebMCP make a page rank or get cited?

No such guarantee is established by the draft. Tool exposure concerns agent interaction. Search eligibility, retrieval, citation, and recommendation need separate evidence.

Can a schema make a consequential tool safe?

No. A schema can constrain the shape of inputs. Authentication, authorization, server validation, user review, idempotency, and truthful confirmation remain application responsibilities.

Should a site wait for broad support?

A site can improve semantic HTML, accessibility, task boundaries, and server validation now. A WebMCP prototype makes sense when the organization has a specific target environment and accepts the maintenance cost of an evolving draft.

Source and method note

The draft specification dated September 14, 2026 and official developer pages were retrieved on September 15, 2026. Tool names, the quote-request example, readiness table, metrics, and implementation workflow are original proposals. No production WebMCP deployment, browser compatibility survey, transaction, visibility effect, or named human review is claimed.