WebMCP Site Tools: What ChatGPT Can Discover and What It Cannot

What WebMCP site tools are

OpenAI describes site tools as its implementation of the proposed WebMCP standard. In supported ChatGPT Work and Codex experiences, the built-in browser can discover tools registered by the page the user is visiting.

The page remains the security boundary. A tool exposes a bounded action that the page can already perform, such as reading a calculator state or preparing an export. It does not make the entire site an agent API.

Current discovery boundaries

Register a read-only tool at the top level

OpenAI’s current example checks for browser support before calling document.modelContext.registerTool. A SERP preview could expose only the fields already visible on the page:

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "read_serp_preview",
    description: "Read the title, description, and preview status shown on this page.",
    inputSchema: {
      type: "object",
      properties: {},
      additionalProperties: false
    },
    execute: async () => ({
      title: titleInput.value,
      description: descriptionInput.value,
      status: computePreviewState()
    })
  });
}

The handler should derive its result from visible page state. Do not include session tokens, unpublished drafts, private analytics or fields that the user cannot inspect.

Return a result the user can verify

A useful result says what happened, which page state it used and whether anything changed. Keep the envelope stable even when the action fails.

{
  "ok": true,
  "action": "read_serp_preview",
  "page_state": "current",
  "changed": false,
  "result": {
    "title": "Example title",
    "description": "Example description",
    "status": "within-guideline"
  }
}

For an error, return a short code such as INVALID_INPUT, AUTH_REQUIRED or STALE_PAGE_STATE and a safe recovery instruction. Do not leak stack traces or internal paths.

The security contract

1. Authorize the action: discovery does not grant a new permission.
2. Validate every input: use a narrow schema and reject unexpected fields.
3. Declare side effects: reading, saving, sending and deleting are different risk levels.
4. Return a verifiable result: the user should see what changed or what was read.
5. Protect sensitive data: do not expose tokens, drafts, customer records or private analytics.
6. Keep the normal UI: the page must still work when WebMCP is absent.

OpenAI says website tool definitions and results are untrusted content. Its browser applies a safety review and existing confirmation rules, but those checks do not make a website or its output trustworthy.

Classify the side effect before writing code

Start at the top of the table. Move to a higher tier only after the lower-risk tool has clean discovery, failure and fallback behavior.

Which website actions belong in a first release?

Diagnose failure at the correct layer

A five-environment QA protocol

Test the tool in the eligible built-in browser, a normal desktop browser, a mobile browser, an iframe embedding and a signed-out session. Record discovery, invocation, result, fallback UI and any authentication challenge. A clean failure is part of the product contract.

Then test malformed inputs, repeated calls and stale page state. The tool should reject invalid input, avoid duplicate side effects and make its result traceable to the page the user can see.

Use a reversible release sequence

1. Ship the ordinary page action and verify keyboard and mobile use.
2. Wrap the same application logic in one read-only site tool.
3. Feature-detect the API and register only on the top-level page.
4. Test unsupported browsers and signed-out states before an eligible client.
5. Add logging for tool name, result class and error code without storing sensitive inputs.
6. Define a rollback that disables registration without disabling the page feature.

Keep WebMCP separate from SEO and AEO claims

A site tool can make an action available while a user is on the page. It does not prove that ChatGPT Search will retrieve the page, cite it or rank it. Indexable explanations still serve search users who never invoke an action.

Use WebMCP to improve task completion, not to decorate an SEO pitch. Our SERP snippet preview remains useful through its ordinary interface whether or not a supported agent discovers a tool.

Download the implementation checklist

Download the WebMCP release checklist. All sample rows are labeled EXAMPLE-REMOVE. Replace them with observed client, model and page results before describing a tool as supported.

Shopify checkout turns WebMCP into a transaction-state interface

Shopify added WebMCP support for checkout on September 28, 2026. Browser agents can work with the buyer’s active checkout through four documented tools: navigate_to_storefront, get_checkout, update_checkout and complete_checkout.

The tools run inside checkout-web and share state with the visible checkout interface. Shopify says they do not expose a new API and do not require merchant configuration. That makes this a platform implementation of the action boundary described earlier in this guide, not a general permission for any site to modify a checkout.

A checkout acceptance test should record the starting cart, session state, supported field change, confirmation event, any 3D Secure or extension handoff, final order state and duplicate-call behavior. Do not test with a live charge unless the merchant has a controlled test environment and a documented reversal path.

This checkout support still does not establish crawling, ranking, citation or remote MCP compatibility. It demonstrates a browser-session action contract on a specific commerce platform.

Official references

Current implementation details come from OpenAI’s site-tools documentation, the ChatGPT release notes and Shopify’s checkout WebMCP changelog, checked October 3, 2026.