Reloop WebMCP

A WebMCP reference implementation for trustworthy AI commerce: agents search, compare and reserve one-of-one inventory with human approval.

Comment

Inspiration

Reloop started with a very ordinary recommerce problem: second-hand inventory is messy.

Listing one item is easy. Listing many is slow. Every garment needs identification, sizing, condition assessment, pricing, descriptions, images and publishing. The buyer side is just as messy: every item is one-of-one, sizing varies, condition is subjective, defects matter, and once an item is gone, it is gone.

That makes recommerce a strong test case for agentic shopping. A buyer may not want to click through filters. They may simply ask:

Find me a genuine black leather jacket around UK size 10, in excellent condition, under R1,200. Avoid faux leather and obvious defects.

A normal storefront struggles with that kind of intent. A browser automation agent can try to infer meaning from the page, but it is still guessing from a human UI.

Reloop asks a different question:

What if commerce applications exposed trusted, page-defined capabilities directly to AI agents while still requiring explicit human approval for consequential actions?

For the WebMCP Challenge, we built a focused public implementation of that idea.

What it does

Reloop is a reference implementation for trustworthy AI commerce using WebMCP.

It demonstrates a complete human-agent commerce flow:

  1. The agent discovers the tools exposed by the page.
  2. The user describes what they want in natural language.
  3. The agent searches deterministic one-of-one inventory.
  4. It inspects item details such as material, size, condition, price, defects and availability.
  5. It compares candidates and recommends the best match with supporting evidence.
  6. The human explicitly approves the exact item in natural language.
  7. Only then can the write-path reservation tool change demo state.
  8. The storefront updates visibly.

The demo is intentionally narrow: a recommerce storefront with synthetic inventory. The underlying pattern is broader: read and reasoning actions can be agent-friendly, while write actions remain application-controlled and human-approved.

Why WebMCP is a strong fit

Most AI web interactions still depend on fragile patterns:

  • the agent reads arbitrary HTML and guesses what the page means
  • the agent clicks through a UI designed for humans
  • the app has little control over which actions are safe or intended

WebMCP changes the boundary.

In Reloop, the page explicitly registers meaningful commerce capabilities. The agent does not need to scrape the storefront or invent a workflow. It discovers tools that represent the actual tasks a buyer needs:

  • search_inventory
  • inspect_item
  • find_best_match
  • compare_items
  • recommend_alternatives
  • reserve_item

Those tools are not generic database operations. They are application-level capabilities that map to shopping intent.

That is why WebMCP matters here: it lets the website describe what an agent can do, while the application keeps authority over business logic, validation and state changes.

Better user experience

For the human, Reloop turns a messy search into a guided conversation.

Instead of filtering by imperfect categories, the user can describe the outcome they want. The agent can then do the tedious work: search, inspect, compare, eliminate poor matches and explain why one item is the strongest choice.

For the agent, the experience is also better. It receives structured tool responses rather than trying to interpret visual layout, DOM fragments or arbitrary copy.

For the application, the experience is safer. The app decides which capabilities exist, how inputs are validated, what evidence is returned, and when a write action is allowed.

The result is not autonomous shopping for its own sake. It is a collaboration:

the agent reasons, the application enforces, and the human decides.

What people and agents can do together now

Reloop shows a workflow that is difficult to do well with a normal storefront alone:

  • express nuanced buyer intent in natural language
  • evaluate one-of-one inventory with inconsistent attributes
  • compare items on fit, condition, material, price and defects
  • preserve the evidence behind a recommendation
  • keep the human in control of irreversible actions
  • update application state only after explicit approval

That last point matters.

The agent is allowed to search, inspect, compare and recommend freely. But reservation is different. reserve_item is the write path, so it requires explicit natural-language approval for the exact SKU in the tool request. A vague instruction such as “Reserve RL-001” is rejected. Approval language such as “I approve RL-001. Please reserve RL-001 for me.” allows the reservation only if the item exists and is still available.

The live deployment has been retested with this boundary: “Reserve RL-001.” returns an approval-required response without changing state. “I approve RL-001. Please reserve RL-001 for me.” succeeds and changes the storefront from 23 → 22 available with RL-001 AVAILABLE → RESERVED.

How we implemented WebMCP

The public challenge repository contains a focused Next.js implementation of the WebMCP layer.

The demo registers six Reloop Site Tools using document.modelContext.registerTool(...). Each tool exposes a specific commerce capability to the client. The matching and reservation logic remains separate from the protocol boundary so the WebMCP layer acts as the agent-facing interface, not the entire application.

The implementation includes:

  • a Next.js demo shell
  • deterministic synthetic inventory
  • recommerce matching and reservation logic
  • WebMCP tool registration
  • explicit approval validation for the write-path reservation tool
  • a human-visible storefront state
  • focused tests and verification commands
  • an AGPLv3 open-source license

The repository README documents the architecture, tool flow, human approval boundary, local setup and verification path.

Challenges we ran into

The hardest design challenge was deciding what the tools should represent.

It would have been easy to expose low-level CRUD functions, but that would not show the real promise of WebMCP. We wanted the agent to work with commerce intent, not database plumbing.

The second challenge was trust.

A shopping assistant that can reserve items without the user’s clear approval is not a better experience. It is just a faster way to make mistakes. We deliberately separated read/reasoning actions from write actions so the agent can help without silently committing the user to an outcome.

The final approval-boundary fix was important: the first implementation used a visible storefront approval gate. The stronger version now validates explicit natural-language approval for the exact SKU inside the reserve_item tool request itself. That keeps the agent-commerce UX conversational while still making the safety boundary application-enforced.

The third challenge was scope.

Reloop could become a much larger product, but this challenge needed a tight, inspectable implementation. We chose a deterministic synthetic storefront so judges can reproduce the same flow, evaluate the WebMCP behavior, and inspect the code without relying on private systems or real customer data.

Accomplishments that we’re proud of

We are proud that Reloop is more than a technical proof of concept.

It demonstrates a coherent product experience:

  • live hosted demo
  • public open-source repository
  • discoverable WebMCP tools
  • natural-language shopping flow
  • evidence-based recommendation
  • comparison against alternatives
  • explicit natural-language approval for the exact SKU
  • application-enforced write boundary
  • visible state change in the storefront
  • deterministic data and verification commands

Most importantly, it shows a reusable pattern for agentic commerce: applications can expose structured capabilities to agents without giving up control of safety-critical actions.

What we learned

The biggest learning was that preparing inventory for AI-assisted selling also prepares it for AI-assisted buying.

Structured item data is useful twice:

  1. It helps sellers turn messy physical inventory into usable listings.
  2. It helps buyer agents reason over unique items with evidence.

WebMCP made that second half more concrete. Instead of treating a website as a surface to be scraped, we could treat it as an intentional collaboration layer between the human, the agent and the application.

We also learned that the most interesting part of agentic commerce is not the final transaction. It is the trust boundary before the transaction: the agent can help the user reach a decision, but the application must enforce what counts as explicit approval before changing state.

What’s next for Reloop

The challenge implementation is intentionally scoped, but the pattern can extend far beyond this demo.

The same architecture could apply to:

  • recommerce marketplaces
  • rentals
  • ticketing
  • bookings
  • travel
  • procurement
  • other approval-sensitive workflows

The next step would be connecting the agent-facing shopping layer to the broader Reloop seller workflow, so newly processed second-hand inventory can become discoverable by both humans and agents.

Longer term, Reloop points toward a version of the web where agent accessibility is not retrofitted through scraping or browser automation, but designed directly into the application.

Reloop is one-of-one commerce, ready for people and their agents.

Built With

Share this project:

Updates

Submission history