Two ways to expose a form to an agent.

Contact form cf-webmcp injects

This first form has no WebMCP attributes in the origin HTML. The publisher kept their template clean. cf-webmcp stamps the four attributes onto the <form> and onto each <input> at the edge using a [[forms]] block in webmcp.toml. View source on this page to see the injected attributes appear inline on the form below.

What cf-webmcp does: matches the form by CSS selector at request time, sets toolname, tooldescription, optional toolautosubmit, and a toolparamdescription on each declared input. Honours the publisher's hand-stamps if any already exist (does not overwrite).

What cf-webmcp does not do: generate the form, change its layout, alter the submit handler, or hide the form from non-agent visitors. It only adds attributes the browser interprets as a WebMCP tool registration.

Contact form hand-stamped

This second form is identical in shape, but the publisher has stamped the WebMCP attributes directly into the HTML themselves. No TOML block is needed - the browser reads the attributes from origin and registers the tool. This is the path for teams that prefer to manage agent-exposed surfaces from inside their CMS or template.

What cf-webmcp does: nothing extra for this form. It passes the attributes through cleanly along with the rest of the response.

What cf-webmcp does not do: modify or remove the attributes. The publisher owns this form's WebMCP surface end to end.

How to test

You can verify each form three ways:

1. View source on this page. Both forms show their attributes inline. The first form's attributes are stamped by the Worker; the second form's attributes came from origin. Same end result in the HTML.
2. List tools from devtools. Enable chrome://flags/#enable-webmcp-testing and run in the console on this page:

   await navigator.modelContextTesting.listTools()

   Look for contact (from the injected form) and contact_alt (from the hand-stamped form) alongside the imperative tools registered by the cf-webmcp bootstrapper.
3. Invoke one as an agent. Still in devtools:

   await navigator.modelContextTesting.executeTool(
     "contact",
     JSON.stringify({ name: "Ada", email: "ada@example.com", message: "hi" })
   )

   The page's submit handler catches the agent-invoked submission via SubmitEvent.agentInvoked and responds with a canned JSON envelope. Nothing is actually posted to a server - this is a pure demonstration. A real publisher would replace the canned response with their own server-side handling.

What the publisher gets

• Zero JS work to register a form as a tool. The browser parses the attributes during HTML parse and registers the tool automatically. No navigator.modelContext.registerTool call needed; that is for the imperative path.
• Edge-side or origin-side, your choice. Use the TOML [[forms]] block to add WebMCP to existing CMS forms without editing templates. Or hand-stamp the attributes in your HTML if you prefer that control. Both forms above work the same way once rendered.
• Native browser input validation runs first. required, type="email", and friends fire before the tool is invoked. The agent never sees an invalid submission.
• Non-agent visitors see the form unchanged. The four attributes are inert to humans; the form is just a form.
• Agent-invoked submissions are distinguishable. The W3C draft adds SubmitEvent.agentInvoked (read-only boolean) and SubmitEvent.respondWith(promise) so a single submit handler can serve both audiences from one code path.