Blast Radius

Inspiration

Supply-chain compromises like the 2018 event-stream incident don't just hit one package — they reach thousands of services through dependencies nobody on the team has ever read. Security review of this kind is exactly the task an AI agent should help with: precise, structured, and fast. But almost every "AI + your app" integration today means the agent works blind, guessing through a UI, while the human has no idea what it's doing until it's done. WebMCP flips that: the agent calls exact tools you define, and — if you build it right — the human can watch it happen. We wanted to see what supply-chain security review looks like when a human and an agent are looking at the exact same screen at the exact same time.

What it does

BlastRadius is a real-time supply-chain blast-radius visualizer with two tools exposed via WebMCP. An agent can call trace_blast_radius on any package name, and instead of the result disappearing into a JSON blob only the agent sees, the dashboard's graph, stats, and attack-path breadcrumb update live in front of the human watching. An agent can also call flag_dependency_for_review to flag a suspicious package with a reason and severity — which surfaces instantly as a card in a "Flagged for Review" panel on the human's screen, ready for their judgment call.

How we built it

The frontend is React with a dark, terminal-style dashboard: a search bar, a stats row (packages affected, services exposed, persistence multiplier, maintainer risk), a force-directed dependency graph, and the flagged-review panel. The WebMCP layer is two tools registered via document.modelContext.registerTool() at the app's entry point. Neither tool just returns data — each dispatches a browser CustomEvent that the dashboard listens for and reacts to visibly, which is the core design decision: agent action becomes human-visible UI change, not a silent side channel.

Challenges we ran into

We started by wrapping an already-built dashboard's live Express/HydraDB backend with WebMCP tools — a stronger, more "production" story on paper. Under real deadline pressure, that backend deployment broke (missing environment configuration on a fresh Vercel project), and debugging it live was eating the little time we had left. Rather than gamble the whole submission on fixing infrastructure blind, we rebuilt the core experience as a fully self-contained client-side app with realistic mock data — same UI, same WebMCP tools, same live-update behavior, zero external dependencies to fail at the worst possible time. That decision is the actual story of this build: knowing when to cut a dependency rather than lose the demo entirely.

Accomplishments that we're proud of

Getting the live-update pattern actually working — an agent calling a tool and a human watching the dashboard change in real time, not a delay, not a refresh — on a tight clock. And recognizing under pressure that a working, honest, self-contained demo beats a broken "more impressive" one; that's a real engineering call, not just a technical one.

What we learned

The biggest one: agent-native features live or die on what the human sees, not what the agent gets back. A tool that returns clean JSON but changes nothing on screen is invisible collaboration — which isn't collaboration at all. We also relearned, the hard way, that infrastructure dependencies (env vars, database connections, multi-service deploys) are the first thing to break under time pressure, and that having a fallback path matters as much as the primary build.

What's next for BlastRadius

Reconnecting the WebMCP layer to the real HydraDB-backed backend now that the deploy issue is understood, so the tools operate on live 10k-package data instead of mock data. Beyond that: more collaborative tools where the agent doesn't just report findings but proposes actions (e.g., "pin this dependency," "open a rollback PR") that the human approves directly from the flagged-review panel — moving from "agent reports, human decides" toward a true shared workspace.

Built With

• hydradb