Dependency War Room

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Dependency War Room

Inspiration

Dependency registries answer the forward question well: “What does this package depend on?” The harder operational question is the inverse one: if a package changes, who downstream is exposed, what evidence do I have, and what should I migrate first?

What it does

Real-time Dependency Graph Analysis Platform combines dependency graph data, API-change analysis, declared version-range exposure, security evidence and explicit human review in one War Room.

For the WebMCP Challenge, I extended the existing platform with a browser-native War Room where a developer and an agent operate the same application workflow. WebMCP exposes constrained product actions for graph inspection, blast-radius analysis, human review, critical paths and migration planning instead of giving the agent raw database or GraphQL access.

Why this is a strong fit for WebMCP

Dependency-impact analysis is naturally multi-step: opening a package graph, summarizing topology, calculating blast radius, tracing a dependency path, simulating an API change, reviewing version exposure, applying human business priority or exclusions, recalculating the scenario, inspecting critical paths and generating a migration plan.

With WebMCP, the application exposes those operations as explicit, schema-constrained product actions. The user remains in the visual War Room while the agent works through the same application workflow.

Human and agent collaboration

There is no separate agent-only copy of the workflow. If the developer changes scenario priority or explicitly excludes something from migration scope, the agent continues from that same reviewed state.

The agent coordinates the investigation, while deterministic application logic remains responsible for breaking-change analysis, version exposure, blast-radius calculation, compatibility-related evidence and migration-plan generation. Human review remains explicit for business priority and exclusions.

How WebMCP is implemented

The application uses document.modelContext and registers a catalog of 16 canonical WebMCP tools. The runtime surface is adaptive: the application does not expose all 16 tools at every moment, but only tools relevant and executable for the active War Room phase.

A verified initial runtime surface for cargo:tokio included open_package_graph, summarize_graph, calculate_blast_radius, trace_dependency_path and focus_graph_nodes. As the workflow advances, actions such as recalculate_scenario and generate_migration_plan become relevant.

Both human UI actions and WebMCP actions call the shared WarRoomActions abstraction. WebMCP does not expose raw SQL, raw Cypher, arbitrary GraphQL, arbitrary scripts, arbitrary URLs or unrestricted backend operations.

Better user experience

The developer can inspect facts visually, make a business decision, and then ask the agent to recalculate the scenario and generate the next migration plan from the updated state. This shared-state collaboration is difficult to achieve reliably with ordinary DOM automation or a standalone chatbot.

Real production environment

The public deployment uses Vercel for the Next.js frontend, Render for the Rust/Axum API, Memgraph Cloud for the dependency graph, Redis for runtime cache/state, PostgreSQL/Neon for relational metadata, Qdrant for semantic search/vector data and OSV.dev for vulnerability evidence.

The production demo is intentionally a seeded environment rather than claiming live registry ingestion. The graph and API interactions demonstrated in the submission video are real production application state.

Existing-project disclosure

The dependency analysis platform existed before the WebMCP Challenge. The challenge submission is the meaningful WebMCP extension and War Room integration added during the competition period, including shared WarRoomActions state, phase-adaptive runtime registration, constrained browser-agent actions, explicit human review, critical-path inspection and deterministic migration planning.

What I learned

WebMCP works best when a website exposes meaningful application actions rather than generic backend capabilities. The important design question is what the application should allow the agent to be authoritative about. Keeping deterministic evidence, human decisions and agent coordination separate made the WebMCP surface clearer and safer.

What's next

The next step would be expanding the same WebMCP authority model to larger dependency graphs and additional package ecosystems while keeping the adaptive tool surface small, with stronger browser-level WebMCP regression coverage and richer source-compatibility evidence.

Built With

• next.js