WebMCP

TL;DR — WebMCP lets a website describe its buttons and functions as structured tools an AI agent can call while the page is open. That can make a real page action—searching inventory, validating code, filtering products—more reliable than asking an agent to guess which control to click. It does not make the page easier to rank, crawl, or discover. As of July 17, 2026, it is experimental: a Community Group draft with a Chrome 149 origin trial, not a finished web standard.

What WebMCP is

WebMCP is a proposed browser API that lets a web page expose structured tools to an AI agent operating in that page’s browsing context. A tool has a name, a description, structured inputs, and code that performs an action. Evidence for this claim WebMCP is a proposed browser API through which web applications expose JavaScript-based tools to agents in a browsing context. Scope: WebMCP Draft Community Group Report dated July 10, 2026; the report is not a W3C Standard. Confidence: high · Verified: 2026-07-17 WebMCP Draft Community Group Report

Imagine a visitor opens a schema validator and asks their browser agent to “validate this Product JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal..” Without WebMCP, the agent may inspect the screen, find a text area, paste into it, click the right button, and interpret the result. With WebMCP, the page could offer a validate_schema tool with an explicit input schema and return a structured result—while keeping the visible interface in sync.

That is the useful mental model: WebMCP is an explicit control surface for an agent that has already reached the page. It is not a new way to publish prose.

Current status on July 17, 2026

WebMCP is moving quickly, so code and compatibility claims need dates. The current position is: Evidence for this claim As of July 17, 2026, WebMCP is a Community Group draft rather than a W3C Standard, and Chrome documents an origin trial beginning in Chrome 149. Scope: Standards and Chrome experiment status checked July 17, 2026; these are time-sensitive claims. Confidence: high · Verified: 2026-07-17 WebMCP: Status of This Document Chrome: Join the WebMCP origin trial

I foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. no primary-source basis in this research pass to claim stable WebMCP support in Edge, Safari, or Firefox. A Microsoft editor contributing to the draft is not the same thing as a browser shipping the feature.

WebMCP versus MCP

Model Context ProtocolMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt. and WebMCP expose tools at different boundaries:

• MCPMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt. usually connects an AI application to a persistent server. The server can provide tools and data whether or not a particular web page is open.
• WebMCP lets the open page expose its current frontend actions and state. Its tools can change when the visitor navigates or when an action becomes unavailable.

They complement each other. A store might use remote MCP for a product catalog and WebMCP for the filter, configuration, and checkout steps visible in the visitor’s current tab. Evidence for this claim WebMCP is designed for tools owned by an active page and its browser context, while remote MCP commonly connects an AI application to a persistent backend server. Scope: Architecture-selection guidance, not a rule that prevents an application from using both technologies. Confidence: high · Verified: 2026-07-17 Chrome: When to use WebMCP and MCP

Does WebMCP help SEO or AI citations?

There is no documented evidence that adding WebMCP improves rankings, crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., AI citationsAn AI citation is the visible source link an AI answer engine shows next to its generated text — the clickable reference that credits the web page it used. A citation's presence is a separate thing from whether the cited page actually supports the statement, and from being retrieved (read behind the scenes) or merely mentioned (named without a link); citation is driven more by brand mentions and being retrievable than by traditional ranking., or discovery. The documented feature begins after an agent reaches a page and inspects the tools available there. Evidence for this claim The documented Chrome WebMCP experiment requires a browsing context and a client visit to discover page tools; no documented ranking, crawling, indexing, or citation benefit was found in this research pass. Scope: The browser-context and visit requirements are direct documentation; the SEO conclusion is a bounded absence-of-evidence statement as of July 17, 2026, not a prediction about future search systems. Confidence: high · Verified: 2026-07-17 Chrome: WebMCP overview and limitations Google Search guidance for AI experiences

It could improve the completion of an on-site task. That may be commercially valuable, but it is a product and conversion hypothesis—not a ranking factor. Keep doing the ordinary work that makes a page discoverable and understandable: semantic HTMLSemantic HTML is the practice of using elements like <main>, <article>, <section>, <nav>, <header>, and <aside> to describe what content is, not just how it looks. It helps search engines and assistive tech identify a page's main content more reliably, but it isn't a ranking factor on its own., accessible forms, internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., indexable content, and appropriate structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding..

Editorial pages do not need fake tools just to look “agent-ready.” If the page only needs to be read, readable HTML is the right interface.

Can Cloudflare enable WebMCP for my site?

Not by itself. Cloudflare Browser Run currently offers experimental lab browser sessions that can visit and test pages with WebMCP tools. Your page still has to define and register those tools. Cloudflare’s documentation also says its lab sessions are not for production workloads. Evidence for this claim Cloudflare Browser Run offers experimental lab sessions that can consume and test page-provided WebMCP tools, but the page still owns tool registration and Cloudflare says lab sessions are not for production workloads. Scope: Cloudflare product documentation last updated April 23, 2026; its example API names lag current Chrome documentation and should not be used as the API authority. Confidence: high · Verified: 2026-07-17 Cloudflare Browser Run: WebMCP

That makes Cloudflare a possible test environment or consuming browser, not a switch that converts every existing form and button into WebMCP.

Should you implement it now?

For most production sites, wait. A small private experiment can make sense when all of these are true:

• the page already has a bounded, useful action;
• the normal human interface remains complete without WebMCP;
• the action is read-only or easily reversible;
• the same application logic serves both the UI and the tool;
• inputs, outputs, authorization, and logs receive a real security review; and
• success can be measured without pretending the experiment affects search visibility.

Do not use an experimental browser API as the only path to a critical task.

TL;DR — WebMCP exposes page-owned tools from document.modelContext to an agent in the active browsing context. The imperative API registers a name, description, JSON Schema input, annotations, and an async callback; tools can be state-dependent and unregistered with an AbortSignal. Chrome documents a declarative form layer too, but the July 10, 2026 Community Group draft still labels its declarative section TODO. The feature is in a Chrome 149 origin trial, not a stable cross-browser baseline. Treat it as progressive enhancement, not SEO infrastructure, and secure it as an authenticated application surface.

How WebMCP works in the browser

A useful WebMCP lifecycle begins and ends with the page. The page registers only the actions that are valid in its current state; an agent already operating in that browsing context discovers and invokes one; the page executes its normal application logic, updates the human-visible interface, and returns a bounded result. When the state changes, the page removes tools that no longer apply. Evidence for this claim The imperative API registers named, described, schema-constrained callbacks and supports state-aware cleanup with AbortSignal plus tool-set change notifications. Scope: Current draft and Chrome experiment; API details may change before stable release. Confidence: high · Verified: 2026-07-17 WebMCP ModelContext API Chrome: WebMCP Imperative API

This stateful lifecycle is one reason WebMCP should not become a static dump of every function in a JavaScript bundle. A tool that is impossible in the visible UI should normally be unavailable to the agent too.

WebMCP vs MCP: two different runtime boundaries

The names invite confusion, but the operational boundary is different. WebMCP lives in a document’s event loop and current browser session. Remote MCPMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt. lives at the AI application’s integration boundary and commonly reaches a persistent backend server. Evidence for this claim WebMCP is designed for tools owned by an active page and its browser context, while remote MCP commonly connects an AI application to a persistent backend server. Scope: Architecture-selection guidance, not a rule that prevents an application from using both technologies. Confidence: high · Verified: 2026-07-17 Chrome: When to use WebMCP and MCP

Do not choose from the acronym. Choose from the owner of the action. If the action needs the current DOM, selection, cart, or UI state, WebMCP may fit. If it must run in the background, across many sites, or without an open tab, use an API or remote MCP.

The imperative API

The imperative API registers a tool through document.modelContext.registerTool(). The tool includes a unique name, description, JSON Schema input, an execute callback, and optional annotations. Chrome also documents getTools(), executeTool() for testing, and a toolchange event. Evidence for this claim Current Chrome documentation uses document.modelContext and says navigator.modelContext is deprecated beginning in Chrome 150. Scope: Chrome implementation guidance checked July 17, 2026; version and API-name claims expire quickly. Confidence: high · Verified: 2026-07-17 Chrome: WebMCP Imperative API

This illustrative candidate shows the intended shape for a future Schema Validator pilot. It is not running on this site, and the API may change before a stable release:

if (document.modelContext) {
  const registration = new AbortController();

  await document.modelContext.registerTool({
    name: 'validate_schema',
    description: 'Validate pasted JSON-LD and return bounded issues.',
    inputSchema: {
      type: 'object',
      properties: {
        markup: {
          type: 'string',
          description: 'JSON-LD markup to validate.',
          maxLength: 50000
        }
      },
      required: ['markup'],
      additionalProperties: false
    },
    annotations: {
      readOnlyHint: true,
      untrustedContentHint: true
    },
    execute: async ({ markup }) => {
      const result = await validateWithTheSameEngineAsTheUI(markup);
      renderResultInTheVisibleUI(result);
      return minimizeValidationResult(result);
    }
  }, { signal: registration.signal });

  // When this page state no longer supports validation:
  // registration.abort();
}

The important architecture is not the wrapper. It is that the callback calls the same validator as the visible UI, server-side limits and authorization still apply, and the response is deliberately minimized. Feature detection preserves the full human workflow in unsupported browsers.

Use document.modelContext, not stale examples built around navigator.modelContext; Chrome marks the latter deprecated beginning in Chrome 150. Date that advice because the feature remains experimental.

The declarative API has a standards mismatch

Chrome documents a declarative approach that annotates ordinary forms with attributes such as toolname, tooldescription, and toolparamdescription. It also documents optional toolautosubmit; otherwise, the user clicks Submit. SubmitEvent.agentInvoked identifies an agent-triggered submission. Evidence for this claim Chrome documents declarative WebMCP form annotations, but the July 10, 2026 Community Group draft says its Declarative WebMCP section is entirely TODO. Scope: A direct comparison between Chrome implementation documentation and the current draft; it does not imply Chrome's experimental implementation is unavailable. Confidence: high · Verified: 2026-07-17 Chrome: WebMCP Declarative API WebMCP: Declarative WebMCP

However, the July 10 Community Group Report says its Declarative WebMCP section is “entirely a TODO” and leaves the form-to-JSON-Schema algorithm undefined. That does not mean Chrome’s experiment is imaginary. It means the implementation documentation is ahead of the normative draft. Treat declarative markup as an experimental Chrome surface, not settled cross-browser HTML.

For now, ordinary semantic forms remain the durable base. An experimental annotation layer should enhance them, never replace labels, validation, accessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all., confirmation, or server-side authorization.

Tool discovery, lifecycle, and cross-origin boundaries

The current API has several boundaries worth designing explicitly:

• Browsing context: Chrome’s experiment requires a browser context. The client visits the site before it discovers the site’s tools.
• Dynamic availability: register tools when they are valid and abort their registration when state or navigation invalidates them. Observers can listen for toolchange.
• Same origin by default: the tools Permissions Policy defaults to 'self'. Cross-origin iframesHTML element that displays one webpage inside another — how embeds work. need explicit delegation such as allow="tools".
• Two-sided cross-origin consent: a tool can use exposedTo to list allowed secure origins, while a caller requests tools from named origins with fromOrigins. One side opting in is not enough.
• Progressive enhancement: unsupported or disabled WebMCP must leave the ordinary page fully usable.

These are useful platform controls, but they do not turn a risky application action into a safe one.

Security: the browser session raises the stakes

A browser agent may operate inside the user’s authenticated session. That can be the feature—access to the current cart, account, or workspace—and the danger. Chrome and the draft discuss prompt injection, misleading tool metadata, contaminated tool output, over-broad parameters, privacy leakage, cross-origin exposure, and misuse of signed-in authority. Evidence for this claim WebMCP tool hints can communicate read-only and untrusted-output intent, but they do not eliminate prompt injection, misleading metadata, privacy leakage, cross-origin risk, or misuse of authenticated browser authority. Scope: Threat-model and defensive guidance; application authorization and confirmation remain implementation responsibilities. Confidence: high · Verified: 2026-07-17 WebMCP security and privacy considerations Chrome: WebMCP tool security Chrome: Agent security considerations

Treat every tool as a public application endpoint with an unusual caller:

1. Keep the tool narrow. One job, explicit inputs, tight enums and lengths, no hidden “do anything” parameter.
2. Enforce authorization in application logic. The agent does not gain more authority than the signed-in user, and a hint is not permission.
3. Separate reads from writes. readOnlyHint and untrustedContentHint communicate risk; they do not enforce it.
4. Require visible confirmation for consequences. Purchases, submissions, deletions, messages, and account changes need a human-understandable checkpoint.
5. Minimize output. Return only what the task needs; never spill session data, raw headers, secrets, or unrelated records.
6. Treat output as untrusted. A string returned by one tool can become input to later model reasoning. Do not allow it to smuggle instructions or authority.
7. Log the boundary. Record the tool, input class, authorization decision, confirmation, result class, error, origin, and lifecycle without logging secrets.

The safe question is not “Can an agent call this?” It is “Would I expose this as a reviewed endpoint to a caller that can misunderstand instructions and relay untrusted text?”

Test contracts and agent behavior separately

Chrome’s eval guidance separates deterministic product tests from probabilistic agent tests. Evidence for this claim WebMCP testing should combine deterministic contract and UI-state tests with probabilistic evaluation of agent tool selection and use. Scope: Chrome's evaluation guidance; teams must define product-specific tasks, models, risks, and thresholds. Confidence: high · Verified: 2026-07-17 Chrome: Evals for WebMCP Both matter:

Deterministic tests should verify registration, schema rejection, valid and invalid inputs, authorization, rate limits, side effects, error shape, output minimization, UI parity, unregister behavior, and unsupported-browser fallback.

Probabilistic evals should measure whether representative agents discover the right tool, avoid irrelevant tools, choose the correct parameters, ask for clarification when required, respect confirmations, stop after success, and resist adversarial descriptions or output.

Do not use one demo prompt as the release gate. A successful callback proves the code ran; it does not prove that models select it reliably or that the action is safe.

Cloudflare Browser Run: useful lab, not enablement

Cloudflare documents WebMCP support in Browser Run’s experimental lab pool and says lab sessions should not be used for production workloads. Its April 23 page also contains older Chrome-era testing names, so use that page as evidence of Cloudflare’s current product offering—not as the authority for the latest WebMCP API shape. Evidence for this claim Cloudflare Browser Run offers experimental lab sessions that can consume and test page-provided WebMCP tools, but the page still owns tool registration and Cloudflare says lab sessions are not for production workloads. Scope: Cloudflare product documentation last updated April 23, 2026; its example API names lag current Chrome documentation and should not be used as the API authority. Confidence: high · Verified: 2026-07-17 Cloudflare Browser Run: WebMCP

Cloudflare can provide a browser session and an agent path that consumes tools. It cannot infer the safe contract for your application or register page-owned tools you did not build.

Proposed patrickstox.com pilot: Schema Validator

The Schema Markup Validator is a good future pilot candidate, not a live WebMCP implementation. It already has a bounded pasted input, deterministic logic, structured issues, and a visible result. A future validate_schema tool could reuse the same validation engine as the UI and the existing remote MCP tool suite.

The pilot should wait until the browser API reaches a stable, non-experimental release and passes a fresh security review. The first version should be read-only, feature-detected, input-limited, response-minimized, and unavailable on preview, admin, or owner-only surfaces. This site does not currently claim WebMCP support.

Decision: build, experiment, wait, or skip

AI summary

• Definition: WebMCP is a proposed browser API for exposing structured, page-owned tools to an agent in an active browsing context.
• Status on July 17, 2026: Community Group draft, not W3C Standard; Chrome 149 origin trial/local flag, not stable cross-browser support.
• Current Chrome API: document.modelContext; Chrome deprecates navigator.modelContext beginning in Chrome 150.
• Not remote MCPMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt.: WebMCP is tab- and page-state-bound; remote MCP commonly connects an AI application to a persistent backend server.
• Not discovery or ranking: no documented benefit for crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., rankings, AI citationsAn AI citation is the visible source link an AI answer engine shows next to its generated text — the clickable reference that credits the web page it used. A citation's presence is a separate thing from whether the cited page actually supports the statement, and from being retrieved (read behind the scenes) or merely mentioned (named without a link); citation is driven more by brand mentions and being retrievable than by traditional ranking., or reaching the page in the first place.
• Declarative caveat: Chrome documents form annotations, while the July 10 Community Group draft still marks that normative section TODO.
• Security: authenticated browser state, prompt injection, poisoned metadata or output, broad inputs, and cross-origin exposure make least privilege, confirmation, server authorization, and logs essential.
• Cloudflare: Browser Run can consume/test WebMCP in experimental lab sessions; it does not create tools on the site.
• Recommendation: keep the human UI complete and wait for stable support; private experiments should be bounded, reversible, and measurable.
• This site’s candidate: a future read-only Schema Validator pilot. It is proposed, not implemented.

What the primary sources establish

Status and compatibility were checked July 17, 2026. Recheck these sources before copying code or making a production decision.

WebMCP implementation checklist

Product fit

• The page has one bounded action that is materially more reliable as a tool.
• The tool solves a user task; it is not being added for speculative rankings.
• A normal semantic, accessible interface remains the source of truth.
• The action belongs to the current page/session rather than a background API.

Contract and lifecycle

• The name and description are short, unique, specific, and not generated from untrusted content.
• The JSON Schema rejects unknown fields and limits strings, arrays, ranges, and enums.
• The callback reuses the same engine and authorization path as the visible UI.
• The UI visibly reflects the resulting state.
• The tool is unregistered when navigation or state makes it invalid.
• Unsupported browsers retain the complete workflow.

Security and privacy

• Read/write behavior is explicit; annotations are treated as hints only.
• Server authorization is enforced independently of the agent.
• Sensitive actions require visible, informed confirmation.
• Cross-origin exposure is denied unless a named use case requires it.
• Tool output is minimized and treated as untrusted downstream input.
• Secrets, cookies, local history, raw private records, and unrelated state are excluded.
• Logs support incident review without storing sensitive payloads.

Release and evaluation

• Registration, validation, errors, side effects, output, UI parity, and cleanup have deterministic tests.
• Representative agents have probabilistic selection and parameterization evals.
• Adversarial prompts, metadata, output, and confused-deputy cases are tested.
• The current spec, Chrome milestone, flags/trial, and vendor docs were rechecked.
• The feature is not a production dependency while support remains experimental.

WebMCP decision cheat sheet

Current syntax and status

Current object:       document.modelContext
Deprecated in C150:  navigator.modelContext
Chrome status:        149 origin trial / testing flag
Standards status:     Community Group draft, not W3C Standard
Discovery moment:     after the client visits the page
Cloudflare role:      experimental consuming/test browser

The ACTION gate

Use ACTION before exposing a page function:

• A — Action is bounded. One purpose, explicit input, predictable output.
• C — Context belongs to the page. The current tab or visible state is genuinely required; otherwise prefer an API or remote MCPMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt..
• T — Trust boundary is reviewed. Authentication, origins, untrusted content, confirmation, and output minimization have owners.
• I — Interface stays complete. The ordinary UI is accessible and fully functional without experimental browser support.
• O — One implementation. UI, API/MCP, and WebMCP call the same canonical engine rather than drifting into separate business logic.
• N — Numbers can be measured. Define task completion, error, clarification, abandonment, unsafe-attempt, and fallback rates before launch.

If any letter fails, the tool is not ready for production.

WebMCP anti-patterns

1. Adding a tool to every article. Readable content does not become more discoverable because a page registers a meaningless read_article action.
2. Treating annotations as enforcement. readOnlyHint communicates intent; it does not prevent hidden writes or guarantee safe model behavior.
3. Copying navigator.modelContext examples without a date. Chrome documents the move to document.modelContext and deprecation beginning in Chrome 150.
4. Giving the agent a generic command runner. Broad inputs erase the benefit of a structured contract and expand prompt-injection impact.
5. Leaving stale tools registered. If the page disables an action, its tool should not remain callable.
6. Returning the whole application object. Minimize output; private or untrusted fields can leak data or poison later reasoning.
7. Letting Cloudflare status substitute for page work. A beta browser that consumes WebMCP does not author, register, secure, or test your tools.
8. Replacing the form with the experiment. Progressive enhancement means the human interface survives missing browser support and API changes.
9. Calling a private demo production-ready. Contract success is not agent reliability, interoperability, or a completed threat model.

Related tools on this site

• Schema Markup Validator: the proposed first WebMCP pilot because its inputs and findings are bounded and deterministic. WebMCP is not enabled on it today.
• MCP Tool Suite: the site’s live remote MCPMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt. surface and the clearest way to compare a persistent server integration with a future page tool.
• Agent Readiness Checker: checks several server-visible agent signals. It intentionally should not score WebMCP because a server-side fetch cannot reliably observe tools registered in a live document.
• Schema Markup Generator: another example of a deterministic human workflow that must remain complete regardless of agent support.

Primary sources

• WebMCP Draft Community Group Report — current draft, API definitions, permissions, security, and explicit standards status.
• Chrome: WebMCP overview — origin-trial entry point, limitations, and testing setup.
• Chrome: Imperative API — current object name, registration, lifecycle, testing, events, and cross-origin controls.
• Chrome: Declarative API — experimental form annotations and submission behavior.
• Chrome: WebMCP tool security — annotations, origin exposure, and tool-provider safeguards.
• Chrome: Agent security considerations — malicious metadata, contaminated outputs, authenticated sessions, and defense in depth.
• Chrome: WebMCP best practices — tool scope, descriptions, state, and reliability.
• Chrome: WebMCP evals — deterministic testing and probabilistic agent evaluation.
• Chrome: When to use WebMCP and MCP — frontend/page context versus persistent backend boundaries.
• Chrome: Join the WebMCP origin trial — Chrome 149 experiment announcement.
• Chrome DevTools: Debug WebMCP tools — registered and invoked tool inspection.
• Lighthouse: Registered WebMCP tools — informational registered-tool audit.
• Cloudflare Browser Run: WebMCP — beta lab sessions and production limitations; API examples on that page lag current Chrome documentation.

Related guides

• Model Context ProtocolMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt.
• Agentic SearchAgentic search is an AI system that autonomously plans, runs, and synthesizes a multi-step research or browsing task — dozens to hundreds of searches and real page reads — instead of returning one answer to a single query. All agentic search is AI search; not all AI search is agentic.
• llms.txtllms.txt is a proposed (not adopted) Markdown file at /llms.txt that gives AI systems a curated map of a site's most important pages. Proposed by Jeremy Howard in 2024, it's read mostly by coding agents like Claude Code — not search crawlers — and Google ignores it.
• Schema Markup for AISchema markup (structured data) is machine-readable code — usually JSON-LD — that labels what your content means using the schema.org vocabulary. For AI search it's infrastructure for entity disambiguation, not a direct citation lever: controlled studies found no meaningful uplift in AI citations from adding it.
• For AI agents — the site’s currently available agent-facing files and remote MCPMCP is an open protocol, created and open-sourced by Anthropic in November 2024, that standardizes how AI applications connect to external tools and data at runtime. It runs on a host–client–server architecture and lets agents call functions, read data, and take actions — the opposite of a static file like llms.txt. surface; it does not claim WebMCP support.

Compatibility and status claims were verified July 17, 2026. Recheck before implementation because milestones, flags, API names, and draft text can change.

Changelog