The tools

Each integration chooses which of these to offer. Each tool reaches the browser with a name, a title (for example "List products"), a description, the inputs it takes (as a JSON Schema, a standard way to describe data) and hints about whether it changes anything. You can change any tool's description under Configure.

Tools that only read#

These don't save anything.

answer_question doesn't change your data, but it does start or continue a conversation in your inbox, and it runs your AI agent, which uses AI credit.

Tools that save something#

These are marked as changing data, so a careful AI assistant should check with the visitor first.

Each tool only reads the inputs listed for it.

What it sends and where it goes#

The script sends only what the AI assistant passes to a tool, plus your key and a random id for the page visit (made when the page loads and kept only in its memory), so Subcontext can keep the visit's calls together. It reads nothing from your page, sets no cookies and stores nothing in the browser. For buy_policy it shows your checkout in a frame over the page, tells the checkout your page's address so the checkout lets only that page show it, and when the panel closes, tells Subcontext the step it closed at, for the visit's conversation.

• register_interest finds the visitor among your contacts (by email, then phone) or adds them. It fills in only blank details, so it never overwrites what you already have. It records their consent for the ways they gave you to contact them, makes them a lead, and adds an entry to their timeline. Any metadata (up to 10 entries) is saved to their record, marked as coming from an AI assistant and given the lowest level of trust. If you set an outbound CRM on the tool, the lead is sent there too. The assistant is only told that you have the details.
• share_requirements saves requirements to an existing contact's record, in the same low-trust way. It never creates a contact.
• book_callback finds or adds the contact, books the call (with an invitation when an email is given), records it on their lead, tells your team, and logs it to Google Sheets if you set that up. It only books inside your business hours, in the future, and in a free slot.
• answer_question starts a conversation in your inbox, or carries one on when given a conversation_id, and answers with your AI agent and its usual safety checks.
• get_quote prices your product the way your agent sells it. It quotes the products of the agent's sales scripts that the platform prices itself, each on the sales flow the agent sells it on over WebMCP (your product's own sales flow unless you chose another for WebMCP on the agent). It finds or adds the person as a customer and a lead and starts their application, so asking again for the same person and cover carries on the same one. The tool itself lists what each product's sales flow asks before its price, step by step and as you released it: its questions (the type of answer, its options and limits, and when it applies) and its choices (the options, what your sales flow says to tell them first, and what choosing confirms). Their age comes from their date of birth. So the assistant asks them all and prices in one call. A choice that your sales flow sends to your team (an adviser) ends there: the tool returns talk_to_the_team instead of a price, and the assistant offers a callback. Your own declarations on a choice are recorded as met when the visitor makes it. A step that asks for the visitor's own words is listed too, as optional: what they say (reflections) is kept for their statement of needs, as your quote form keeps it. Anything still open comes back as needs_answers (a question released since the page loaded, say), in your sales flow's order, and the assistant asks and calls again. Before it gives a price, it hands the assistant what you must tell them first, word for word: who you are and how you're paid, and whatever your sales flow places on its steps up to and with the price while the sale still owes it (your key documents, their right to cancel, your own disclosures). It prices only once it's called again saying it has read each one out (disclosures_read), and records each as given over WebMCP. Health questions need the person's consent first. A price comes with a link to review it and carry on with the application on your site. A visitor can ask for a handful an hour.
• buy_policy lets the visitor buy the price get_quote gave them, without leaving your page. The assistant can't use it until the visitor agrees in their browser. It first hands the assistant everything you must tell them before they buy, word for word as your checkout words it (your key documents with their links, their right to cancel, how they'll pay, how to complain, the Ombudsman and the FSCS, and any extra services or terms your product has), and goes on only once called again saying it has read each one out. Each is then recorded as given over WebMCP, so the checkout keeps only what needs the visitor's own yes. Your checkout then opens in a panel over the page, where they set up their Direct Debit, pay the first premium and confirm what they're buying, exactly as on your hosted checkout. Bank and card details go only into Stripe's own fields: they never reach the assistant, your page or Subcontext's API, and the assistant never sees the checkout's link. Their yes to what they're buying is theirs, given in the checkout, never the assistant's, and so is any declaration of your own the sale still owes: the checkout shows it, and asks them to tick any they must confirm or agree to, before payment. The checkout also shows back what their assistant read them, and asks them to tick that they were told it, so you have their own word for it as well as the assistant's. When they finish, the checkout shows their policy and, if your sales flow asks for their marketing preferences once the policy is set up, asks them there (recorded as your quote form records it), and the assistant is told their policy number and start date. If they close the panel first, it's told the step they left at and what to suggest, and nothing has been charged. It works only for a price this website's get_quote gave, with the email given to it, and for a policy already bought it returns the policy.
• Vulnerable customers. get_quote and buy_policy ask the assistant to think about whether anything the visitor has said suggests they may be in vulnerable circumstances, and to pass what it noticed as vulnerability (signs, lasting, and a short note). It's recorded as your agent's own vulnerability check is. Signs of something temporary (a bereavement, losing a job, money worries) stop the sale: the tool returns talk_to_the_team, it's raised with your team in the visit's conversation, and the assistant tells the visitor someone will be in touch. A lasting need (sight or hearing loss, a long-term condition) lets the sale carry on at their pace, and your team is told so their documents can go out in a format they can use.
• No tool reads your contacts back. An assistant can't list or look up your contacts.
• Every visit is a conversation you can audit. Where you have a live agent, a page visit's tool calls are kept in order in one WebMCP conversation in your inbox, owned by the agent that sells (else the one that answers questions), with each call's arguments and result, and linked to the person's lead and application. A purchase joins the conversation its price was quoted in, even from a later visit, and the sale's own steps (their consent, their confirmation in the checkout, the payment and the policy) are recorded in it too, as is how the checkout panel ended (bought, or the step they closed it at). Each call is checked against your rules first, as your agent's own tools are: one your rules refuse, or want a person to approve, doesn't run, and the assistant is told to offer a callback. Its Audit tab and PDF show the lot. answer_question answers in the same conversation.
• Every tool call is also logged and shown under Insights > Conversations.

What's public and what's protected#

• The key is public. It is meant to be in your page source, like the key in any embedded widget. It can't do anything on its own.
• Your websites list is the main protection. Every request must come from one of the websites on the integration. If a key leaks and is misused, press Rotate key and update your snippet. The old key stops working straight away.
• Only safe actions. Because a determined person could call the tools outside a browser, the tools only read product information or take in leads and callbacks. Nothing returns your customers' data.
• Unticked tools can't be called. A tool you haven't ticked isn't offered, and a direct call to it is refused.
• Your plan is checked on every request. If your plan stops including agent access, the snippet stops working, even though the integration is still there.
• No visitor login. Tool calls are made on behalf of your firm through the key, not as a signed-in person.
• Rate limit. Up to 300 requests per visitor IP address every 5 minutes.