The project-brief planner on this site takes three inputs: an application name, a workflow, and the outcome a customer should be able to achieve. It turns those into a draft scope for a WebMCP pilot.
You can fill in the form yourself. In a browser that supports WebMCP, an agent can prepare that same brief. The form and the output update together, and you can edit the result before downloading it or opening an email draft.
I built this as a small example of the integration work I’m offering. The suggestions are predefined templates for four workflows. The planner itself doesn’t call a model, inspect your application, or estimate a price.
Start with an action someone can use
An agent needs to know what the application can do. In this case, that’s preparing a brief. Exposing every field as a separate tool would make the agent reconstruct the form one operation at a time.
The planner has three tools:
| Tool | Purpose |
|---|---|
get_pilot_options | List workflows, example outcomes, and review boundaries. |
prepare_pilot_brief | Validate all three inputs, update the form, and prepare a visible draft. |
get_pilot_brief | Read the prepared draft and report whether the form contains unprepared edits. |
That last detail matters. A visitor might change the application name after an agent prepared the brief. Reading the last prepared result shouldn’t imply those new edits were included. The interface also disables the sharing links until the visitor prepares the edited brief.
Keep one implementation behind both interfaces
The form and the agent call the same brief builder. It checks the application name and desired outcome, accepts only the four supported workflows, and returns the suggested scope. All validation finishes before the page changes.
If an agent passes an unknown workflow or an oversized string, the operation fails without replacing the existing draft. An HTML form’s input limits alone wouldn’t protect this path: a tool callback receives its own arguments.
The result is rendered as text. Application names and outcomes are user input, so they shouldn’t become HTML. Tool results containing those values also carry the untrusted-content annotation; an agent should treat them as data.
Register tools for the lifetime of the page
The current imperative API registers tools through document.modelContext. Registration accepts an abort signal for removing them later. The exact API matters here because WebMCP is still changing; older examples may use a different interface. Chrome’s imperative API documentation covers the current shape.
This site uses client-side navigation. Leaving the planner doesn’t necessarily unload the browser document, so tools need explicit cleanup when the page changes. Otherwise an agent could discover a tool whose form no longer exists.
Each planner instance owns its registrations. Navigating away aborts them and releases the download URL. Returning creates a fresh planner with fresh registrations.
Registration is a separate concern from the form’s event handlers. If browser policy prevents a tool from registering, the ordinary planner still needs to work.
Make the handoff clear
Preparing a brief has no external effect. It doesn’t create a lead, send a message, or reserve time on my calendar. The draft stays in the page. Downloading creates a local Markdown file; the email link opens a draft for the visitor to review and send.
An agent can still read the text through its tools, so its provider’s data handling applies when you choose to use one. That’s explained next to the form.
A booking or checkout integration would need stronger boundaries: current availability, server-side authorization, and confirmation tied to the actual transaction. A tool annotation can describe a boundary, but application code still has to enforce it.
What this example proves
This is a demonstration of a shared workflow: a person and an agent can use the same application logic and see the same result. The form also works when WebMCP isn’t available.
It isn’t a before-and-after agent benchmark. I haven’t established a task-completion improvement or a token-saving percentage from this planner. That would require repeated tasks with a named agent and model, a baseline, and recorded failures as well as successes.
For a client pilot, I’d agree on that task set first. Then measure correct completion, elapsed time, and human corrections with and without the integration. A faster answer is useful only when the resulting booking, configuration, or report is right.
You can try the planner, read how I choose between WebMCP and an MCP server, or discuss a scoped pilot.