What an AI agent discovers
on a web page
This page registers a callable tool with a machine-readable JSON schema. Everything below is the real manifest an agent would read when it lands on this URL, plus a working invocation you can run yourself. No API keys, no backend, no external calls.
What is WebMCP, in one answer
WebMCP is a pattern where a web page publishes its own callable tools, described with machine-readable JSON schemas, so an AI agent visiting the URL can discover and invoke them directly. Rather than the agent needing a separately hosted server for every capability, the page declares what it can do: each tool has a name, a description written for a model to read, and an input schema specifying required arguments and allowed values. An agent matches a tool to the user's goal, validates the arguments against the schema, calls the tool, and receives a structured result. It is complementary to MCP servers, not a replacement: MCP gives an agent tools that work everywhere, while a WebMCP-style page gives it tools that are specific to the context the user is already viewing.
The practical value is that a page can be an action surface, not just a document. When a URL exposes a clear, honest tool manifest, an agent can complete a task on it instead of handing the user a list of steps to follow by hand.
The tool this page exposes
One interactive element: a deterministic lookup that returns the connection facts for a supported AI-assistant platform. Pick a platform and invoke the tool exactly as an agent would.
What an AI agent discovers on this page
lookup_channel_facts{
"name": "lookup_channel_facts",
"description": "Return the connection facts (channel, transport, auth, and a setup note) for a supported AI-assistant platform. Deterministic, offline, no network access.",
"inputSchema": {
"type": "object",
"properties": {
"platform": {
"type": "string",
"description": "The platform to look up connection facts for.",
"enum": [
"slack",
"teams",
"discord",
"whatsapp",
"telegram",
"github"
]
}
},
"required": [
"platform"
]
}
}Invoke the tool
| Dimension | MCP server | WebMCP-style page |
|---|---|---|
| Where tools live | A separately hosted process | The page the user is already on |
| Discovery | Configured once, available everywhere | Read from the URL at visit time |
| Scope | Cross-app, shared capabilities | Specific to this page's context |
| Backend required | Yes | No — can be fully client-side |
| Best for | Shared, recurring tool use | Page-specific actions and lookups |
Frequently asked questions
What is WebMCP?
WebMCP is an emerging pattern in which a web page declares its own callable tools, with machine-readable JSON schemas, so an AI agent that lands on the URL can discover and invoke them. Instead of the agent needing a separately hosted MCP server, the page itself publishes a manifest of what it can do, and the agent calls those tools in place.
How does an agent call a tool on a web page?
The page registers each tool with a name, a natural-language description, and a JSON input schema. An agent reads that manifest, decides a tool matches the user's goal, validates its arguments against the schema, invokes the tool, and receives a structured result. Because the schema is explicit, the agent knows which arguments are required and what values are allowed before it calls anything.
Is this the same as an MCP server?
No, but they are complementary. An MCP server runs out-of-band and gives an agent tools that work everywhere. A WebMCP-style page gives an agent tools that are specific to the context the user is already viewing. The two combine well: a page can expose what it uniquely knows, while an MCP server handles the shared, cross-app capabilities.
Does this demo call any external API or backend?
No. The tool on this page is a deterministic, self-contained lookup that runs entirely in your browser. There are no API keys, no server calls, and no data leaves the page. That is deliberate: it shows that a page can be useful to an agent without exposing a backend.
Why would I want my web page to expose tools to agents?
Because an agent that can act on your page is more useful than one that can only read it. When a page publishes a clear tool manifest, an agent can complete tasks on it directly, which makes the page the natural place to send users who want an outcome rather than a paragraph of instructions.
Want this in your own tools?
Cody is a private AI assistant with a mature MCP toolkit. If you are wiring agents into real systems, the same pattern here is what makes them useful: clear, schema-described tools they can call with confidence.