An AI agent should not need a secret back door into your app.
It should not update one database record while your visible interface updates another. It should not skip the validation your form uses. It should not report “done” while the screen still shows the old state.
That sounds obvious. It is also the kind of mistake you can create in one enthusiastic afternoon by adding an agent tool beside an existing website.
I did not find a development in the previous 24 hours that supported a substantial new beginner lesson without repeating recent coverage, so I widened the search window to seven days. On August 25, 2026, OpenAI opened the WebMCP Challenge, a ten-day build event supported by Google Chrome, Cloudflare, Shopify, Vercel, Render, and Netlify. OpenAI describes WebMCP as an experimental open standard that lets a site expose structured tools an agent can use directly.
On August 26, Google’s Chrome team published new guidance for designing WebMCP workflows. The advice begins with the user’s goal, initial state, boundaries, conversation, recovery paths, and evaluations—not with “register every button as a tool.”
That order is the important part.
The durable beginner lesson is not that every website needs WebMCP this weekend. It is this:
Build one product action, then give the human interface and the agent interface two honest ways to invoke it.
I call this the one-action, two-interface rule.
Most browser agents have had to understand websites through the interface made for people: text, buttons, forms, screenshots, scrolling, and page state. That can work, but the agent has to infer what a control means and how the pieces fit together.
Chrome’s WebMCP overview describes a more structured path. A site registers a tool with a name, description, and input schema. The browser exposes that contract to a compatible agent. The agent supplies structured arguments, and the site’s own code executes the action while the user remains involved for permission and confirmation.
WebMCP also has two broad implementation paths. The imperative API can register JavaScript functions as tools. The declarative API can annotate standard HTML forms so the browser can represent the form as a tool.
Cloudflare has already demonstrated another direction. Its developer preview can add a WebMCP bridge at the edge, including tool packs that work without changing the origin application code.
This is meaningful because it can replace a brittle tour of the screen with a named product contract.
But a named contract can still be badly designed.
If the visible “Create project” form and the agent’s createProject
tool contain different rules, you now own two products wearing one logo.
If you are still defining the first useful workflow, my AI App Builder Starter Prompts are free. Use them to name the user, outcome, inputs, exclusions, and proof before deciding whether that workflow deserves an agent-facing tool.
The tempting implementation is a button inventory:
Save
into saveThing
;Delete
into deleteThing
;Send
into sendThing
;Buttons are not the architecture.
A button may begin a workflow, but the real product action includes the signed-in user, current record, allowed transition, validated input, side effects, result, and failure state.
For example, “send invoice” is not merely a click. The invoice may need an owner, recipient, line items, total, valid status, delivery method, and confirmation. The action may create a timestamp, write an audit event, send a message, and update what the user sees.
If the human interface enforces those rules but the agent tool calls a shortcut, the tool is not an alternate interface. It is an alternate business system.
That is the mess to prevent.
Start with what the user is trying to accomplish.
Weak tool:
clickPrimaryButton
Better tool:
createInvoiceDraft
The second name survives a redesign. It also tells the agent and the developer what the action is responsible for.
Write one sentence:
Given [starting state] and [required input], the user can [product outcome], producing [visible result].
If the sentence describes moving around the interface instead of changing or retrieving meaningful product state, you may not have found the right tool boundary yet.
Before adding an agent path, complete the action as a person.
Record:
This is not busywork. It is your current product contract, whether or not anyone wrote it down.
Chrome’s August 26 guidance recommends defining the user goal and initial state, then role-playing the conversation turn by turn. That is useful because an agent request may begin with less information than the form requires. “Make me an invoice for Acme” still needs line items, amounts, and perhaps a due date. The tool should help the agent identify the missing input, not make up business facts.
Both interfaces should call the same product-level function.
Conceptually:
Human form ─┐
├─> createInvoiceDraft(input, actor) ─> result
Agent tool ─┘
The exact files depend on your stack. The principle does not.
Do not put critical business rules only inside the React component, form click handler, or WebMCP callback. Move the action into a shared layer with a clear input and result. Then let each interface translate its own interaction into that contract.
This does not mean the human screen and agent chat must look alike. It means they agree on what happened.
The shared action should decide whether the operation is valid.
Check at least:
The interface may provide earlier, friendlier guidance. The human form can highlight a missing date. The agent can ask the user which date they mean. But both paths must meet the same final gate.
An agent description that says “only use this on your own invoices” is not authorization. The domain action must enforce ownership.
“Success” is too vague.
Return a structured result such as:
status: created
invoiceId: inv_204
revision: 1
total: 480.00
nextAllowedActions: edit, preview, send
The agent can explain that result. The screen can navigate to the same invoice and show the same values. Your logs can attach the same action ID.
The free AI App Builder Starter Prompts can help you define the workflow and its done-when proof. They are free; for this checklist, turn that proof into a structured result both interfaces can inspect.
If the agent claims success but the visible app cannot display the resulting object, treat the action as unverified.
Chrome’s guide says a tool should return context-aware recovery guidance instead of a generic error, raw API failure, or silence.
That same discipline should benefit the human interface.
Instead of:
Something went wrong.
Return:
Invoice inv_204 cannot be sent because it has no recipient email. Add a recipient, then try again.
The screen can show the message near the relevant field. The agent can ask the user for the missing information. The shared action remains the source of truth.
Separate recoverable failure from forbidden action. Missing information may invite another attempt. Failed ownership should stop the operation. A shipped order should not become cancellable because an agent phrased the request more confidently.
Use the same fixtures against both interfaces.
Test at least five cases:
Then compare the evidence:
The wording can differ. The truth cannot.
Copy this into your project before you register an agent tool:
| Question | Decision |
|---|---|
| User outcome | What useful job finishes? |
| Starting state | What page, record, identity, and context exist first? |
| Required input | Which values must the user or agent supply? |
| Shared action | Which one function owns the business operation? |
| Validation | Which rules apply to both paths? |
| Permission | Which identity may act on which resource? |
| Transition | Which current states may become which next states? |
| Result | Which ID, values, and next actions prove success? |
| Failure | Which errors are recoverable, and which must stop? |
| Parity proof | How do the human and agent paths prove the same truth? |
If you need two different answers in the last five rows, you may be building two implementations instead of two interfaces.
Shared actions are not free.
You may have to pull logic out of a convenient UI component. Old forms may contain hidden assumptions. A long workflow may need several smaller tools instead of one enormous call. Some human experiences rely on visual comparison or creative judgment that does not translate cleanly into structured arguments.
WebMCP itself is also experimental. Chrome’s documentation says the API remains under active discussion and may change. Browser support, tool behavior, security guidance, and integration details can move while the standard develops.
That is a reason to keep the boundary narrow.
Do not rewrite your whole product around one experimental interface. Start with one stable, valuable action whose logic already deserves to exist outside the screen. Put the WebMCP-specific registration at the edge of your architecture so the product action remains useful even if the browser API changes.
And do not expose every capability merely because you can. Reading a filtered list may be a good first tool. Deleting an account is a terrible first experiment.
Pick one action users already complete successfully on your website.
Write its one-action, two-interface contract. Move the final validation and state change into one shared function. Keep the existing human UI working. Then add one agent-facing wrapper and run the five parity tests.
Do not begin with a demo that only proves the agent can call JavaScript. Prove that a person and an agent can reach the same product truth through different interfaces.
For the immediate guided action, use my AI App Builder Starter Prompts, which are free. They help you define the user, workflow, inputs, constraints, data, and QA proof before you expose the action.
If you want the organized path from idea to publication, AI App Builder From Zero is my $19 field manual covering idea generation, scope, stack choice, prompting, architecture, QA, deployment, App Store, Google Play, and launch.
WebMCP may change how agents interact with a website. It does not change the beginner obligation underneath it.
One product action. Two interfaces. One version of the truth.
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
LinkedIn: https://www.linkedin.com/in/marcusykim/