Stickybit.← E-commercePortuguêsAnalysis · WebMCP · 2026
WebMCP · the store’s socket for agents

Today the agent clicks through your store. Soon it will call functions.

To buy something, an AI assistant today takes a screenshot, reads the page’s code and imitates clicks: expensive, slow and it breaks when the layout changes. WebMCP lets the store offer sockets, ready-made functions such as search, check shipping, reserve and place the order, that the agent uses directly. You decide what stays on.

See what an agent can do in my store
Specimen · switch the store’s sockets on and off

The customer’s request to the assistant: "a pedestal fan under R$ 300, delivered by Friday to my postcode"

    0actions imitating a person
    0direct calls
    0points that break with the layout
    0human gates

    Illustrative: the sockets, the store and the request are an example. The counts of on-screen actions are a typical script, not a measurement; the real saving in cost and stability depends on the store and the agent.

    In everyday life

    Searching the stockroom alone or asking at the counter.

    Picture a store where the customer has to walk into the stockroom and find the product alone, eyes almost shut, feeling shelf by shelf. It works, but it is slow, and moving one aisle is enough to get them lost. That is how an AI assistant shops today: it takes a screenshot, reads the code of the whole page, guesses where the button is and clicks.

    The other way is the counter: the store has a menu of what the clerk can fetch, and the customer just asks. WebMCP is that counter for agents. The store itself declares the functions an agent may use, with a name and a description, and the agent calls the function instead of imitating a person.

    We call these functions sockets: a standard fitting, the same for any agent, that the store switches on or off.

    TODAY · SEARCHING THE SHELVES ALONE screenshot → read the code → click → and what if the aisle moved? WITH THE SOCKET · ASKING AT THE COUNTER store menu buscar() · frete() reservar() · fechar()* 1 request, 1 answer * only what you allowed
    On top, today’s agent. Below, the agent with the socket: it asks for what the store offers, and only that.
    How it is today

    Screenshot, read, click: four ways to go wrong.

    It costs at every step. Each action forces the agent to look at the whole screen again. In a ten-step purchase that multiplies, and whoever pays the AI bill feels it.

    It breaks when the layout changes. The team moves a button and the automation stops. Fixing it becomes a permanent tax.

    Hidden text can give orders. Third-party content on the page (a comment, an ad) can carry instructions telling the agent to act against the store or the customer.

    Being able to click is not permission. The agent does whatever the screen allows, even without authorization for the business rule behind it. Whoever confuses the two opens a gap.

    Screenshota heavy imageRead the codethe whole pageDecide whereguess the buttonClickand hope!costs per step!hidden instruction!layout changed!click ≠ permissionRepeat this at every step, in every store, after every layout change.It is today’s way. It works, but every red dot is a cost or a gap.
    Today’s path. Each red dot is cost, fragility or a gap.
    How it works with the socket

    The store declares what the agent may ask for.

    There are two ways to open a socket. In the simplest, the store marks a form that already exists, such as search or postcode, with a name and a description, and the agent starts using it as a function. In the other, the site registers a function in the page’s own code. Neither requires rebuilding the site.

    The standard also brings safety hints: marking content as "untrusted" and a function as "read-only". They help, but they are a patch: the layer that lets the agent act arrived before the layer that governs what it may do.

    Chrome 149opened WebMCP as a public trial (announced at Google I/O 2026)
    1 switchin the Cloudflare dashboard turns WebMCP on for any site, in preview (Aug 2026)
    2 hintsin the standard: untrusted content and read-only function
    in trialthe standard may still change before it becomes official
    The care you cannot skip

    Clicking is not permission. The store decides.

    Every socket that touches money or personal data goes through three locks: the store’s rules on the server (value cap, stock, fraud check), a human confirmation gate for anything irreversible, and a log of each step.

    The rule we take from real 2026 incidents: everything the agent reads is suspect, and the gate that matters is the exit. Trying to clean everything that comes in does not work; it is safer to control what the agent can close, pay for or send out.

    Sheet for each socket

    Name and what it doesclear
    Who may call itidentified agent
    Limitvalue and quantity
    Human confirmationif irreversible
    Logevery call
    Customer passwordnever
    Agent fechar() Store rules ✓ value cap ✓ in stock ✓ fraud check Gate OK? Order exists a log of each step: who asked, what the rule said, who confirmed BEING ABLE TO CLICK IS NOT PERMISSION The decision stays on the store’s server, never on the screen or in the agent.
    The order only exists after the store’s rules and the customer’s tap. The agent proposes; the decision sits outside it.
    Both sides

    Your store receives agents. Your robots visit other stores.

    In your store (receiving)

    • Open read-only first: catalog, price, stock, shipping, order status.
    • Then what reserves: cart, with a short expiry.
    • Last, what charges: place the order, always with a confirmation gate and a cap.
    • Make yourself findable: a public catalog of your sockets helps agents find you; being found is not being trusted.

    In your automations (visiting)

    • Use the socket where it exists: and fall back to reading the screen where it does not.
    • Isolate the method: a layer in the middle turns the switch into an upgrade, not a rewrite.
    • Measure cost per action: screen versus direct call, on your own workload.
    • Treat the page as hostile: read, never obey.
    Three words on this page
    Socket (WebMCP)

    A function the store declares for agents to use directly, with a name and a description, instead of the agent imitating clicks.

    Confirmation gate

    The step where a person approves anything irreversible, such as paying. The agent proposes; the person confirms.

    Hidden instruction

    Text on the page, invisible or disguised, that tries to give the agent orders. That is why it reads but does not obey.

    All the section’s words, explained →

    Limits

    Where this may be wrong.

    The standard is still on trial

    WebMCP is in public trial in Chrome and in preview at Cloudflare. Names, formats and rules may change before it becomes official. That is why we recommend the layer in the middle, which absorbs the change.

    We did not measure the gain

    Calling a function costs far less than reading the whole screen, but we have no number we measured for Brazilian stores. The specimen counts actions, not cost.

    Few agents use it today

    Opening the socket does not bring traffic by itself. It pays off when the assistants your customers use start looking for it.

    Security is behind

    The standard’s safety hints are stopgaps. Real protection is still the rule on the server, the human gate and the log.

    See also
    AnalysisAgentic web · two customersThe same page read by a person, a search engine and a shopping assistant.
    CaseTOTVS proxy on Black FridayA layer in the middle that held the peak without rebuilding the system.
    Free readingYour store as the agent sees itWithin 24 hours, with evidence for each item.

    ← Agent-ready e-commerce · stickybit.com.br

    Sources