Restock Room

• 

  Approved decision

• 

  Alert overview

• 

  Replenishment draft

Inspiration

Retail teams do not need an agent that silently buys stock. They need help turning messy operational signals into a clear, reviewable next step. A shelf can be below its reorder point, compatible alternatives can exist, and the decision still belongs to the person responsible for stock and spend.

Restock Room explores that handoff. It gives an agent a narrow, explicit set of capabilities for finding evidence and preparing a proposal, while keeping the normal workspace understandable and the final approval visibly human.

What it does

Restock Room starts with visible low-stock alerts and a visible replenishment policy. A browser agent can read the alert evidence and policy, search the visible synthetic catalog for the affected item and alternatives, and create a replenishment draft or a policy-aware two-alert plan. The operator then reviews every proposed line in the same UI and approves or rejects it.

The draft or plan is intentionally the end of the agent's authority. The multi-alert plan enforces the visible 75% signal-confidence threshold, two-line limit, and $1,800 budget. Approval is a local, auditable UI action only: it never contacts a supplier, creates a cart, submits an order, or handles a payment. All catalog and inventory records in the demo are synthetic.

Why this is a strong WebMCP use case

Without WebMCP, an agent must infer workflows from a page's layout and text, which is brittle for operational work. Restock Room exposes the meaningful actions as structured tools, with stable names, input schemas, and safe outcomes. The agent can work with the same stock alert and catalog information the operator sees instead of guessing which controls or records matter.

That produces a better joint experience: the agent reduces the research and proposal work, while the human retains context, discretion, and final control. The normal UI remains fully usable even if WebMCP is unavailable, so agent support enhances the workspace instead of replacing it.

How we built it

The React and TypeScript app registers seven client-side WebMCP tools through document.modelContext.registerTool when the browser exposes the API:

The read-only tools use readOnlyHint, inputs are bounded with object schemas, and no tool exposes untrusted or user-generated content. The deployed static app also sets origin-isolation and Permissions-Policy: tools=(self) headers for the WebMCP environment.

Challenges we ran into

The hard product decision was restraint. It is easy to make a replenishment demo look impressive by letting an agent complete a purchase, but that conceals the real risks. We narrowed the tool surface to what an operator can inspect, reason about, and safely reverse.

We also designed the UI and the tool contract together. Every agent-visible result must make sense to a person looking at the workspace, and every material action must leave a visible trace.

Accomplishments that we are proud of

• A complete alert-to-draft-to-approval workflow and a multi-alert policy plan rather than isolated tool calls.
• A small WebMCP contract that clearly separates read-only lookup from reversible state changes.
• A human-first fallback experience and an explicit audit trail.
• A public HTTPS deployment that is ready for judges to test in a WebMCP-enabled browser.

What we learned

Agent-native product design is less about exposing every button and more about naming the few actions that carry real intent. A structured tool can make an agent more reliable, but the product must still say who owns the decision and what the tool is not allowed to do.

What's next for Restock Room

The next iteration would connect to real inventory feeds behind explicit authorization, add role-aware approval policies, and preserve a durable audit history. Any supplier or purchase integration would remain a separate, explicit human-approved step rather than an extension of the draft-creation tool.

Built With

• react
• typescript
• vite
• vitest
• webmcp