OpenAI’s WebMCP Challenge closes today, September 3, and the interesting part isn’t the hackathon; it’s the product boundary the experiment exposes.
WebMCP is an experimental open standard that lets a website publish structured tools for agents to call directly. Instead of inferring that a blue rectangle labeled “Refund” is clickable and navigating screens like a slightly caffeinated intern, an agent can call a typed refund action with defined inputs.
That sounds like developer plumbing. For product teams, though, it creates a second interface contract sitting beside the human one.
A button and a tool are different promises
Human interfaces tolerate ambiguity because people carry context: we read labels, notice disabled states, infer consequences from surrounding copy, and stop when something looks strange. An agent-facing tool needs more explicit boundaries around valid inputs, permissions, side effects, retry behavior, and what “success” actually means.
Those questions already exist in good API design, but WebMCP moves them into products that may never have considered themselves developer platforms. A travel site, retailer, support portal, or project-management app can expose structured actions without first turning its whole backend into a public API.
The temptation will be to toolify every button. That’s product-manager-y in the bad way.
A useful agent tool should represent a durable user intent rather than a DOM shortcut or whatever control happens to be visible today. “Return order” is a product capability; “click the third button in the order card” is presentation wearing an API costume. If the website gets redesigned next quarter, the first contract can survive while the second deserves to break.
This resembles my earlier argument about developer platforms hiding internal architecture, except the consumer is software acting for a customer rather than a developer integrating a system.
Design the refusal path too
OpenAI describes WebMCP as a way to define exactly how agents can use an app, improving speed, accuracy, and reliability. The more interesting product work starts where “exactly” gets uncomfortable, especially for actions that change money, access, ownership, or customer data.
Consider a refund tool whose human interface appears only when an order is eligible, with policy text nearby and a confirmation dialog afterward. An agent needs equivalent constraints somewhere in the tool contract or server behavior, or the structured interface becomes easier to invoke while being harder to reason about.
I’d review agent-facing actions with four questions: what can the agent read, what can it change, when must a human confirm, and what evidence comes back after execution. That last question matters because “success” isn’t enough for consequential actions; users may need a receipt, transaction identifier, changed state, or specific reason for refusal.
There is a reasonable counterargument: WebMCP remains experimental, and Chrome support currently requires an experimental flag or origin trial. Product teams shouldn’t redesign mature workflows around a standard that may change, particularly when browser and agent behavior are still moving quickly.
Agreed. The useful exercise doesn’t require betting the roadmap on WebMCP or adding another protocol to next quarter’s architecture plan.
Take the five highest-value jobs in your web product and ask whether each has a stable, machine-readable action underneath the pixels. If defining one feels surprisingly difficult, the problem may be older than agents: permissions are fuzzy, side effects aren’t explicit, or the UI has been carrying business rules that never became a clean product contract.
Agents may become another customer of the interface. They shouldn’t inherit every button.
Comments
Comments are powered by GitHub Discussions through Giscus.