Agent Actions

Agent Actions are what a buyer’s AI agent can do on your site: read your content and act on it — request a quote, request a time, ask for a callback — without leaving the page and without your visitor typing into a chat.

On your pages, Inception Agents registers the actions with the browser’s agent API (document.modelContext; earlier builds used navigator.modelContext), which lets a page offer tools to the AI agent driving the browser: ChatGPT’s desktop browser and Codex, Gemini in Chrome, and headless agents such as BrowserRun and Playwright-based operators.

The browser API reaches agents in a browser. The same actions also answer at https://your-domain.com/mcp for agents that never open one: personal agents and chat connectors calling from their own servers (see Agents that call your MCP server directly).

The page tools are registered by the Inception Agents page script (beacon.js with data-webmcp="1"). Three install paths put it on your site, all from the same configuration; you only need one.

What gets registered

Every tool comes from configuration you already have in the dashboard — nothing is registered that you did not publish.

Read tools (from your Inception Points). get_briefing (the one-shot briefing: facts with proofs, scope, hours, earliest availability), ask_site(query) (the query engine over your curated and computed answers), get_availability, and one get_{slug} per published point (get_pricing, get_service_area, get_credentials, …). These carry readOnlyHint and run the same code path as GET /agent/{slug}, so every call lands in the same analytics as a crawler visit — with the surface recorded as webmcp.

Action tools (from your interaction intents). Each enabled intent under Interaction → Express Flows becomes one tool, named by its tool_name, with the model-facing field descriptions you wrote (agent_description). The intent’s handler decides what the tool does:

Action tools that create a request carry consequentialHint. A request reaches you once three things are in: a name, a phone or email, and the person’s agreement to be contacted. There are three ways they arrive, and every request records which one it was.

A request that came through the hosted express form is recorded as express_form. One where a text-message code was verified is recorded as sms_confirmed, but only when the verified number is the number the request was completed with: a code sent to one phone never vouches for another. The method appears on the lead, in its consent proof, and on the lead.captured webhook event (data.lead.provenance.approval_method), so your team can see what stood behind the consent.

Two rules follow from an agent’s word not being a person’s signature. Marketing consent is recorded only when the person ticked it themselves on the card on your page. An agent can complete a request, and you can answer it, but it cannot opt someone into marketing; neither can a post to the express form, and neither can a verified text code, which proves who holds a number and nothing about a marketing box. And one contact can complete five requests with you in 24 hours, counted by phone number as well as by the full contact, so a new email address on each call does not reset it; after that the agent is told nothing was sent.

Bookings against a connected calendar always take two calls, because the person (or their agent) has to choose one of the offered times.

When nobody is watching the page. Personal agents often drive a browser no one is looking at. If the card appears and no pointer or keyboard reaches it within 30 seconds, the tool call stops waiting and tells the agent how to finish with confirm_request. The card stays on the page for ten minutes in case the person is only slow, and the rest of that session skips the card.

The tool budget

An agent pays tokens for every registered tool, so the page registers at most eight at a time: every action tool first, then get_briefing and ask_site, then the point that matches the current page, then the remaining points. The set is re-selected on navigation (including pushState routing) so the current page’s point is always in. Intents can be limited to pages with Inject on pages (/pricing/*, exact paths, or everywhere).

Install: the WordPress plugin or the Cloudflare Worker

Both put your agent surface on your own domain and load the page script for you, with Agent Actions on. Each connects with a one-time install code, and connecting is what proves the site is yours. Going live runs as a checklist from Claude or a coding agent (the Inception Agents connector’s /inception-go-live playbook): approve the tools agents will see, choose who receives leads, install, prove it from outside, and send a TEST lead through the real site. Follow WordPress or Cloudflare Worker.

Install: the script tag

A script tag registers the tools on your pages only; /mcp on your own domain needs the plugin or the Worker. Add data-webmcp="1" to your Inception Trace beacon tag. Existing installs only need the attribute added; the dashboard’s install snippets already carry it.

<script src="https://inception-agents-api.inception-agents.workers.dev/beacon.js"
  data-tenant-id="YOUR_TENANT_ID"
  data-conversion-tracking
  data-pixel-enrichment
  data-webmcp="1"
  async></script>

The beacon loads the Agent Actions module (/webmcp.js, ~40 KB, cached) only on browsers that expose the agent API (document.modelContext or navigator.modelContext). Every other browser loads nothing extra.

Where the tag goes, per platform (all in the dashboard under Trace → Install):

• WordPress: use the plugin instead: it loads the page script with Agent Actions on (Settings → Inception Agents → Agent tools) and also serves /mcp.
• Wix: Settings → Advanced → Custom Code → + Add Custom Code → All pages, Head.
• Squarespace: Settings → Advanced → Code Injection → Header.
• Webflow: Site settings → Custom Code → Head code → Save → Publish.
• GoDaddy Website Builder: Edit Website → Settings → Header HTML.

How the page script finds your tools

When your own domain serves /.well-known/agent-capabilities.json and /agent/index.json (the plugin and the Worker both do), the page reads its own copies. Otherwise the module asks the API for the same two documents in one call:

GET https://inception-agents-api.inception-agents.workers.dev/api/v1/webmcp/descriptors?domain=your-domain.com
→ { manifest, agentIndex, tools }

tools is the budgeted, ready-to-register list; manifest and agentIndex are the raw documents the page uses to match intents to pages. The response is public, cached for five minutes, and is also what you curl to see what an agent will see.

Cloudflare’s own switch: leave it off

Cloudflare offers a switch of its own for this (AI → Agent Readiness → WebMCP). Leave it off. It has no field for an MCP address; it re-serves your site’s /mcp with the tool annotations stripped (the hints that tell an agent a tool is an action), and when its bridge script is on the page our page script registers nothing, so the confirmation card never appears. On Cloudflare, use the Cloudflare Worker instead: it puts the same tools on your own domain, annotations and card included.

Agents that call your MCP server directly

Not every agent opens a browser. Personal agents and chat connectors call https://your-domain.com/mcp from their own servers, often while nobody is watching. They are let in without a key, and they see exactly what your page registers: your read tools and your action tools, limited to what fits your kind of business (a law firm’s site never offers a cart). That is the whole list. Your operator tools (analytics, audiences, campaigns) answer only to a request signed with your own key through the SDK route-through; a bearer token means nothing on this endpoint, so a made-up one gains nothing. An agent working this way completes a request exactly as the table above describes: with the person’s details and go-ahead sent with the request, or afterwards with confirm_request.

Behind the WordPress plugin or the Cloudflare Worker, each /mcp request reaches us signed with your site’s relay key, together with the visitor’s address, Origin and User-Agent, so each visitor is counted and rate-limited as themselves. A relay vouches for the visitor; it never gains operator powers.

Calls are limited per address: 120 a minute, and 10 a minute for tools that create a request or are metered. An agent that goes over is told to wait, and nothing is sent. A client that has not signed its request may send one tool call per JSON-RPC batch; the others come back with an error asking for separate requests.

Verify

# 1. The page script is on the live page, with Agent Actions on
curl -sL https://your-domain.com/ | grep -o 'data-webmcp="1"'

# 2. The tools an agent will be offered on the page
curl -s "https://inception-agents-api.inception-agents.workers.dev/api/v1/webmcp/descriptors?domain=your-domain.com"

# 3. Agents are pointed at /mcp (plugin and Worker installs)
curl -s https://your-domain.com/.well-known/mcp.json

# 4. The hosted MCP tool list, as an agent calling from its own servers sees it
curl -s -X POST https://your-domain.com/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Then open the site in a browser that supports the agent API: the address bar shows the page has tools, and asking the agent about the business makes it call get_briefing or ask_site before it answers. Each visit is recorded in your workspace as one agent conversation (Agent Intelligence → Conversations), and every completed request lands in Leads. Going live runs checks like these from outside for you, then sends a TEST lead through the real site; after that, the site is checked every hour.

Computer-use agents that only see the page

Agents that navigate visually and cannot call the page’s actions still complete the same requests through the express pages: GET /agent/express/{intent} renders the same confirmation card over a plain HTML form, and the form works with JavaScript off. See Express Flows.

What is billed

One price per request that reaches you, set for your industry, with no monthly fee and no setup fee (see pricing). A request counts when an agent called request_* or book_*, the person completed it with their name, a contact channel and their consent (in the same call, on the card, or through confirm_request / confirm_booking), and it reached you: by email, Slack or text, through your connected system, or as a booking on your calendar. It counts once, however many times the agent retries, and it appears in Leads.

Never billed: everything an agent reads first (get_pricing, check_fit, get_prep_checklist, compare_plans, and the point reads get_briefing, ask_site and get_{slug}), a request for work you don’t take, a repeat request from the same person within 30 days, test requests, and a request that never reached you. Set a monthly cap and we never bill above it; requests keep reaching you. Every billed request is listed, with what it became.