SuperWeb

Inspiration

Last semester ended and everyone went home. Before the group scattered I wanted a real camera to take proper photos of them, under $200, decent in low light, small enough that I would actually carry it. I said those requirements out loud in about eight seconds. Finding the camera took a night of tabs, filter dropdowns and reviews that all say the same thing.

That gap bothered me. I already knew what I wanted. The work was not deciding, it was operating a website. Amazon has more than 10,000 products in that category and half of them are the same thing with a different logo.

Agents are supposed to help with this, and mostly they do it by pretending to be a person. They read pixels, guess which button is the search box, click, wait, re-read. That works until the layout changes. It felt backwards to us. The site already knows what it can do. It should say so.

What it does

SuperWeb is a shopping app with two front doors into the same building.

A person uses the normal React interface. An agent comes in through WebMCP. Both talk to the same application state and the same APIs, so the two views never disagree.

When ChatGPT calls search_products, it is not hunting for a button. The page declares that capability with a name, a description and an input schema. The tool runs, the catalog filters, and a human watching the screen sees the same change happen live. Same for filter_catalog, compare_products, manage_cart and the rest of the tools the page exposes.

We also built a staff dashboard side with tools like get_metrics, breakdown_metrics, check_data_trust and start_report, because the shopping case is the fun demo but the boring case is the valuable one.

How we built it

The app is a React front end deployed on Vercel. The WebMCP layer sits alongside the UI and registers tools against the same state the components read from, which is the whole point. There is no second code path for the agent, no headless copy of the app, no scraping surface to maintain. A tool handler calls the same function a button calls.

Each tool declares three things. A name the model can reason about. A description written for a reader who cannot see the page. An input schema that rejects bad arguments before anything runs.

The demo film was cut in CapCut. Narration is text to speech, the guitar under the opening and the credits is a cover I recorded of 离开我的依赖 by 王艳薇.

Challenges we ran into

Photos cannot travel through the tool call. This is the one that actually stopped us. Structured data moves through WebMCP fine. A user's photo does not. If I want to say "find me something that looks like this", there is no path for the image today. Multimodal input through WebMCP is unsolved and we could not work around it, only describe it honestly.

Exposing tools is easy. Explaining how they fit together is not. We got each individual capability declared quickly. Then we watched the model call them in an order that made no sense, because nothing in the schema says check_data_trust should come before start_report. A tool list is a vocabulary. It is not a grammar. We do not have a good answer for this yet, and I suspect it is the real open problem in this space.

Writing descriptions for something with no eyes. Our first tool descriptions were written like code comments, for a developer who can see the page. They were useless. Rewriting them for a reader with no visual context changed the behaviour more than any prompt engineering did.

Keeping the two views honest. Every time we let the agent path touch state through a shortcut, the UI drifted out of sync. Forcing every tool through the same functions the UI uses was slower to build and removed a whole class of bug.

What we learned

The interesting shift is not shopping. It is routine knowledge work. A manager asks why November revenue changed. Today that is searching dashboards, filtering data, checking quality, tracing anomalies and writing it up, and most of that is operating software rather than thinking. That part can move. The goal, the constraints, the exceptions and the final approval stay with the person, and should.

We also learned that the demo has to show the site doing something. An agent typing in a chat panel proves nothing. The moment that convinced people was watching the catalog filter itself while nobody touched the mouse.

What's next

Multimodal input, since that is the hard blocker. Some way to describe workflows and not just tools, which might be as simple as declaring ordering constraints between them. And if WebMCP connects one agent to one website, agent-to-agent protocols across several services are the obvious next question. We have not built that. Building this made it much easier to picture.

Try it: https://webmcp-superweb.vercel.app/

Built by Tan Dat Ta and Huy Doan.