ReuseRoute

ReuseRoute Let your AI agent find the best next life for anything you no longer need.

Inspiration: Getting rid of an item is deceptively complicated. A cracked laptop might be repairable, refurbishable, useful for parts, or finally ready for material recovery. A chair could be donated if pickup exists. Damaged clothing might still be repairable or useful for fibre recovery.

The web has plenty of information about these options, but the user journey is fragmented. People often have to open several pages, interpret different acceptance rules, compare conditions, and then figure out what to prepare before a handoff. The easiest option can become the trash bin simply because the better option takes too much research.

We wanted to explore a different kind of open web: one where circular-economy services do not just publish pages for humans to read, but also expose clear, structured actions that a user's agent can call on the person's behalf.

What it does:

ReuseRoute is a human-first web app with an agent-native WebMCP layer.

A person describes an unwanted item, its condition, their transport constraint, and what matters most. A browser agent can then:

1. find eligible repair, reuse, salvage and recycling routes,
2. compare the strongest options using structured fields,
3. select one option and open its details on the page,
4. prepare a visible handoff checklist,
5. save the selected route locally,

pre-fill a visible handoff request for the person to review.

The last step is intentionally human-confirmed. The declarative WebMCP form does not auto-submit. The agent can prepare the task, but the person makes the commitment.

All organizations and service data in the hackathon demo are fictional, so the app never presents invented availability or eligibility as real-world guidance.

How we built it: ReuseRoute is a dependency-free static web app built with semantic HTML, responsive CSS and vanilla JavaScript.

The WebMCP implementation uses both APIs:

Imperative WebMCP: document.modelContext.registerTool(...) defines structured search, comparison, selection and saved-state tools using JSON Schema.

Dynamic tool lifecycle: after a route is selected, ReuseRoute registers route-specific prepare_selected_handoff and save_selected_route tools. An AbortController removes the old contextual tools when the selection changes.

Declarative WebMCP: the handoff form uses toolname, tooldescription and toolparamdescription attributes so an agent can fill the real visible form.

Shared state: every agent action updates the same interface the human sees — result cards, details dialog, checklist, saved indicator and activity log.

Progressive enhancement: the complete manual experience still works when WebMCP is unavailable.

The demo uses local browser storage for saved routes and confirmed demo handoff requests. There is no backend and no network write operation.

Challenges we ran into: The main design challenge was resisting the temptation to expose one giant "do everything" tool. WebMCP is more useful when the tool surface reflects the product's real task boundaries.

We split the journey into discovery, comparison and selection, then made the tool set state-aware. A handoff-preparation action should not exist before a route has been chosen, so those tools are registered only in the relevant context.

A second challenge was deciding where the agent should stop. Preparing a handoff request is useful automation; silently submitting one is a different level of commitment. The declarative form became our human checkpoint: the agent can populate it, the browser makes that visible, and the person confirms.

Finally, we wanted the demo to be trustworthy. Instead of pretending fictional services were real, every program and impact signal is clearly labeled as demo data.

What we learned: The biggest lesson was that agent-friendly design is not the same as adding chat to a website. WebMCP works best when the website itself becomes legible as a set of intentional capabilities.

We learned to think about:

1. the user's goal before individual tool calls,
2. initial application state,
3. the smallest useful tool boundaries,
4. when tools should appear or disappear,
5. which outputs should visibly update the UI,
6. and where a human confirmation is more appropriate than autonomous execution.

What's next: A production version could let real repair cafés, charities, retailers and municipal reuse programs expose their own WebMCP tools. A user's agent could then discover and orchestrate those capabilities across the open web without relying on fragile DOM scraping.

The long-term idea is simple: when someone is finished with an object, the web should make its next useful life easier than throwing it away.

Built With

• accessibility
• aiagents
• chrome
• circulareconomy
• css3
• html5
• javascript
• jsonschema
• localstorage
• netlify
• progressiveweb
• sustainability
• webmcp