WebMCP in Practice: 5 Forms You Should Mark Today

Direct Answer

If you have a search, newsletter, contact, booking, or quote form on your site, add the attributes `toolname` and `tooldescription` to their `<form>` tag. Declarative WebMCP tells the AI agent what the form is for and what data to provide. In practice, check: unique `toolname`, specific `tooldescription`, correct `name` on fields, and no `toolautosubmit` on consents, bookings, and payments.

Template to copy:

> If [the form performs a specific action], mark it as `toolname="[action_name]"` and `tooldescription="[what it does + what data is needed]"`, because [the AI agent doesn’t have to guess the purpose of the form]. In practice, check [unique name, description, `name` fields, required fields, no autosubmit for risky actions].

A client asks the agent: "Find navy barefoot shoes in size 28 in this store and enroll me in the promotion notification." Without WebMCP, the agent sees the fields and buttons. With WebMCP, the search and newsletter forms tell him directly: "this is product search" and "this is newsletter signup."

Key takeaways

WebMCP is still in draft and early preview, but marking forms is cheap, reversible, and aligns with the direction of the standard.
The declarative version does not require JavaScript. You add attributes to the existing <form>.
The most important attributes are toolname and tooldescription; for fields, use normal name, required, type, min, max, pattern, and optionally toolparamdescription.
Start with 5 forms: search, newsletter, contact, booking, quote.
The Audit AI checkpoint for declarative WebMCP checks for the presence of toolname and tooldescription, so this fix is easy to verify.

Why This is Important in 2026

Chrome Developers describe WebMCP as an early preview aimed at giving websites a structured way to present tools for agents. The official draft of WebMCP by the Web Machine Learning Community Group discusses tools for agents and includes a section on declarative WebMCP. It is not yet a stable standard available everywhere, but the direction is clear: the agent should receive a description of the action rather than guess from the DOM and screenshots.

Chrome outlines two approaches. The declarative API is for standard actions recorded in HTML forms. The imperative API is for dynamic actions via JavaScript, for example, a cart that depends on application state. This article covers the former pathway, as it is the simplest for small business owners.

You do not need to rewrite your store in a new framework today. If you have access to a form template in WordPress, Shoper, Shopify, PrestaShop, or plain HTML, often you just need to add 2-4 attributes. This won't guarantee that every agent will execute the action right away, but it will provide a better description of the forms that can be audited now.

How WebMCP Differs from a Regular Form

A regular form tells the browser: "send these fields to this address."

A form with WebMCP additionally informs the agent: "this tool is for product searching," "this field is an email address," "this field describes the appointment date," "this action requires a message from the customer."

Without WebMCP:

example.html

<form action="/search" method="get">
  <input name="q" type="search" />
  <button>Search</button>
</form>

With declarative WebMCP:

example.html

<form
  action="/search"
  method="get"
  toolname="search_products"
  tooldescription="Search products in the catalog by product name, category, SKU or customer query."
>
  <input
    name="q"
    type="search"
    required
    toolparamdescription="Product name, SKU, category or search phrase."
  />
  <button type="submit">Search</button>
</form>

The difference lies in a few additional attributes. For a human, the page looks the same. For the agent, the form has a name, description, and meaning.

Step by Step: 5 Forms to Mark

01
Product Search
Bad
the form only has `q`, and the "Search" button is clear only to a human.
Better
the form is named `search_products`, the description specifies that it can search by name, category, or SKU, and the field has `toolparamdescription`.
example.html
```
<form
  action="/search"
  method="get"
  toolname="search_products"
  tooldescription="Search products in the catalog by name, category, SKU or customer query."
>
  <label for="search-query">Search the store</label>
  <input
    id="search-query"
    name="q"
    type="search"
    required
    autocomplete="off"
    toolparamdescription="Product name, category, SKU or natural language search phrase."
  />
  <button type="submit">Search</button>
</form>
```
For a shoe store, the agent might enter "barefoot shoes size 28". For a cosmetics store: "SPF 50 cream for sensitive skin." The agent doesn't have to guess that `q` means product query.
For local services, search makes sense too. A dental clinic might have `search_services`, while a beauty salon might use `search_treatments`.

Newsletter and Notifications

Bad

the newsletter form only has `email`, and the description on the page says "Stay updated."

Better

the agent sees that the form enrolls the user in the newsletter or promotional notifications.

example.html

<form
  action="/newsletter"
  method="post"
  toolname="subscribe_newsletter"
  tooldescription="Subscribe the user to email updates about new products, promotions and guides. Requires email consent."
>
  <label for="newsletter-email">Email address</label>
  <input
    id="newsletter-email"
    name="email"
    type="email"
    required
    autocomplete="email"
    toolparamdescription="Customer email address for newsletter subscription."
  />
  <label>
    <input name="marketing_consent" type="checkbox" required />
    I agree to receive marketing messages.
  </label>
  <button type="submit">Sign me up</button>
</form>

Do not add `toolautosubmit` here. The newsletter requires consent. The agent can prepare the form, but the user should see the consent and consciously confirm it.

For a supplements store, the description should be cautious: "Subscribe to product availability and educational updates," not "Subscribe to medical advice." A small change can make a big difference.

Contact Form

Bad

contact is described as "Write to us," and fields are named `name`, `email`, `msg`.

Better

the form indicates that it sends a message to customer support and lists the required data.

example.html

<form
  action="/contact"
  method="post"
  toolname="send_contact_message"
  tooldescription="Send a customer support message. Required fields: customer name, email address, and message."
>
  <label for="contact-name">Name</label>
  <input
    id="contact-name"
    name="customer_name"
    type="text"
    required
    toolparamdescription="Customer name used for the reply."
  />

  <label for="contact-email">Email</label>
  <input
    id="contact-email"
    name="email"
    type="email"
    required
    autocomplete="email"
    toolparamdescription="Email address for reply."
  />

  <label for="contact-message">Message</label>
  <textarea
    id="contact-message"
    name="message"
    required
    minlength="20"
    toolparamdescription="Customer message with question, order number or issue description."
  ></textarea>

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

For a furniture store, the agent might ask about the delivery time of a sectional sofa. For an accounting office, they could prepare an inquiry about solo entrepreneurship support. A good `tooldescription` doesn't have to be long; it just needs to convey the purpose of the form.

Appointment Booking

Bad

the booking form has fields for `date`, `time`, `service`, but the agent doesn't know if it's a preliminary request or a binding reservation.

Better

the description indicates that the form is for requesting an appointment, and the fields have clear limitations.

example.html

<form
  action="/booking"
  method="post"
  toolname="request_appointment"
  tooldescription="Request an appointment for a selected service, preferred date, and preferred time. Staff confirms the appointment by email or phone."
>
  <label for="service">Service</label>
  <select
    id="service"
    name="service"
    required
    toolparamdescription="Service the customer wants to book."
  >
    <option value="consultation">Consultation</option>
    <option value="cleaning">Facial Cleaning</option>
    <option value="physiotherapy">60-minute Physiotherapy</option>
  </select>

  <label for="appointment-date">Preferred date</label>
  <input
    id="appointment-date"
    name="preferred_date"
    type="date"
    required
    toolparamdescription="Preferred appointment date in YYYY-MM-DD format."
  />

  <label for="appointment-time">Preferred time</label>
  <input
    id="appointment-time"
    name="preferred_time"
    type="time"
    required
    toolparamdescription="Preferred appointment time."
  />

  <label for="appointment-email">Email</label>
  <input
    id="appointment-email"
    name="email"
    type="email"
    required
    toolparamdescription="Email address for appointment confirmation."
  />

  <button type="submit">Request Appointment</button>
</form>

If the booking is immediate and payable, do not use autosubmit. If it’s just a request for availability, it’s still better to leave confirmation to the user. WebMCP does not exempt you from logic regarding consents, payments, and GDPR.

Quote Request Form

Bad

the "Request a Quote" form has one text field and no context.

Better

the agent knows what data is needed for a preliminary quote, and the form uses named fields.

example.html

<form
  action="/quote"
  method="post"
  toolname="request_quote"
  tooldescription="Request a quote for a product, service, or project. Required fields: customer email, service type, budget range, and project description."
>
  <label for="quote-email">Email</label>
  <input
    id="quote-email"
    name="email"
    type="email"
    required
    toolparamdescription="Customer email address for the quote response."
  />

  <label for="quote-type">Quote Type</label>
  <select
    id="quote-type"
    name="quote_type"
    required
    toolparamdescription="Type of quote request."
  >
    <option value="product">Custom Product</option>
    <option value="service">Service</option>
    <option value="implementation">Implementation or Project</option>
  </select>

  <label for="budget">Budget</label>
  <select
    id="budget"
    name="budget_range"
    toolparamdescription="Approximate budget range in PLN."
  >
    <option value="under_1000">Up to 1000 PLN</option>
    <option value="1000_5000">1000-5000 PLN</option>
    <option value="over_5000">Above 5000 PLN</option>
  </select>

  <label for="quote-description">Description</label>
  <textarea
    id="quote-description"
    name="project_description"
    required
    minlength="30"
    toolparamdescription="Short description of the product, service, quantity, deadline, or business need."
  ></textarea>

  <button type="submit">Request Quote</button>
</form>

For a renovation company, this could be a quote for painting 70 m2. For a furniture store: an inquiry for a custom table. For Audit AI: a quote for implementing fixes after an audit.

Table: Which Forms to Mark First

| Form | toolname | Risk of autosubmit | Priority | | ---------- | ---------------------- | ----------------------: | -------: | | Search | search_products | low | 1 | | Contact | send_contact_message | medium | 2 | | Booking | request_appointment | high | 3 | | Quote | request_quote | medium | 4 | | Newsletter | subscribe_newsletter | high, marketing consent | 5 |

If you only have 20 minutes, start with the search and contact forms. If you run a salon, clinic, or service, booking will be more important than the newsletter. If you sell custom products, the quote form makes more sense than general contact.

Naming Conventions

toolname should be stable, short, and written without spaces. The safest approach is to use snake_case:

example.txt

search_products
subscribe_newsletter
send_contact_message
request_appointment
request_quote

Avoid names like:

example.txt

form1
contact
new-form-2026
superLeadMagnet

tooldescription should contain one specific sentence. A good sentence answers three questions: what the form does, for whom or what, and what data is required.

Bad:

example.html

tooldescription="Contact form"

Better:

example.html

tooldescription="Send a customer support message. Required fields: customer
name, email address, and message."

Implementation Checklist

Implementation Checklist · 0/18 done

List all forms on the site.
Select the 5 most important: search, newsletter, contact, booking, quote.
Ensure each form is a true `<form>` tag.
Add a unique `toolname` to each important form.
Add a specific `tooldescription` to each important form.
Use snake_case for `toolname`.
Do not use the same tool name twice on one page.
Check that each field has a sensible `name` attribute.
Add `required` where the field is truly necessary.
Add correct types: `email`, `search`, `date`, `time`, `number`, `tel`.
Add `min`, `max`, `minlength`, `maxlength`, or `pattern` if constraints matter.
Add `toolparamdescription` to fields where the name may be unclear.
Do not add `toolautosubmit` to newsletters, bookings, payments, or consents.
Leave a visible submit button for the user.
Check that the form still functions normally for humans.
Run an audit on `auditai.cc`.
Check HTML after implementation, not just the CMS editor.
Document the list of used tool names on the site.

7-day Mini Plan

Identify all forms and record them in a table: URL, purpose, fields, business owner.
Mark the product or service search.
Mark the contact form and correct field names like `msg`, `tel1`, `form-email`.
Mark the newsletter, but without `toolautosubmit`, and check marketing consent.
Mark the booking or quote form, depending on which produces more inquiries.
Test forms on mobile and in the HTML code of the site after implementation.
Run [Audit AI](https://auditai.cc), check the declarative WebMCP checkpoint, and save the before/after results.

Common Mistakes

Attributes on a div instead of the form

example.html

<div toolname="search_products" tooldescription="Search products">
  <form action="/search">
    <input name="q" />
  </form>
</div>

Better version:

example.html

<form
  action="/search"
  toolname="search_products"
  tooldescription="Search products in the catalog by name, category, or SKU."
>
  <input name="q" />
</form>

Fields without `name`

example.html

<input id="email" type="email" required />

Such a field may look fine, but the schema for the form may overlook it. Add `name`:

example.html

<input id="email" name="email" type="email" required />

Too vague a description

example.html

<form toolname="contact" tooldescription="Contact us"></form>

Better version:

example.html

<form
  toolname="send_contact_message"
  tooldescription="Send a customer support message. Required fields: customer name, email address, and message."
></form>

Autosubmit on consent or payment

example.html

<form
  toolname="subscribe_newsletter"
  tooldescription="Subscribe to newsletter"
  toolautosubmit
></form>

Do not do this for consents, payments, bookings, or sensitive data. It’s safer to leave the final click to the user.

How to Measure Effects

First signal: Audit AI detects declarative WebMCP and shows tool names.

Second signal: after changing the HTML, it still works for humans, meaning the form submits data as before.

Third signal: form descriptions are understandable without looking at the layout. If you show someone just the <form> tag, they should know its purpose.

Fourth signal: in a manual audit, there are no forms with toolname without tooldescription, fields without name, and duplicate names.

Fifth signal: when testing in an environment supporting WebMCP, tools appear as separate actions rather than as unlabeled fields.

For Whom This Advice is Not Suitable

Do not start with WebMCP if the forms on the site do not work for regular users. First, fix submissions, validations, consents, and server-side errors.

Do not implement toolautosubmit if you do not understand the legal and UX implications. For newsletters, bookings, payments, sign-ups for consultations, and medical data, the user should have clear confirmation.

Do not treat WebMCP as a substitute for accessibility. Labels, aria-label, correct field types, and readable form errors are still needed.

Do not promise management "immediate sales with AI agents." This is a stage of preparing the infrastructure. The business impact will depend on the adoption of browsers, agents, and the overall quality of the site.

FAQ

Does declarative WebMCP work without JavaScript?

Yes, in terms of implementation on the site: you add attributes to the existing HTML form. This does not mean that every browser and every agent will utilize these attributes right away. WebMCP is still experimental.

Do I need to add `toolparamdescription` to every field?

Not necessarily. If a field has a good label, correct type, and sensible `name`, the agent already has a lot of information. Add `toolparamdescription` where the field name is abbreviated, industry-specific, or unclear.

Should `toolname` be in Polish or English?

It’s safest to use short names in English in snake_case, such as `search_products` or `request_quote`. The description can be in English or Polish, but for technical compatibility and agent functionality, it’s better to keep descriptions simple and unambiguous.

Can I mark the cart declaratively?

If the cart is a regular form, you can add attributes. If the cart operates dynamically in JavaScript, changes the state of the application, and relies on the logged-in user, the imperative version via `navigator.modelContext.registerTool()` may be better. This is a separate, more complex stage.

Will Audit AI check these attributes?

Yes. The local checkpoint for declarative WebMCP in Audit AI looks for `toolname` and `tooldescription` in the HTML. After implementation, you can run an audit and check if the tools are detected.

Summary

Declarative WebMCP is the simplest first step toward an AI-ready site. It does not require rewriting the store, server MCP, or JavaScript. Just start with forms that are already generating leads or revenue.

Mark search, contact, newsletter, booking, and quote forms. Then check the results on auditai.cc before moving on to more complex integrations.

Sources

WebMCP Draft Community Group Report, Web Machine Learning Community Groupwebmachinelearning.github.io/webmcp Chrome Developers, WebMCP is available for early previewdeveloper.chrome.com/blog/webmcp-epp Chrome Developers, When to use WebMCP and MCPdeveloper.chrome.com/blog/webmcp-mcp-usage MCPcat, WebMCP Declarative API: HTML Form Toolsmcpcat.io/guides/declarative-webmcp-tools-html-form-attributes Puppeteer, WebMCP guidepptr.dev/guides/webmcp

Declarative WebMCP in Practice: 5 Forms You Must Mark Today

Key takeaways

Why This is Important in 2026

How WebMCP Differs from a Regular Form

Step by Step: 5 Forms to Mark

Table: Which Forms to Mark First

Naming Conventions

Implementation Checklist

7-day Mini Plan

Common Mistakes

How to Measure Effects

For Whom This Advice is Not Suitable

FAQ

Summary

Sources

Check whether AI cites your site

Key takeaways

Why This is Important in 2026

How WebMCP Differs from a Regular Form

Step by Step: 5 Forms to Mark

Table: Which Forms to Mark First

Naming Conventions

Implementation Checklist

7-day Mini Plan

Common Mistakes

How to Measure Effects

For Whom This Advice is Not Suitable

FAQ

Summary

Sources

Related articles

Check whether AI cites your site