WebMCP
Botonom pages declare what they can do to an AI agent running in the same browser tab. Which tools are exposed, what they can and cannot do, and how to see them.
This guide begins with What this is, continues through The tools we expose, Seeing them today, What they cannot do, and finishes with In-page tools or the MCP server.
What this is
An AI agent working inside a visitor's browser tab does not have to guess what a Botonom page offers. The page declares its own capabilities to the browser, and the agent calls them like functions: no screenshots, no DOM parsing, no scraping.
This is WebMCP, and the entry point is document.modelContext. Nothing is installed and no key is issued: the agent works inside the session the person already has, with no separate sign-in.
Every tool we expose is read-only. They answer questions about the catalogue, pricing and documentation, and they cannot change anything in a workspace.
This page covers what Botonom exposes. For the standard itself, what is not settled yet, and how to declare your own site's actions, read Ready Your Web App for WebMCP.
The tools we expose
Five tools are available on every page. Two more appear only on their own page and are withdrawn when the visitor leaves it.
| Tool | What it answers | Where |
|---|---|---|
botonom_search_agents | The catalogue of AI employees, with role, category and monthly salary | every page |
botonom_search_skills | Skills and integrations an agent can be equipped with | every page |
botonom_get_pricing | Plans, token pools, agent salaries, trial length, annual discount | every page |
botonom_estimate_plan | Which plan covers a given monthly conversation volume | every page |
botonom_search_docs | This documentation, by title, summary and tag | every page |
botonom_score_ai_readiness | Runs the AIQ assessment and draws the report on screen | /en/tools/aiq |
botonom_prepare_contact_request | Drafts the contact form and focuses Send | /en/contact |
botonom_estimate_plan runs the same calculator the pricing page renders from, so a tool answer and the page can never disagree about the same workload.
botonom_score_ai_readiness is the one that shows what in-page tools are for: it scores the assessment and renders the report, so the agent and the person end up reading the same screen.
Seeing them today
WebMCP is a W3C Community Group draft and Chrome keeps it behind an origin trial. In an ordinary browser document.modelContext is undefined and our pages register nothing, which is the intended behaviour rather than a fault.
Today the tools can be called by Chrome started with the WebMCP flag, and by the ChatGPT desktop app's own browser with site tools enabled.
To look for yourself, start a separate Chrome with the flag:
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --enable-features=WebMCP --user-data-dir=/tmp/webmcp-profile https://botonom.com/en/pricing
Then, in that page's console:
(await document.modelContext.getTools()).map(t => t.name)
To run one, pass the arguments as a JSON string:
await (async () => {
const tools = await document.modelContext.getTools();
const tool = tools.find(t => t.name === "botonom_get_pricing");
return JSON.parse(await document.modelContext.executeTool(tool, "{}"));
})()
What they cannot do
Each limit below is enforced by the code that runs the tool.
- They cannot submit a form or contact anyone. The contact tool fills the fields and focuses the Send button. It has no path to the submit handler and never touches the consent checkboxes, so the visitor still reads the draft and presses Send.
- They cannot spend money. No checkout, no hiring, no plan change, no token spend.
- They cannot read a signed-in session. Every answer comes from data already public on the site.
- They cannot act inside a workspace. Listing agents, running tasks and approving work belong to the MCP server, where each permission is approved explicitly.
In-page tools or the MCP server
Both exist and they answer different needs.
| In-page tools (WebMCP) | MCP server | |
|---|---|---|
| Runs in | The visitor's browser tab | Your assistant, over HTTP |
| Identity | The session the person already has | OAuth, with permissions you approve |
| Reaches | Public site data, plus what the page is showing | Your workspace: agents, runs, instructions |
| Works when | A person is present, in a compatible browser | Always, including scheduled jobs |
| Set-up | None | Connect once |
If the value is tied to the page, the in-page tools are the right thing. For anything that touches a workspace or must run without a browser, use the server: https://mcp.botonom.com/mcp, documented in Connect Botonom to Claude, ChatGPT and other assistants.
If you do not see what you expect
document.modelContext is undefined. The browser does not expose the API. Start Chrome with --enable-features=WebMCP, and note the flag only applies to a Chrome started fresh with its own --user-data-dir.
getTools() returns an empty list. You are on a page that registers nothing, such as an embedded widget, or the document is not a secure context.
The AIQ or contact tool is missing. Those two register only on /en/tools/aiq and /en/contact. Leaving the page withdraws them by design.
executeTool fails with "Failed to parse input arguments". The arguments must be a JSON string, not an object. Use JSON.stringify(args).
A tool call is refused. Each handler validates its own input: the AIQ tool needs all fifteen answers, and the contact tool needs a valid category plus a subject and a message. The error text says which.