GatherLight

GatherLight - Landing Page and Queries
Quests and OSS Tools Integrated with - OpenStreetMap and Wikimedia
Quest - Completion and Sign off on the Volunteer's name, Minimum Viable Information
Screen to verify final submission details
A Peer Selected Reviewer Views your contribution
Let's Go! Star Lights up, And your community thanks your service!
Architecture Diagram Detailing Deployment, Infra, Sites and Tools

Inspiration

Volunteering takes more time than most people expect. A person might have twenty free minutes and a genuine desire to help but the steps surrounding that desire often take much longer. They need to find a useful gap, learn an unfamiliar system, gather evidence, format it correctly, verify it and locate the right reviewer. And let's be real, most honestly helpful people drop off before they ever reach the step that only they can do.

This led us to the enigma : what should an agent never do on behalf of a person?

An agent cannot stand at a shop entrance and check whether it is step-free. It cannot make a phone call and take responsibility for what it heard. These actions require human presence, judgment and accountability. However an agent can remove nearly every obstacle surrounding those actions.

GatherLight uses WebMCP capability to coordinate human-led civic work across the web.

It finds real gaps in OpenStreetMap and Wikidata and guides a person through one useful task. It checks the result, carries it across sites, asks for explicit confirmation and routes it to another person for review. The agent handles the logistics and the human does the work. (A genuine win-win)

What it does

GatherLight takes one plain-language request and turns it into one verified civic contribution.

"Find me something useful I can do near Koramangala in twenty minutes." (for people that don't know what Koramangala is, it is a place in an Indian city - Bangalore, known for parties,tech and ever upgrading infrastructure)

The browser agent works through the below five WebMCP tools.

find-quests finds gaps on OpenStreetMap or Wikidata that match the volunteer's location, available time and skills.
open-quest opens the visible workspace and explains the parts of the work that must remain human such as calling a place, visiting an entrance or reading an independent source.
check-contribution checks the form against source-specific rules and returns exact corrections instead of a generic error message.
submit-contribution becomes available only after the check passes. It opens an HTML confirmation dialog showing the exact contribution, destination, visibility and licence. The tool waits for the person to click and then checks the contribution again before sending anything.
approve-contribution is available only to a reviewer who has a submitted contribution. It rejects self-review, checks that the public source has not changed and records either an approval or a stale result.

Some quests continue/handed off on another website. Well, that's the USP. We are not just building a Hackathon repository but something that expands on the very foundations of WebMCP.

The handoff carries permission and provenance but it does not carry the volunteer's PII data, observation, credentials or source tokens. The person enters the evidence through the visible interface.

After review, an approved OpenStreetMap contribution can be opened in an embedded iD editor. GatherLight reloads the live map element, compares its version and stages the exact change in iD's undoable state. Nothing is uploaded automatically.

Approval also produces a visible collective result (Audit purposes when Crowd Sourced - obviously). A mark becomes fully lit only when the public source accepts the change.

GatherLight does not treat "approved" and "published" as the same thing.

How we built it

(This gets fairly technical, fairly fast - bear with us - or if you wanna skip the text - Excalidraw Slides to Show what we did.)

The main product is not the website. It is @gatherlight/quest-tools, a framework-neutral package that expresses the five verbs as a reusable WebMCP grammar.

Quest is the React reference application and Survey is a separate partner site written in vanilla TypeScript. Both use the same package which is proof that the workflow is portable across sites, origins and frameworks.

The package registers tools through document.modelContext. Each WebMCP tool is a thin wrapper over the same operation used by the visible interface so a button and an agent call run the same validation, confirmation, state transition and error handling. There is no hidden automation path that can bypass the human interface.

A capability rack shows the tools available at the current moment. When the workflow state changes the package updates the registered tools. By design, The submit-contribution tool does not exist for the agent until the contribution passes its check. The package still validates availability inside every execution because dynamic registration improves tool discovery but it is not an authorization boundary.

Every result uses a small quest/1 envelope with an explicit state. Human-readable guidance comes first and one stable machine-readable line comes last.

Public place names, source titles, URLs and contribution text are treated as untrusted input. We cap and escape them and mark tool output with untrustedContentHint.

Cross-origin state lives in one Cloudflare Durable Object that stores only two entities: contributions and handoffs. Handoffs include: hashed, origin-bound, action-bound, single-use and short-lived. Exchanging one creates a grant for one contribution without exposing the volunteer's session. The data used is real.

Overpass finds OpenStreetMap places with missing opening hours or wheelchair information.
SPARQL finds Wikidata statements that still lack a source.
Nominatim and Photon resolve place names.
opening_hours validates map syntax.
iD stages reviewed OpenStreetMap changes.
Offline snapshots of real source data keep the demo usable when a public endpoint is unavailable.

Challenges we ran into

Crossing the document boundary

WebMCP tools belong to the document that registered them so a full navigation destroys that document and its registered tools, and this boundary is still under discussion in WebMCP issue #227. We worked around this by having open-quest return the next URL along with an opaque handoff that the receiving site can exchange to register the next valid tools without needing a browser extension.

Keeping the person in control

A browser-owned elicitation mechanism does not yet exist (see issue #165) so our package uses a site-owned <dialog> that follows a fixed sequence of check, preview, wait for confirmation, check again and then submit. Nothing is sent if the form changes after confirmation or if the person declines at any point, though we acknowledge this is an application-level safeguard and not a browser security primitive.

Working with live public data

A correct contribution can become outdated while it waits for review so GatherLight captures the source revision when a quest opens and reloads it before any approval or iD staging step. If the source has changed the contribution is marked stale and nothing is overwritten silently.

Accomplishments that we're proud of

One agent coordinates a human-led workflow across two origins and three surfaces using a single shared package. Quest discovers the work, Survey receives the field contribution and iD stages the reviewed change and the same five-verb package works in both React and vanilla TypeScript without any framework-specific logic.
The human contribution cannot be bypassed and submission cannot skip confirmation. The agent can open, check, route and submit but it cannot manufacture an observation, photograph or source judgment, and both the UI and agent paths go through the same check-confirm-check sequence.
Every contribution is grounded in real public data with each stage of the lifecycle clearly labelled and the prototype produces concrete findings for the open WebMCP Skills proposal.

What we learned

In civic systems an agent is more useful when it removes the friction around work that still needs human presence and judgment rather than trying to do that work itself and WebMCP makes this possible because the agent acts inside the page's current session through capabilities the site owns while the visible interface stays in control.
We also found that being honest about what a contribution has actually achieved is more valuable than overstating it because telling a user that their contribution is reviewed but not yet published builds more trust than an animation that implies more change than actually happened.

What's next for GatherLight

First we will contribute the implementation evidence back to WebMCP's active discussions.
- Cross-document and cross-tab tool continuity in issue #227.
- Browser-owned human elicitation in issue #165.
- Workflow-level guidance and tool composition in issue #161.
Next we will publish @gatherlight/quest-tools and work with real partner sites. Adoption matters more than adding features. A second organization should be able to implement the five operations, keep its own interface and identity system and join the workflow without adopting Quest's frontend.
Then we will add accountable write-back. Reviewers will sign in with their own OpenStreetMap or Wikimedia identities. GatherLight will run the source-conflict check again, show the exact public change and write only after reviewer confirmation. The resulting changeset, note or revision will become the landed receipt.
We will add new civic sources only with partner consent and source-specific review rules. A library catalogue, transit feed, heritage register or local open-data portal may use the same grammar and the five verbs will remain unchanged.
The long-term goal is a web where any civic site can clearly state what the work is, what a person must do, what the agent may coordinate and what proof exists that it mattered.