Rdyrct

Inspiration

What inspired me was "how can an agent help me?" I had a hard time thinking what would work but honestly just handing out what a user can do normally already is a big improvement!

What it does

It's an already existing software to create short links with qr codes and statistics, but with the use of WebMCP we can interact with what's already there with little effort. A supporting browser gets twelve tools. On the public pages: read the plans and a product summary, and open the QR generator. In the generator: set the value and styling, read the code back, or download it as PNG or SVG. Signed in: search links, read or create a tracked link, edit one, delete one, and read organization analytics (totals, top links, acquisition breakdowns, dead and declining links). Every result lands in the real UI: created links show up on the Links page, generated codes sit in the generator ready to download.

How we built it

Zero new backend. Each tool calls the same org-scoped REST endpoint the page itself uses, so authorization, quotas and validation stay exactly where they were. Registration goes through document.modelContext when a browser exposes it, and is a deliberate no-op everywhere else: no supported browser means zero behavior change. Tools only appear once the signed-in user and their organization resolve, outputs are plain text capped at 1500 characters and marked untrustedContentHint, and read-only tools carry readOnlyHint. For testing, Playwright installs a fake modelContext before the app loads, so every flow runs in a real browser against the real app.

Challenges we ran into

The biggest one reached production: some implementations call execute(input) with no second argument, and destructuring the abort signal out of it threw. Sentry caught it, the fix made the argument optional, and the e2e suite now invokes a tool bare, exactly the shape that crashed. The second challenge was restraint. It's tempting to hand an agent login or billing, but credentials in model context and injected instructions near identity are risks you don't get to take back, so anything that moves identity or money stayed human-only. Deleting a link is exposed, but it's marked as a write and the agent has to name the exact slug.

Accomplishments that we're proud of

It shipped on a real product with real users, not a demo stub. A production crash was caught, root-caused and regression-tested within hours of appearing in Sentry. An agent can now drive the whole core loop: generate a branded QR code and download it, create a link, then explain how its clicks look. And we also negotiated text/markdown versions of the marketing pages off the same Accept header, so agents can read about the product even signed out.

What we learned

Handing over what already exists beat inventing new agent features. The less a tool returns, the more useful it is: short prose summaries outperformed raw JSON every time. And a protocol built on optional browser behavior needs defensive contracts everywhere: any argument can be missing, any capability can be absent, and none of it may ever break the person behind the browser.

What's next for Rdyrct

More read tools first: domains, member roles, per-link drilldowns, CSV exports. Then discovery: proper Link headers toward an API catalog and service description so agents can learn the surface themselves instead of guessing tool by top-level name. Agent-facing credentials are interesting but they come last, behind the same rule as login: nothing that moves identity happens without the human in the loop.