track_delivery, a bookings app find_free_slot, an accounting app
get_unpaid_invoices.
The API follows WebMCP — the
W3C proposal that exposes navigator.modelContext so pages can register tools
for AI agents. You don’t need a browser that supports WebMCP:
salesive-dev-tools ships a complete implementation that works everywhere, and
mirrors into the native API when one exists.
How a call flows
- Your page registers tools with
modelContext.registerTool(...). - The dashboard forwards the descriptors (name, description, schema — never your functions) to Ola’s backend.
- When Ola decides to use your tool, the merchant sees an approval card in the chat — your app’s logo, the tool name, and the arguments — with Approve, Reject, and Always allow.
- On approval, the call is posted into your iframe, your
execute()runs in your page (your session, your data), and the result goes back to Ola.
Tools run entirely client-side in your iframe. They involve no OAuth scopes,
no API tokens, and no server-side access — a tool can only do what your page
can already do.
Registering a tool
execute may return an MCP-style { content: [{ type: "text", text }] }
object, a plain string, or any JSON-serializable value — the SDK normalizes it.
Throw an error to report failure; Ola is told and continues gracefully.
Unregister with modelContext.unregisterTool("track_delivery"), or pass an
AbortSignal at registration (spec-style):
Browser support — handled in the package
salesive-dev-tools/webmcp is a self-contained implementation, not a thin
wrapper over a browser API:
- No native WebMCP (every stable browser today): the module itself is the
implementation, and it also installs itself as
navigator.modelContextanddocument.modelContextwhen they’re absent — code written against the standard API runs unchanged. - Native WebMCP present (e.g. Chrome’s origin trial): the native object is left untouched, and your registrations are mirrored into it too — so browser-level agents see your tools alongside Ola.
modelContext as your source of truth and you never need to
feature-detect anything.
Approval, “Always allow”, and revocation
Every call needs the merchant’s explicit approval in the Ola chat. The approval card shows your app’s logo and name from the installation record (not from your registration payload), the tool title, and the exact arguments.- Approve — this one call runs.
- Always allow — this call runs, and future calls of this specific tool from this installation run without asking.
- Reject — Ola is told the merchant declined and moves on.
Limits
Registrations exceeding a limit are rejected server-side; the rest of the
payload still registers. Names are automatically namespaced per app
(
app__yourapp_xxxx__tool_name), so two apps can expose tools with the same
local name without conflict.
Full example — React
Security model
- Your
executefunctions never leave your page — only descriptors are shared, and calls come back to your iframe over the same origin-checked App Bridge as every other event. - Every call is gated by merchant approval (or a prior explicit “Always allow” for that exact tool).
- Tool results are treated as third-party data by Ola — descriptions and results are length-capped and sandboxed with untrusted-content guidance.
- Only Ola (the default dashboard assistant) can use app tools; other agents on the platform can’t see them.
Next steps
App Bridge
Lifecycle events, runtime permissions, and the file picker.
Build & publish
Submit your app for marketplace review.

