An agent-ready website gives an AI agent narrow, inspectable operations instead of asking it to infer every action from pixels. WebMCP is a proposed standard for exposing those operations from a webpage. OpenAI calls its implementation Site tools. This is a technical integration, not a certification or a search-ranking feature.

Start with one action your application already supports. A dashboard might expose its selected date range. A document editor might let an agent find a paragraph and propose a comment. The goal is to reuse application behavior, not create a privileged second application hidden behind the interface.

This is a documentation-based engineering guide, not a claim that we independently tested every browser or deployment combination. Capability and rollout details were checked on September 16, 2026 against official Site tools documentation.

WebMCP versus server-side MCP

Server-side MCP connects an AI application to a local or remote service. That service can expose tools without keeping a website open. WebMCP exposes actions from the page the person and agent are viewing, using that live application context.

Choose page tools when shared visual state matters: selected chart ranges, editor selections, an itinerary or the current document. Choose a server integration when work must continue independently of an open page. Supporting both can be sensible, but authorization and audit records must remain consistent across the two entry points.

Do not turn every REST endpoint into a browser tool. A tool should represent a bounded user task. get_selected_chart_data is easier to reason about than request_any_url. propose_document_comment is safer than exposing an arbitrary JavaScript execution primitive. Our AI Application Architecture foundation explains the surrounding contracts, state and failure boundaries.

Current support is narrower than the proposal

OpenAI documents discovery in the ChatGPT desktop app’s built-in browser, including ChatGPT Work and Codex. Its current implementation uses top-level JavaScript registration: declarative HTML form tools and iframe registrations are not supported. Availability varies by rollout, workspace and model; the current docs list Sol/Terra support, Luna disabled, and no Enterprise/Edu availability. Verify that matrix before committing to a customer deployment.

An unsupported browser must still offer the ordinary interface. Closing or navigating away from a page can remove its tools. A durable backend job should therefore have its own identity and status endpoint, rather than depending on a browser tool registration staying alive.

Register a small read operation first

The documented registration surface is document.modelContext.registerTool. Feature-detect it before registration. This read-only illustration uses the documented API shape but deliberately exposes no application data:

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "read_current_view",
    description: "Read the current page title. Does not change data.",
    inputSchema: {
      type: "object",
      properties: {},
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: async () => ({ title: document.title }),
  });
}

Keep registration in the top-level page module and catch registration failures in your application’s integration boundary. A failure to expose agent tools should not prevent a person from using the dashboard. The example is not a complete SDK, authentication implementation or browser compatibility test.

When expanding the tool, return a useful verification result: current resource ID, selected range, data version and whether the result is partial. Avoid returning the entire document or account when the user asked for a selected chart. Narrow outputs reduce both accidental disclosure and model confusion.

Schemas describe inputs; they do not grant permission

An input schema is a contract for arguments, not an authorization policy. Give each operation explicit types, required fields and bounded values. Reject unknown keys. Validate again at the backend when a request touches durable data.

For example, a chart tool should accept a known metric identifier and a bounded date interval, not a database query string. A document tool should accept the current document ID and a section ID, not an arbitrary filesystem path. Use the same structured-output validation principles you apply to model responses: parsing succeeds before an action becomes eligible to execute.

Return errors that help recovery without revealing secrets. Distinguish unauthenticated, unauthorized, missing resource, stale version and temporary service failure. Do not turn every error into an empty success result. An agent cannot safely verify an operation when failure is hidden.

Logged-in sessions are not blanket authorization

Shared session context is convenient, but being signed in does not authorize every mutation. Reuse existing user identity, tenant checks, role rules and CSRF protections. Never move provider API keys or administrative credentials into a browser tool payload.

The backend must check that the current user may act on the specified resource. An agent-controlled argument must not switch tenants, select another user’s document or supply a more privileged role. Keep these decisions outside model reasoning. See API authentication for AI applications and environment secrets for those boundaries.

Treat tool descriptions and returned content as untrusted. A customer document can contain instructions that conflict with the person’s request. Tool output must not silently become authority to send messages, buy something or retrieve unrelated records. Our AI Security foundation covers the broader permission model.

Split proposals from consequential actions

A useful write flow has two stages: propose a change, then commit it after the normal confirmation policy. A comment suggestion can remain a draft. An itinerary can show a proposed change before a booking. A deletion can return the precise affected resource before confirmation.

Do not describe a destructive operation as read-only. Hints help discovery but cannot enforce behavior. Enforce side-effect policy in application code and at the server. For high-impact changes, bind approval to the exact resource and operation, not to a vague earlier conversation.

Use a resource version or equivalent concurrency check so a stale proposal cannot overwrite newer human edits. Give repeatable mutations an idempotency key and keep a durable action record. A network timeout does not prove the server did nothing. The idempotency foundation explains why retries must preserve one intended effect.

Design for interrupted and asynchronous work

A page can disappear while work continues. Return a job identifier for asynchronous operations and expose status through existing application logic. Clearly separate accepted, running, completed and failed states. A successful request to start a job is not proof the job finished.

Cancellation also needs semantics. Closing the tab should not accidentally cancel a paid backend task unless that behavior is explicitly designed. Conversely, an agent should not continue an irreversible workflow because a progress message was mistaken for approval. Webhook architecture is useful when completion is delivered independently of the page.

Test the tools and the ordinary interface

Build tests around the action contract, not only whether the model can discover a name. The AI Testing & Evaluation hub connects browser reliability with permission and output checks.

Test at least:

• supported registration and unsupported-browser fallback;
• logged-out and insufficient-role requests;
• wrong tenant and missing resource IDs;
• malformed, oversized and unknown arguments;
• duplicate mutation requests and ambiguous timeouts;
• changed resource versions between proposal and commit;
• navigation during a background job;
• malicious instructions inside returned content;
• refusal or cancellation before consequential actions.

Use Playwright browser workflows to confirm the human interface remains usable, with keyboard navigation, labels and confirmations intact. Separately evaluate whether an agent selects the correct tool and interprets partial/error results properly. Passing a UI test does not prove the agent respects the task boundary.

My take

WebMCP is worth implementing when it makes a real application operation clearer and more verifiable than simulated clicking. Start read-only, expose a narrow contract and preserve existing permissions. Add writes only after you can show what changed, recover from retries and keep human approval meaningful.

Do not rebuild your website around hypothetical agent traffic. There is no ranking promise here. A useful integration improves a task people already perform and degrades gracefully when no compatible agent is present.

FAQ

Is an agent-ready website certified?

No. The term describes application capabilities. It is not a certification, trust badge or SEO guarantee.

Does WebMCP replace MCP servers?

No. Page-bound actions and server integrations have different lifecycles. An application can support both.

Can I expose existing forms automatically?

Do not assume so. ChatGPT’s documented implementation currently requires top-level JavaScript registration rather than declarative HTML form tools.

Does a signed-in session remove the need for approvals?

No. Backend authorization and confirmation for consequential actions still apply.

Should unsupported browsers lose functionality?

No. Preserve the normal UI and treat agent tools as an additional interface, not the only route to core actions.