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. Write each action once: it reaches every visitor, via WebMCP where the browser supports it and the assistant's own bridge elsewhere, apps included.

Your assistant is already on the page, from the embed script you added when you set it up. Page tools ride that same script — 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 as you would to a new colleague; that description is what the assistant reads to decide when to use it.

2. Register them

One call, 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, tokens or markup, only the value you choose to return.

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

With a bundler, import registerPageTools from /sdk/v1/webmcp/index.js (served 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 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 tools are exposed only to your assistant's own address; any other origin is refused by name. Add one by naming it exactly in exposedTo — no wildcards, since *.example.com would hand every subdomain the right to run your actions.

Site page tools, under Channels and access, is about your VISITORS: turn it off and the Site tools sheet stops appearing, without touching your site's code.

Assistant may operate the host page, under Integration › Page tools, is about the ASSISTANT, with three settings:

New workspaces start at All actions, with confirmation — safe, since nothing is reachable until your page registers a tool and names your assistant in exposedTo. The panel also takes allow/deny lists by tool-name prefix (blocking wins) and logs every attempt: tool, page, answer, outcome.

6. Let a checker see them

The SDK writes <link rel="webmcp-catalog" href="…"> into your head, rewritten whenever your tool list changes, so an inspector can confirm registration without a console. If your site has a server, serve that same document at a real URL and link it from your served head — the only version a reader sees without running your page.

Verify

1. Open your site with the assistant and press Site tools in its header — every registered tool is listed with its description, arguments, and read-only mark.
2. Run a read-only tool from that list; the result matches what your page shows.
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 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 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.