WebMCP: how to make your website agent-ready, and how it differs from MCP

What is WebMCP?

Today, a browser agent filling in an inquiry form on your site has to work it out like a new visitor. Google notes that browser agents read pages by analyzing screenshots, inspecting the DOM and interpreting the accessibility tree. That works, but it is fragile: a moved button or an unlabeled field can derail the task.

WebMCP lets the page say directly: here are the actions I support, what each does, and exactly what input it accepts. Chrome describes it as a proposed standard that aims to expose structured tools to AI agents on existing websites. Chrome's WebMCP documentation describes two approaches: an imperative JavaScript API, where your script registers tools, and a declarative approach, where you annotate existing HTML forms.

Status matters. WebMCP is a proposal, available in Chrome behind an origin trial or a flag as of 2026. Most visitors' browsers will not expose it and most agents will not use it yet, so build it as progressive enhancement: the site must work exactly the same without it.

WebMCP vs MCP: what is the difference?

MCP, the Model Context Protocol, is an open protocol for connecting AI applications to external tools and data. An MCP server lists tools and runs them when a client asks, using JSON-RPC 2.0 messages. WebMCP borrows the idea of a tool, but the tool lives inside a web page and is called by an agent operating in the browser while that page is open.

The definitions look alike: on trugoods.net, both our server-side MCP tools and our in-page WebMCP tool have a name, a plain-language description and a JSON Schema for inputs. The difference is where the code runs and who is present when it runs.

Should a small firm care about WebMCP yet?

It is worth understanding now and worth implementing only for a clear, small use case. Chrome's toolkit post separates agents searching the web from agents using it, and says that when agents are searching, SEO principles still apply. WebMCP is about the second stage; there is no indication it affects rankings in Google or AI answers.

Chrome has added an Agentic browsing category to Lighthouse, starting in Chrome 150. It checks accessible names on interactive elements, visual stability (Cumulative Layout Shift), registered WebMCP tools, forms missing declarative WebMCP, and schema validity. Chrome describes it as informational and unbenchmarked: pass, fail and warnings, not a score to chase.

Adoption of related discovery files is tiny: Cloudflare's Is it agent ready scanner reported MCP Server Cards and API catalogs on fewer than 15 of roughly 200,000 top domains. Being early costs little if the implementation is small and safe.

Before WebMCP: make the page readable by agents

• Give every button, link and form field an accessible name, such as a visible label tied to the input. Agents rely on the accessibility tree as their primary model of the page.
• Keep the layout stable. Content that shifts after load causes misclicks for agents and people alike.
• Serve meaningful HTML that does not depend on heavy client-side rendering to show your services and contact options.
• Write clear validation messages so an agent or a person can tell what went wrong.
• Publish consistent business facts: service pages, structured data and, optionally, an llms.txt file.

How we implemented WebMCP on trugoods.net, step by step

Our site has one multi-step flow worth delegating: preparing a consultation request. We registered a single imperative WebMCP tool for it, named prepare_trugoods_consultation.

1. Choose one low-risk jobThe worst outcome of a bad draft is a visitor editing a few fields. We exposed nothing irreversible, such as sending the request, and nothing involving payments.
2. Feature-detect, then enhanceThe script checks whether the browser exposes a model context object (our code looks for navigator.modelContext, with document.modelContext as a fallback) and otherwise does nothing. Regular visitors see no difference.
3. Describe the tool honestlyThe description tells the agent exactly what happens: it opens the visible guide and prefills a draft for the visitor to review, it does not submit or store anything, and the agent should never include sensitive information.
4. Constrain the inputThe input schema lists only our intake form's fields, each a string with a maximum length (300 characters, or 2,000 for goals), and rejects extra properties. The tool's annotations mark it as not read-only, because it changes what is on the page.
5. Validate again when it runsThe execute function re-checks every field before touching the page and refuses to run while a submission is in progress.
6. Do the work visiblyThe tool fills in the same on-page intake guide a person would use and opens it, returning only a small status: draft prepared, visitor review required, not submitted.
7. Leave submission to the humanTo send the request, the visitor reviews a summary, ticks a consent checkbox and presses submit. Our lead endpoint then validates again on the server, applies rate limits and can require a Cloudflare Turnstile check.
8. Clean up with the pageThe tool is registered with an abort signal that fires when the visitor leaves the page, so it does not outlive its context.

Security and consent rules for WebMCP tools

A WebMCP tool runs your own page code, so it can do anything that code can do. Safety comes from your design, not the protocol.

• No silent submissions. Anything that sends data, books or buys should end with a visible review step and an explicit human action.
• Treat agent input as untrusted: allow-list fields, cap lengths, reject unknown properties and validate again on the server. An agent may be relaying text from another website.
• Rate limit on the server, whatever the request's origin. Client-side checks are a courtesy, not a control.
• Never expose private data. Return status, not stored customer records or lead data.
• Say what the tool will not do, so the agent can explain the action accurately to the person.
• Keep descriptions factual. Text designed to steer an agent toward your business is manipulation and erodes trust.

How to test WebMCP in Chrome

Chrome's toolkit post describes testing with Chrome DevTools for Agents, which turns your coding agent into a browsing agent you control. These features are experimental and Chrome notes they can be unstable.

1. Enable WebMCPUse a browser such as Chrome Canary with the chrome://flags/#enable-webmcp-testing flag turned on, and enable Remote Debugging in chrome://inspect.
2. Connect DevTools for AgentsConfigure the chrome-devtools-mcp package in your coding agent with its experimental WebMCP option, following Chrome's post and the project's GitHub repository.
3. Start with a known-good demoTry Chrome's WebMCP pizza maker demo to confirm the setup works.
4. Exercise your own toolAsk the agent to open your page, list the tools, call yours and summarize what it did. Then try bad input, extra fields and over-long values, and confirm they are rejected and nothing reaches your server until a person submits.
5. Run the Agentic browsing auditDevTools for Agents can run Lighthouse on the active tab through its lighthouse_audit tool. Treat the results as a checklist.

Where MCP servers, Server Cards and API catalogs fit

Agents that never open your page need a server-side route. On trugoods.net that is a small, read-only MCP endpoint at /api/agent/mcp. It accepts JSON-RPC 2.0 POST requests for initialize, ping, tools/list and tools/call, and offers four tools: search_services, get_readiness_matrix, get_case_study and prepare_consultation_brief, which returns an editable draft, points to our contact page and saves nothing. We also publish plain JSON at /api/services and /api/agent/catalog, linked from our llms.txt.

Two emerging formats help agents find endpoints like these. An MCP Server Card is a draft proposal for a JSON file at /.well-known/mcp/server-card.json describing a server's name, version, transport endpoint and capabilities. An API catalog, defined in RFC 9727, is a file at /.well-known/api-catalog listing your APIs with links to their descriptions and documentation. Both are cheap once you have an endpoint, but almost nobody uses them yet.

For most professional-service firms, a read-only JSON catalog or MCP endpoint is a more useful first step than WebMCP: it is simpler, exposes only public information, and serves agents that never render your page.

trugoods.net publishes both, so you can inspect working examples: our MCP Server Card, our API catalog and the OpenAPI description of the same read-only endpoints.

A sensible order to make your website agent-ready

1. Get foundFix crawling, indexing and service-page content. Our SEO and GEO overview covers this foundation.
2. Get readAccessible names, stable layout and clear forms, checked with Lighthouse's Agentic browsing category.
3. Get understoodConsistent business facts, schema.org structured data and, optionally, llms.txt.
4. Offer read-only dataA JSON service catalog or read-only MCP endpoint, if you have information worth querying.
5. Add one WebMCP toolA single, human-confirmed flow such as preparing an inquiry.
6. Measure and revisitRe-test after browser updates, and use our AI visibility audit guide to check whether you are found and cited at all.

Frequently asked questions

What is WebMCP in Chrome?

A proposed web standard that lets a page register tools an in-browser AI agent can call, through a JavaScript API or annotated HTML forms. As of 2026 Chrome offers it behind an origin trial or flag, and Lighthouse's Agentic browsing category reports on WebMCP signals.

Is MCP obsolete now that WebMCP exists?

No. MCP connects AI applications to tools on a server; WebMCP exposes tools from a page open in the browser. They solve different problems, which is why trugoods.net runs both.

Does WebMCP improve SEO or AI search rankings?

There is no evidence that it does. Chrome says SEO principles still apply when agents are searching; WebMCP helps once an agent is using your site.

Can a WebMCP tool submit a form without the user?

Technically a tool runs your page's code, so it can do whatever that code does. That is why you should design tools to prepare a visible draft and leave the final submission to the person, as we do.

Where can I find WebMCP on GitHub?

Chrome's WebMCP documentation links to the proposal and related resources. Chrome also publishes demo pages at googlechromelabs.github.io/webmcp-tools, and Chrome DevTools for Agents ships as the chrome-devtools-mcp package with its own GitHub repository.

Do I need WebMCP if I already have an MCP server?

Not necessarily. A read-only MCP endpoint or JSON catalog covers public service information. Add WebMCP when you have an on-page flow, such as an inquiry form, that agents would otherwise have to click through.

Related guides

• What is llms.txt, and is it worth adding to your website?
• Is my website visible to AI? A 30-minute AI visibility audit
• How to get ChatGPT to recommend your business (without tricks)