WebMCP tools for B2B sites: which actions to expose first

TL;DR

• WebMCP lets a page offer AI agents named tools instead of making them guess at buttons. On a B2B site, the question is not how to use it but which few actions deserve a tool.
• Start with actions that are frequent, valuable to you and low risk: request a demo or quote, compare plans, check an integration or coverage. Most of them already exist as forms.
• Hold back anything that creates accounts, spends money or changes data until you have watched real agent traffic, and mark those tools as consequential when you add them.

Where WebMCP stands in October 2026

WebMCP is still a draft. The specification is a Draft Community Group Report of the W3C Web Machine Learning Community Group, dated 20 October 2026, and it says plainly that it "is not a W3C Standard nor is it on the W3C Standards Track." The project's implementation status page lists origin trials in Chrome 149 and Edge 150, experimental support in Brave's Leo assistant and support in ChatGPT Desktop. Firefox and Safari have no status beyond open standards-position discussions.

So few visitors' agents call WebMCP tools today. Agent traffic in general is growing fast, though: Cloudflare reported in September 2026 that daily requests from AI agents on its network grew by more than 1,700% over the previous year, and it described WebMCP as a way to "expose actions directly instead of making agents guess which button to press" (Cloudflare). The cost of preparing one or two tools is small, and most of the work, clean forms with clear labels, helps people too.

If WebMCP is new to you, read what WebMCP is first. This article assumes you know the basics and want to decide what to build.

How to pick: four questions per action

List every action a visitor can take on your site, then score each one:

1. Frequency. How often do visitors try to do this? Check form submissions, chat logs and button clicks.
2. Value. What is it worth to you when it succeeds? A demo request is worth more than a newsletter signup.
3. Risk. What happens if an agent does it wrong or does it when the user did not mean to? Reading a price list is harmless; starting a paid plan is not.
4. Effort. Is there already a form or a function you can wrap, or would you need to build something new?

Expose first the actions that score high on frequency and value and low on risk and effort. On almost every B2B site, that list is short.

Expose first: the low-risk, high-value tools

Request a demo or a quote

This is the action most B2B visitors come for, and it already exists as a form. The declarative API turns that form into a tool with two attributes on the form element: toolname and tooldescription. When an agent calls the tool, "the browser brings the form into focus and populates its field," and the form stays visible. By default, "the user must manually click Submit," which makes this the safest kind of tool there is.

<form toolname="request_quote"
      tooldescription="Request a freight quote for a shipment between the EU and North America. Returns a confirmation; sales replies within one business day."
      action="/quote" method="post">
  <label for="origin">Origin port or city</label>
  <input id="origin" name="origin" required>

  <label for="destination">Destination port or city</label>
  <input id="destination" name="destination" required>

  <label for="volume">Shipment size</label>
  <select id="volume" name="volume" required
          toolparamdescription="Approximate size of the shipment">
    <option value="pallets">1–10 pallets</option>
    <option value="lcl">Less than a container</option>
    <option value="fcl">One or more full containers</option>
  </select>

  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>

  <button type="submit">Request a quote</button>
</form>

Leave toolautosubmit off. Your submit handler can detect agent submissions through SubmitEvent.agentInvoked and log them, and it can send a structured result back to the agent with respondWith(), after calling preventDefault(), as Chrome's docs describe.

Compare plans or estimate a price

Buyers ask agents to compare vendors on price, so a read-only tool that returns your plans for a given team size or usage is valuable. It is also safe: it changes nothing. The imperative API registers it from JavaScript, with readOnlyHint set:

if ("modelContext" in document) {
  await document.modelContext.registerTool({
    name: "compare_plans",
    description: "Compare subscription plans for a given number of users. Returns each plan's monthly price, included users and main features.",
    inputSchema: {
      type: "object",
      properties: {
        users: { type: "integer", description: "Number of people who will use the product" },
        billing: { type: "string", enum: ["monthly", "annual"], description: "Billing period the buyer prefers" }
      },
      required: ["users"]
    },
    annotations: { readOnlyHint: true },
    async execute({ users, billing = "monthly" }) {
      const res = await fetch(`/api/plans?users=${users}&billing=${billing}`);
      if (!res.ok) return "Plans could not be loaded. The pricing page lists all plans.";
      return JSON.stringify(await res.json());
    }
  });
}

Return the same numbers your pricing page shows. If the tool and the page disagree, the agent will report both and the buyer will trust neither.

Check an integration, coverage or fit

"Do you integrate with our CRM?", "Do you deliver to Austria?", "Is this compliant with our industry's rules?" These questions decide shortlists. A read-only tool such as check_integration or check_coverage with one input and a precise answer saves the agent from reading ten pages and guessing.

Ask the site a question

If your site already has an assistant or search that answers from your content, a read-only ask_question tool lets an agent use it directly instead of scraping. Return the answer with the URLs it came from, so the agent can cite them.

Expose next: tools that create something

Add these once you have seen agents use the first group.

• Book a meeting. A booking creates an event in a person's calendar and sends invitations. Use a two-step pattern: a read-only tool that returns open times, then a booking tool with consequentialHint, so agents and browsers can "enforce mandatory user confirmation prompts before executing high-stakes tools," as the imperative API docs put it.
• Start a trial. Creating an account on the user's behalf is consequential. Keep the final step on the page, in front of the user.
• Download gated content. If the asset is behind an email form, the declarative pattern works; be clear in the description that the user's email will be sent to you.

Hold back for now

Some actions should stay out of WebMCP on a B2B marketing site, at least until browsers ship it by default and you have real usage data:

• Purchases and payments, including upgrades of an existing plan.
• Cancellations, deletions and account changes.
• Messages sent in the user's name, such as referrals or invitations to colleagues.
• Anything behind a login that you have not threat-modeled for agent use.

The draft's security section explains why. It discusses prompt injection against tools, including "tool poisoning" through descriptions and "output injection," as well as "misrepresentation of intent" and "privacy leakage through over-parameterization." Consequential actions raise the stakes of each.

The priority list at a glance

Writing tools agents pick correctly

Chrome's best-practices guide is short. The points that matter most for B2B tools:

• Name the outcome exactly. "Distinguish execution from initiation." A tool that opens the demo form is start_demo_request; one that submits it is request_demo.
• Describe what it does and when to use it, in positive terms. Chrome advises positive language instead of a list of limitations: say what the tool does, and the limits follow.
• Accept raw input. Let the agent pass "about 25 people" or "Rotterdam to Houston" and parse it in your code, instead of making the model calculate.
• Use specific types and enums for fields with fixed values, and explain choices: billing: "annual", not billing_id: 2.
• Validate strictly in code, loosely in schema, and return errors that say what to fix, so the agent can retry.
• Ask only for what you need. Every extra parameter is extra personal data an agent might share. That is the over-parameterization risk the draft describes.
• One job per tool, no overlaps. "The more tools you provide and the more the tools have overlap, the harder it is for the agent to pick correctly."
• Register tools when they are useful and remove them when they are not. A booking tool belongs on the page where booking makes sense. Lighthouse lists every registered tool and warns when a page registers more than 40, because each one consumes context, adds latency and raises "the risk of confusion for agents."

Guardrails that stay on your side

A tool runs your page's code with the user's session. Keep these rules whatever you expose:

• The server decides. Authentication, rate limits and validation stay server-side, exactly as for a human click.
• Mark untrusted output. If a tool returns reviews, forum posts or other user-generated text, set untrustedContentHint.
• Mind iframes. Per the imperative API docs, tool registration is disabled by default in cross-origin iframes; an embed needs allow="tools" from the parent page. Only grant it to embeds you control.
• HTTPS only. The draft marks document.modelContext as available only in secure contexts.

A 30-day rollout

For the wider picture of crawlers, content and analytics, use the agent-ready website checklist. To see which agents already visit your pages, read how to tell when AI agents visit your website.

The first WebMCP tools on a B2B site should be boring: the quote form you already have, a plan comparison and an answer to "do you work with X." They are cheap to build, safe to expose and exactly what a buyer's agent is trying to do. Leave the actions that move money or data for later, when the standard and your own traffic data are both more mature.