How we added WebMCP to sikte.ai

In brief: Sikte AI added a WebMCP tool, checkAiVisibility, to sikte.ai/sjekk-din-synlighet on October 18, 2026. It uses Chrome's declarative WebMCP API (the attributes toolname, tooldescription, and toolparamdescription on a standard HTML form). The website has an origin trial token, so the tool is available to visitors using Chrome 149 or newer without flags. The agent fills in the URL and email; consent and submission are handled by the user. To our knowledge, it is the first WebMCP tool on a Norwegian website.

This post is for anyone working with websites in B2B, banking, insurance, or retail who is wondering what the "agentic web" actually means for a contact form or a price calculator.

What is WebMCP?

WebMCP is a proposed web standard that allows a website to tell AI agents exactly what actions the page offers—such as "get quote" or "submit inquiry"—instead of the agent having to guess by scraping the screen. The standard is being developed within the W3C Web Machine Learning group, spearheaded by Google and Microsoft, and Chrome 149 opened a public origin trial in May 2026.

Today, an AI agent visiting a website must interpret forms: locate the field that likely means "annual mileage", hope the button doesn't trigger a popup, and click its way through. With WebMCP, the page declares a tool with a name, description, and a JSON schema for input data. The agent calls it like a function. The form remains visible to the user, and the action takes place within the user's own browser.

There are two ways to do this:

• Declarative API: add HTML attributes to a regular <form>. No new code. This is what we used.

• Imperative API: register tools in JavaScript using document.modelContext.registerTool(). Provides full control over the logic behind the tool.

Two things are worth noting before you read on. WebMCP only works in browsers that support it, which currently means Chrome. And it is designed for agents running in the browser—not for ChatGPT, Perplexity, or Google AI Overview, which fetch pages from a server without executing JavaScript. The latter becomes important toward the end.

The form we started with

We chose the AI visibility check because it is the simplest conversion flow we have, and because it is entirely our own. The form has four fields, a Cloudflare Turnstile check, and one button.

The form is a React code component in Framer, rendered directly into the page—no third-party iframe. This turned out to be crucial: WebMCP is locked to the same origin as the page, so an iframe-based HubSpot or Typeform form would have required a different approach.

Two technical details we uncovered when inspecting the page: none of the fields had the required attribute in the HTML (validation was handled in JavaScript), and the form submitted data to our own API via fetch instead of a standard form submit. Both impacted what we had to modify.

How we built it

The entire change consists of four attributes on the form and the fields. Chrome reads them from the DOM and generates the JSON schema automatically.

<form toolname="checkAiVisibility"
      tooldescription="Starts a free AI-visibility analysis of a website (citability, crawlability, structured data, content structure, entity clarity; each scored 0-100). The report opens after about two minutes and a link is emailed. Requires the user's email. Fill in the website and email only; the user must tick the data-processing consent box, complete the verification and click the submit button themselves."
      novalidate>

  <label for="url">Nettadresse</label>
  <input id="url" name="url" type="url" required
         toolparamdescription="Full URL of the site to analyse, including https://. Use the root domain unless the user names a specific page.">

  <label for="email">E-post</label>
  <input id="email" name="email" type="email" required
         toolparamdescription="The user's email address; the report link is sent here.">

  <input id="consent" name="consentToProcess" type="checkbox"
         toolparamdescription="Consent to Sikte AI storing and processing personal data. Leave unset: the user must tick this box themselves.">
  <label for="consent">Jeg samtykker til at Sikte AI kan lagre og behandle mine personopplysninger.</label>

  <input id="news" name="consentToCommunications" type="checkbox"
         toolparamdescription="Optional newsletter opt-in. Leave unset: the user must tick this box themselves if they want it.">
  <label for="news">Jeg ønsker å motta nyhetsbrev fra Sikte AI</label>

  <button type="submit">Analyser nettstedet mitt</button>
</form>

<form toolname="checkAiVisibility"
      tooldescription="Starts a free AI-visibility analysis of a website (citability, crawlability, structured data, content structure, entity clarity; each scored 0-100). The report opens after about two minutes and a link is emailed. Requires the user's email. Fill in the website and email only; the user must tick the data-processing consent box, complete the verification and click the submit button themselves."
      novalidate>

  <label for="url">Nettadresse</label>
  <input id="url" name="url" type="url" required
         toolparamdescription="Full URL of the site to analyse, including https://. Use the root domain unless the user names a specific page.">

  <label for="email">E-post</label>
  <input id="email" name="email" type="email" required
         toolparamdescription="The user's email address; the report link is sent here.">

  <input id="consent" name="consentToProcess" type="checkbox"
         toolparamdescription="Consent to Sikte AI storing and processing personal data. Leave unset: the user must tick this box themselves.">
  <label for="consent">Jeg samtykker til at Sikte AI kan lagre og behandle mine personopplysninger.</label>

  <input id="news" name="consentToCommunications" type="checkbox"
         toolparamdescription="Optional newsletter opt-in. Leave unset: the user must tick this box themselves if they want it.">
  <label for="news">Jeg ønsker å motta nyhetsbrev fra Sikte AI</label>

  <button type="submit">Analyser nettstedet mitt</button>
</form>

<form toolname="checkAiVisibility"
      tooldescription="Starts a free AI-visibility analysis of a website (citability, crawlability, structured data, content structure, entity clarity; each scored 0-100). The report opens after about two minutes and a link is emailed. Requires the user's email. Fill in the website and email only; the user must tick the data-processing consent box, complete the verification and click the submit button themselves."
      novalidate>

  <label for="url">Nettadresse</label>
  <input id="url" name="url" type="url" required
         toolparamdescription="Full URL of the site to analyse, including https://. Use the root domain unless the user names a specific page.">

  <label for="email">E-post</label>
  <input id="email" name="email" type="email" required
         toolparamdescription="The user's email address; the report link is sent here.">

  <input id="consent" name="consentToProcess" type="checkbox"
         toolparamdescription="Consent to Sikte AI storing and processing personal data. Leave unset: the user must tick this box themselves.">
  <label for="consent">Jeg samtykker til at Sikte AI kan lagre og behandle mine personopplysninger.</label>

  <input id="news" name="consentToCommunications" type="checkbox"
         toolparamdescription="Optional newsletter opt-in. Leave unset: the user must tick this box themselves if they want it.">
  <label for="news">Jeg ønsker å motta nyhetsbrev fra Sikte AI</label>

  <button type="submit">Analyser nettstedet mitt</button>
</form>

Four key takeaways:

1. The descriptions are in English, even though the site is in Norwegian. The agent's language model reads them, not the user, and English yields the most predictable interpretation across models.

2. required had to be added to the HTML. Chrome uses this attribute to populate the required list in the JSON schema. We kept novalidate on the form, so the user experience remains untouched.

3. No toolautosubmit. Without it, the agent populates the fields, highlights the form, and stops. The human clicks the button. More on why in the next section.

4. React and unknown attributes. React may strip out lowercase attributes it does not recognize. We initially tested them as regular JSX props; they survived into the DOM during Framer's build process, sparing us from having to apply them inside a useEffect.

We made one addition to the form's JavaScript: when the user submits a form populated by the agent, we reply to the agent using respondWith() on the submit event, returning status and a link to the report. That allows the agent to inform the user where the report can be found.

Chrome generated this schema from the HTML above—this is what the agent sees:

{
  "name": "checkAiVisibility",
  "inputSchema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "Full URL of the site to analyse ..."
      },
      "email": {
        "type": "string",
        "description": "The user's email address ..."
      },
      "consentToProcess": {
        "type": "boolean",
        "description": "Consent to Sikte AI ... Leave unset ..."
      },
      "consentToCommunications": {
        "type": "boolean",
        "description": "Optional newsletter opt-in ..."
      }
    },
    "required": ["url", "email"]
  }
}

{
  "name": "checkAiVisibility",
  "inputSchema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "Full URL of the site to analyse ..."
      },
      "email": {
        "type": "string",
        "description": "The user's email address ..."
      },
      "consentToProcess": {
        "type": "boolean",
        "description": "Consent to Sikte AI ... Leave unset ..."
      },
      "consentToCommunications": {
        "type": "boolean",
        "description": "Optional newsletter opt-in ..."
      }
    },
    "required": ["url", "email"]
  }
}

{
  "name": "checkAiVisibility",
  "inputSchema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "Full URL of the site to analyse ..."
      },
      "email": {
        "type": "string",
        "description": "The user's email address ..."
      },
      "consentToProcess": {
        "type": "boolean",
        "description": "Consent to Sikte AI ... Leave unset ..."
      },
      "consentToCommunications": {
        "type": "boolean",
        "description": "Optional newsletter opt-in ..."
      }
    },
    "required": ["url", "email"]
  }
}

The hidden Turnstile field was correctly omitted. We noticed that type="url" and type="email" mapped to plain string without a format—this is Chrome's design choice, and the descriptions make up for it.

Consent and Turnstile: why the agent isn't allowed to submit on its own

The most critical design decision was that the agent must never be allowed to check the consent box or submit the form. Under GDPR, consent must be an affirmative, active choice by the individual. An agent ticking the box because the user said "just do it" does not suffice, and the Data Protection Authority would hardly disagree.

The solution relies on three layers:

• Consent fields are not required in HTML, and the description explicitly states: "Leave unset: the user must tick this box themselves". The agent knows the field exists, but is instructed to leave it alone.

• No toolautosubmit. When the tool is called, Chrome scrolls the form into view, fills in the URL and email, and places a dashed border around the form and submit button (via the CSS pseudo-classes :tool-form-active and :tool-submit-active). Then it pauses. The tool call remains in a "pending" state until the person clicks or cancels.

• Turnstile must still be passed, and that verification is executed by Cloudflare—not the agent.

As a result, WebMCP saves the user from repetitive typing, while the legally significant actions—consent and submission—remain strictly human. The same pattern applies to a mortgage application, an insurance policy, or a B2B inquiry: the agent prepares, the human confirms.

How we tested it

You need Chrome 149 or later. Because WebMCP is still an origin trial, either the website must have an origin trial token, or you must enable the flag chrome://flags/#enable-webmcp-testing. We used both: during development, we tested preview environments with the flag, and for production, we embedded an origin trial token for https://sikte.ai into the page's <head>. With the token in place, the tool is accessible to all visitors on Chrome 149 or newer without flags. The token expires on March 30, 2027, and must be renewed before then.

1. Verify that the tool is registered. Open DevTools → Application → WebMCP. The panel lists all tools on the page and displays the JSON schema as generated by Chrome. This is where you verify that the required list is correct.

2. Invoke the tool without a language model. In the console, you can simulate what an agent would do:

   const tool = (await document.modelContext.getTools())
     .find(t => t.name === 'checkAiVisibility');
   
   await document.modelContext.executeTool(tool, {
     url: 'https://sikte.ai',
     email: 'test@example.no'
   });

   const tool = (await document.modelContext.getTools())
     .find(t => t.name === 'checkAiVisibility');
   
   await document.modelContext.executeTool(tool, {
     url: 'https://sikte.ai',
     email: 'test@example.no'
   });

   const tool = (await document.modelContext.getTools())
     .find(t => t.name === 'checkAiVisibility');
   
   await document.modelContext.executeTool(tool, {
     url: 'https://sikte.ai',
     email: 'test@example.no'
   });

3. Observe what happens on the page. The form scrolled into view, both fields were populated, the consent checkboxes remained blank, and the button received the blue outline. Nothing was submitted. The call stayed pending until we clicked the button ourselves.

4. Check other browsers. In Firefox and Safari, document.modelContext is undefined, and the form behaves exactly as it used to. That is the essence of progressive enhancement.

Following deployment, we ran the same test on sikte.ai with the token active. When we checked the consent box and submitted the form manually, the agent received {"status": "started"} along with the link to the report.

One pitfall: executeTool expects the tool object from getTools(), not the name as a string. We spent a few minutes troubleshooting that.

Google also provides a Chrome extension, Model Context Tool Inspector, where you can enter a natural language prompt and watch the agent select and invoke the tool. It requires a Gemini API key to run prompts.

What we learned – and what Google AI Overview said afterwards

Four days after launch, we asked Google whether sikte.ai had any WebMCP tools. AI Overview replied no. The tool was present the entire time—we double-checked, and the toolname attribute is even present in the server-rendered HTML.

The reason is straightforward, and it gets right to the core of what we do. AI Overview does not run a Chrome agent against your page. Its response is constructed from Google's search index and a language model. document.modelContext is a browser runtime API; it never makes it into the search index. Chrome's own documentation lists this limitation: a client must visit the website directly to discover available tools.

Furthermore, there was no text anywhere stating that the tool existed. No mention on the page, no FAQ, no structured data, no blog post. Asked about something lacking documentation, the model answers "nothing found" and expresses it as a no.

There are two key lessons here:

• WebMCP and GEO are distinct channels. WebMCP enables browser agents to use your site. GEO (Generative Engine Optimization) enables answer engines to reference it. Implementing one provides zero value to the other.

• What the agent can do must also be readable. If ChatGPT, Perplexity, or Google are to say "sikte.ai has a tool for this", it must be explicitly stated in plain text and in structured data. That is why we are writing this post—and why the form page now includes an FAQ and structured data declaring the same.

We are tracking the outcome. The query "does sikte.ai have WebMCP tools?" is now posed weekly to Google AI Overview, ChatGPT, and Perplexity, and we will update this post once the answer flips.

What this means for B2B, banking, and insurance

Contact forms and price calculators are the two places where the difference between "AI can read the page" and "AI can act on the page" directly drives revenue. Both are already present on virtually every site in these sectors, and both can be declared using the exact approach shown above.

Three recommendations based on our experience:

1. Start with the calculator, not the form. A calculator is a pure function free of consent complexities. It is also where the competition is won: an agent comparing three insurance providers will select the ones that return an actual figure.

2. Separate reading from acting. An agent can pull a price estimate freely. An application, purchase, or inquiry should always go through a human, just as we did with consent. The explanation in tooldescription is the place to state this.

3. Include disclaimers in the response. The agent simply conveys the figure it receives. If the calculator fine print notes "example, excludes fees", that must also be included in the tool's description or response—otherwise it is lost before reaching the customer.

And for those pitching this internally: WebMCP makes the page usable for agents. That is not the same as having ChatGPT recommend you. Doing so still requires visible, citable copy—like this article.

Want to see how your website currently performs in AI search? Run the free AI visibility check—with or without an agent.

Sources: Chrome for Developers – WebMCP, Declarative API, WebMCP explainer (W3C WebML).