SiteWorks-WebMCP

Inspiration

In 2004 I built my own e-commerce platform, and I've run it and its successors ever since — over 30,000 stores at peak. In all that time, one thing never got easier: getting a real merchant's products into a store. The industry's answer is still "upload a correctly formatted CSV." The merchant's actual data is a flyer taped to the counter glass, a price list the printer was sent, a Word doc from 2019. I've watched merchants stall on that gap for two decades, thirty thousand ecom sites worth.

When OpenAI shipped Site tools on August 25th, I saw the fix for the first time: don't build another bundled chatbot — make the admin page itself the tool surface, and let the merchant's own agent do the work. Storefront-side WebMCP already existed (Shopify ships it on every Liquid storefront; Chrome's official demos are shops). The admin — where the store gets made — had none. This is that half.

What it does

SiteWorks is a production site builder. During the Submission Period I added a WebMCP layer: the signed-in editor page registers 55 tools (19 read, 33 write, 3 skills) via document.modelContext.registerTool. The merchant's ChatGPT photographs the counter menu and drafts every item into the live store — reading the catalogue first, matching existing products instead of duplicating them, and flagging unpriced or ambiguous items for review instead of inventing numbers. The warnings live on the drafts, not in the chat. Then the same tools run outbound: export the catalogue and brand system, generate a printable flyer, inspect the result.

Everything is draft-first with optimistic concurrency, an audit row per call, and one structural rule: nothing the agent can call publishes a page or a product. Publish isn't a guideline the model follows — it's a call that doesn't exist. The human holds the only commit button.

How we built it

On a real platform, which meant the hard part wasn't the tools — it was the boundary. One operations layer already served the human UI; WebMCP became a second caller of the same layer, and a server-side MCP endpoint a third. For the open-source release I extracted a standalone demo (SQLite, one container, a fictional bakery) that runs the identical layer, with prior work delineated in docs/PROVENANCE.md — the platform predates the contest; every WebMCP line postdates August 25th, and git grep at the cut-off commit proves it.

Challenges we ran into Tools inside iframes aren't discovered. Our editor is a parent shell around a sandboxed preview — registration had to live on the parent, proxying into the preview. tools.call() can't return a file. Exports return a signed URL plus SHA-256 and expiry instead; the artefact rides the browser, the facts ride the tool result. Real defects, found by agent testing. A hero image/video conflict and a broken version-listing endpoint surfaced only when an agent actually drove the surface — both fixed, with the evidence baked into the tool contracts. Facts vs. decoration. Image models corrupt small text, so generated imagery decorates while names and prices bind from catalogue data. And the platform outage on deadline day, mid-render. Thanks for the extension. What we learned

An agent doesn't need your platform to be smart — it needs it to be legible and governable. The intelligence is the user's; the structure is the site's. Twenty years of merchant onboarding pain turned out to be an interface problem: design the tool surface so the model's worst day is a review queue, not a live store, and everything else follows.

What's next for SiteWorks WebMCP

Shopper-side tools on the published storefronts (mirroring Shopify's vocabulary, so one platform carries both halves), deterministic flyer rendering so campaign artwork binds from the catalogue like everything else, and the same agent-native admin rolled out across the production estate — a thousand-plus small-business sites whose owners will never learn a page builder, but already know how to talk to ChatGPT.