Let the assistant use your page

Busymate AI already knows what your business says. Page tools let your assistant do what your page does — look up an order, book a slot, start a return — by calling functions your site already has, in the visitor's own session. You write each action once and it reaches every visitor: through the browser where WebMCP is implemented, and through the assistant's own bridge everywhere else, mobile apps included.

Your assistant is already on the page — the one embed script you added when you set it up. Page tools ride that same script; there is nothing extra to install.

1. Decide what the page can do

Pick three to seven things a visitor does here, and note for each whether it only reads or actually changes something.

Name each with a verb — check_order_status, list_available_slots, start_return — and describe it the way you would to a new colleague. That description is what the assistant reads to decide when to use it.

2. Register them

One call, on the page where those actions live:

// One call, both transports: the browser's own WebMCP where it exists,
// and the assistant's bridge everywhere else (Safari, Firefox, app WebViews).
BusymateAI.registerPageTools([
  {
    name: "check_order_status",
    description: "Look up an order by its number and say where it is.",
    inputSchema: {
      type: "object",
      properties: { orderNumber: { type: "string", description: "The order number, as printed on the receipt" } },
      required: ["orderNumber"],
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }) => (await fetch(`/api/orders/${orderNumber}`)).json(),
  },
]);

execute runs in your page, on the visitor's own session. The assistant never receives your cookies, your tokens or your markup — only the value you chose to return.

Mark every read with annotations: { readOnlyHint: true }. Anything without that mark counts as a change: the assistant shows the visitor the exact call and waits for a yes. There is no way to switch that off, and no reason to mark a change as a read — the confirmation is what makes a visitor comfortable letting an assistant act at all.

With a bundler, import registerPageTools from /sdk/v1/webmcp/index.js on your assistant's address instead of using the global.

3. Forms you already have

If the action is a real <form>, annotate it and register every annotated form on the page with one call to registerDeclarativeForms() — no other JavaScript:

<form action="/book" toolname="book_appointment"
      tooldescription="Book an appointment for a date, a time and a service."
      toolautosubmit>
  <input name="date" type="date" toolparamdescription="The day, e.g. next Tuesday">
  <input name="time" type="time" toolparamdescription="The start time">
  <select name="service" toolparamdescription="Which service to book">
    <option>Consultation</option>
    <option>Follow-up</option>
  </select>
  <button type="submit">Book</button>
</form>

The form keeps working for people exactly as before. Submitting it changes something, so it asks first — unless you add data-tool-readonly to a form that only filters what is already on screen.

4. Tools that come and go

A tool the visitor cannot currently use should not be offered. Pass { signal } from an AbortController and call abort() when the view goes away; the tools disappear with it.

5. Who can see them

By default your tools are exposed to your assistant's own address and nothing else; any other origin is refused by name. To add one, name it exactly in exposedTo — there are no wildcards, because *.example.com would hand every subdomain you do not control the right to run your page's actions.

You also keep one switch: Site page tools, in the Console under Channels and access. Turning it off stops your assistant using page tools everywhere, without touching your site's code.

6. Let a checker see them

The SDK also writes <link rel="webmcp-catalog" href="…"> into your head, and rewrites it whenever your tool list changes, so an inspector can confirm the registration without a console. If your site has a server, serve the same document at a real URL and put that link in your served head: it is the only version a reader can see without running your page, and yours is never replaced.

Verify

1. Open your site with the assistant and press Site tools in its header. Every tool you registered is listed with its description and arguments, and the ones you marked read-only say so.
2. Run a read-only tool from that list. The result matches what your page shows for the same thing.
3. Run one that changes something. It asks first and shows the exact call; declining leaves the page untouched.
4. Ask the assistant in plain words to do one of those things — it picks your tool rather than describing a page.
5. Open the same page in Safari or inside your mobile app. The list is identical: the bridge covers what the browser does not.
6. Navigate away from the view you registered on. The tool leaves the list.
7. View the page source with the assistant loaded: a webmcp-catalog link is present and its document lists the same tools.

Next

• Connect your MCP server as assistant tools — the actions that live on your servers rather than on the page.
• Recognize signed-in customers — so a page tool can answer about this customer's order.
• In-app support for iOS and Android — where the bridge is the only transport.