OpenSource Release Feed

Inspiration

RSS remains one of the best ways to follow the open web, but discovering and configuring feeds for open-source projects is still unnecessarily difficult. OSSReleaseFeed began as a zero-account way to turn GitHub topics or starred repositories into a permanent feed URL.

WebMCP introduced a more interesting possibility: instead of making an agent guess how to operate the interface, the page could expose structured tools while keeping the application visible and interactive. The goal became a genuinely collaborative experience in which an agent can configure a feed, the user can follow every change, and either participant can safely continue where the other left off.

What it does

OSSReleaseFeed creates permanent Atom or JSON Feed URLs for public GitHub activity. Users can follow repositories associated with selected GitHub topics or start from repositories they have starred, choose the activity they care about, and select an update frequency. No OSSReleaseFeed account, OAuth flow, or email address is required.

In a WebMCP-capable browser, an agent can build a topic feed through tools exposed directly by the page. The tools are progressively disclosed as the configuration advances: choosing the source reveals topic selection, validated topics reveal feed settings, and completed settings reveal URL generation.

Every WebMCP action updates the visible interface. The user can inspect the agent’s choices, refine them with the normal controls, take over completely, or ask the agent to continue.

How we built it

The frontend uses React, TypeScript, and Vite on Cloudflare Pages. Feed generation and GitHub integration run through a TypeScript Cloudflare Worker built with Hono and Effect.

The WebMCP integration registers a small dynamic toolset using document.modelContext.registerTool. It currently provides tools to inspect the current feed configuration, choose the topic-feed source, validate and select GitHub topics, configure feed settings, and generate the final URL.

WebMCP is not a separate implementation of the feed builder. The manual and WebMCP paths share the same feed configuration, state reducer, GitHub validation API, and URL generator. Manual controls prevent many invalid inputs through constrained interface elements. WebMCP validates structured tool input through schemas and runtime checks, then uses the same GitHub topic validation before applying user-supplied topics.

We documented the important user journeys as Gherkin scenarios and used them to guide Vitest integration coverage and Playwright tests across desktop, tablet, and mobile viewports.

Challenges we ran into

The hardest challenge was coordinating slow agent operations with direct user interaction.

A WebMCP agent may still be waiting for GitHub validation when the user decides to take over and complete a different feed manually. Without explicit coordination, the older tool call could eventually finish and overwrite the user’s newer choices or clear a feed URL they had already generated.

The application therefore follows a strict newer-action-wins policy. A newer WebMCP mutation aborts older pending WebMCP work. A manual change to the current feed configuration immediately revokes pending mutating WebMCP work before applying the user’s change. Revision checks provide a final safeguard when an upstream request completes despite cancellation.

We also encountered differences between WebMCP hosts, including execution callbacks that did not always provide an abort signal. The handlers now tolerate a missing signal while preserving cancellation when one is supplied.

GitHub rate limiting presented another challenge. We added safer diagnostics that distinguish rate limiting from general upstream unavailability without exposing tokens, usernames, or other sensitive request details.

Accomplishments that we're proud of

We are particularly proud that the result feels like one coherent application rather than a conventional interface with an agent API attached to the side.

Agent actions are visible, manual and agent-driven changes share the same underlying state, and users can take control without risking a delayed operation overwriting their completed work.

The dynamic tool surface also gives agents only the capabilities that are meaningful at the current stage of the task. This reduces ambiguity while preserving the user’s ability to operate the same interface directly.

Finally, the production implementation is backed by manual scenarios, integration tests, accessibility checks, and end-to-end coverage—including the difficult case where manual completion must defeat a slow WebMCP response.

What we learned

WebMCP is most valuable when it complements the visible application instead of bypassing it. Structured tools improve agent reliability, but the larger benefit is creating a shared surface where people can understand, correct, and continue an agent’s work.

We also learned that shared state requires explicit concurrency rules. AbortController helps avoid unnecessary network work, but cancellation alone is insufficient. Revision checks are still necessary because an upstream operation may complete after cancellation or a host may not provide the expected signal.

Progressive tool registration proved useful as both an agent-guidance mechanism and a product-design constraint. It encouraged us to define the valid transitions in the feed-building journey precisely, which also improved our scenarios and automated tests.

What's next for OpenSource Release Feed

The current WebMCP implementation focuses deliberately on topic feeds. The next step is to extend the same visible, validated workflow to starred-repository feeds, including username validation, repository selection, filtering, and correction of individual repository names.

We also want to improve resilience around GitHub rate limits through better caching and clearer recovery guidance, expand the manual and automated scenario suite, and continue testing across WebMCP-capable hosts as the standard evolves.

Longer term, we want OSSReleaseFeed to demonstrate a dependable pattern for the agent-native web: applications where agents can perform meaningful work efficiently, people can see and refine that work, and the user’s latest intent always remains authoritative.

Built With

• cloudflare
• react
• typescript
• webmcp
• workers