WebMCP: give agents a clearer way in.
WebMCP lets a website describe functions that a browser agent can discover and call while the page is open. A site might expose a product search, a timetable lookup or a form helper. The browser mediates the interaction with the site’s existing interface.
It is a Community Group draft, with evolving APIs and browser support. It is useful to distinguish a proposed interface, a tool actually observed in a browser, and an action that has been tested successfully.
Try it on Agent Web Map
This browser has not exposed WebMCP here. The website, public API and MCP connection remain available.
In a supported browser, this tab registers four public lookup tools: find documentation for a task, search the directory, read a publisher record and find shared file headings. They perform public reads and do not expose private workspaces or owner controls.
WebMCP vs MCP vs llms.txt
| Interface | What it provides | Where it works |
|---|---|---|
| llms.txt | A publisher’s description, guidance and links to useful pages | A public text file, including root or documentation paths |
| MCP | A protocol for discovering and using server tools and resources | A connected agent client and server |
| WebMCP | Structured tools exposed by a web page | A supported browser and a live page context |
These interfaces can complement one another. A file explains where to start; a server or browser interface can expose actions. Publishing a file does not by itself install a connection, establish WebMCP support or grant permission to act. Chrome explains the different contexts.
How to find websites an agent can use
Start with the task and inspect the evidence. Browse interface-oriented publishers or publisher-declared MCP endpoints. These are discovery signals, not live tool confirmations. Use the MCP endpoint checker when the publisher provides a public endpoint.
For browser tools, open the page in a supported browser and inspect its registered inventory. Tool names, input schemas, permissions, check time and page context all matter. Static HTML may hint at WebMCP but cannot establish what tools exist after scripts, sign-in or page interaction.
What should a useful browser tool describe?
- A specific action and an accurate description
- Inputs with a clear schema and sensible limits
- Whether it reads data or changes something
- The result and any errors the agent must handle
- When sign-in, user consent or confirmation is required
Descriptions and read-only hints are publisher claims. Keep authority to buy, send, delete or change an account separate from discovering that an action exists.
Prepare your own website
Audit its public signals, make useful pages readable, and draft an llms.txt describing the actual site. Add browser tools only where they make a real task clearer. After publishing, check the live file and submit it to the directory.
Inspect this tab’s tool inventory
In a browser exposing the current draft API, this developer-console expression reads tool metadata. It does not run a tool:
await document.modelContext.getTools()Older experimental browser builds may expose a different API. Follow the documentation for your browser version.
More: Can AI find, understand and cite your website? · Check what an MCP endpoint actually returns. · Agentic commerce needs evidence behind the interface. · Find the right documentation before using it. · The llms.txt project · What is llms.txt? · llms.txt examples · llms.txt best practices · checker · generator