Your forms have a new kind of visitor. WebMCP is how you greet it.

Picture the visitor your contact form was designed for. A person, a mouse, two minutes of patience. Labels they can read, a red asterisk they understand, a checkbox they know to tick.

Now picture a different visitor. Someone asks their AI assistant to “book a demo with that vendor”, and the assistant opens your page and starts working out your form. It can’t see your design. It reads the markup and guesses. Is “Company” the company name or the company size? Is that empty field at the bottom a real question or a spam trap? Does pressing Enter send it?

Guessing is how leads get lost. WebMCP stops the guessing.

What WebMCP actually is

MCP, the Model Context Protocol, is how AI applications connect to tools: a server says “here’s what I can do, and here’s what each action needs”, and the model calls it. WebMCP brings the same idea to an ordinary web page. The page declares its own tools, and an agent working in the browser on someone’s behalf can call them directly instead of clicking around.

There are two ways to do it. The imperative way is JavaScript: the page registers tools, each with a name, a description, an input schema and a function to run. The declarative way is plain HTML: you add a few attributes to a form you already have.

It’s early. WebMCP is being developed in the W3C Web Machine Learning Community Group, with editors from Google and Microsoft, and it’s a draft, not a finished standard. Chrome is testing it, and the draft has already changed shape once: the JavaScript entry point moved from navigator.modelContext to document.modelContext. If you build on it, plan to keep up.

Why start with forms

On a B2B website, forms are where the site turns into revenue. Before adding anything for agents, get the plumbing right: render the CRM’s forms in the site’s own design and hold every submission in a delivery queue until the CRM confirms it, retrying if it has to. Then no lead goes missing between the form and the CRM.

That makes the next step obvious. If agents are going to fill in forms for people, the forms that never lose a lead should also be the ones an agent can’t misunderstand. That is what WebMCP is for.

What it looks like

The declarative version is small enough to show. This is the contact form on this site, trimmed to the parts that matter:

<form toolname="contact_arvind"
  tooldescription="Write a message to Arvind Kumar from the contact form
    on this page. You fill in the fields; the person using the page
    reviews them, ticks the consent box and presses Send. Nothing is
    sent without them. Messages are answered by email.">

  <input name="ak_email" type="email" required
    toolparamdescription="The sender's email address. The reply goes here.">

  <textarea name="ak_message" required
    toolparamdescription="What the sender would like Arvind Kumar to know
      or help with, in their own words."></textarea>

  <input name="ak_consent" type="checkbox" required
    toolparamdescription="Consent to be contacted back. Leave this for the
      person to tick themselves.">

  <input name="ak_trap" type="text" tabindex="-1"
    toolparamdescription="Spam trap. Always leave empty.">

  <button type="submit">Send</button>
</form>

Three attributes do the work. toolname gives the form a name an agent can call. tooldescription says what the form does and what happens next. toolparamdescription explains each field in one sentence, which is the part most people skip and the part that matters most.

The AI Scanner on this site shows the other way: when the browser supports it, the scanner registers its tools from JavaScript, so an agent can ask it to check a page the same way a person would.

The details that decide whether it works

Building it taught me three things you won’t find in a quick-start guide.

Tell the agent what to leave alone

Most forms carry a honeypot: a hidden field that people never see and bots fill in, so the server can throw the spam away. Give that field an innocent name like “website” and you have set a trap for the wrong visitor. A helpful agent reads the markup, sees a field asking for a website, fills it in, and the form discards a real enquiry as spam. On this site the trap is called ak_trap, labelled “Leave this empty”, and described to agents as exactly what it is.

Let the person press Send

There is an attribute, toolautosubmit, that lets an agent submit a form on its own. I leave it off. The agent fills in the fields; the person reviews them, ticks the consent box and presses Send. Consent is the one field I describe to agents as theirs to leave alone.

Never make people pay for it

None of this changes the form for a person with a mouse. Browsers that don’t know WebMCP ignore the attributes. The form looks the same, works the same and lands in the same place. That’s the rule I’d give anyone adopting a draft standard: add it in a way that is invisible when nobody uses it.

WebMCP and MCP are different jobs

People mix these up, so it’s worth one paragraph. WebMCP is the front door: it is for agents visiting the website on a visitor’s behalf. A website MCP server is the other door: it lets a site’s own internal agents work on the site through checked operations instead of raw edits. One is for the people we want to reach. The other is for the team that runs the site.

Why bother before the agents arrive

Fair question. Agents that use WebMCP are only starting to show up, and the standard will keep moving.

But the cost is small, and the timing is the point. Every shift in search has rewarded the sites that were ready early: clean markup before crawlers got picky, structured data before rich results. Agents filling in forms for people is the next version of that. When they arrive in numbers, you want your forms to be the easiest on the web to get right.

This site has it too. Ask an agent to contact me from the Contact page and it will find a tool called contact_arvind, fill it in, and leave the last step to you.