Conductor WebMCP

A browser-native, approval-gated control surface for inspecting and coordinating bounded coding-agent work.

Comment

Inspiration

Coding agents are powerful, but coordinating several of them still forces people to bounce between terminals, repository views, and chat threads. Browser agents can see a dashboard, yet without a structured interface they must guess which controls to click and which state is safe to change.

Conductor already gives developers one local-first control surface for projects, worktrees, terminals, diffs, previews, and coding-agent sessions. WebMCP made it possible to give a browser agent the same product-level vocabulary without giving it raw terminal or filesystem power.

What it does

Conductor WebMCP adds seven browser-native tools to the Conductor dashboard:

  • conductor_get_workspace_overview
  • conductor_list_projects
  • conductor_list_sessions
  • conductor_inspect_session
  • conductor_focus_session
  • conductor_start_agent
  • conductor_send_feedback

A person can keep the live dashboard open while a browser agent inspects bounded project and session state, summarizes a diff, focuses a session for review, starts a scoped coding task, or sends feedback. Every resulting state change is visible in the same dashboard.

The public /webmcp route is a backend-free demo workspace. Judges can run the complete tool contract without access to a private laptop, repository, credential, or agent session. The real dashboard mounts the same contract through Conductor's authenticated APIs and paired-device bridge scope.

Why WebMCP is the right interface

This workflow is difficult with ordinary browser automation. Session IDs, repository state, approval requirements, and bounded result shapes are semantic product concepts, not reliable pixel targets. WebMCP exposes those concepts directly, so the agent does not need to infer them from the page.

It also improves the human experience. Instead of surrendering the interface to an autonomous script, the person stays in the visible control surface and approves consequential actions. The browser agent handles coordination; the person keeps authority.

How we built it

The integration registers typed tools with document.modelContext.registerTool, with navigator.modelContext as a compatibility fallback for earlier preview browser builds. Shared schemas reject additional properties and cap IDs, prompts, feedback, filters, and result counts. Read tools use readOnlyHint; repository-derived responses use untrustedContentHint.

Mutations use defense in depth:

  1. The input schema requires confirmed: true.
  2. Invalid or oversized input fails before a prompt, request, navigation, or state change.
  3. The browser then asks the person to approve the exact action.
  4. Existing authentication, action guards, and paired-device scope remain authoritative.

The public route uses deterministic in-memory data and resets on reload. It stays interactive in browsers without WebMCP, while supported browsers register all seven tools natively.

Challenges we ran into

The hardest design problem was choosing the right boundary. Exposing a terminal, arbitrary URL fetcher, or filesystem path would have been easy and dangerous. We instead modeled a small set of high-level Conductor actions and made their limits part of both the JSON schema and the executor.

We also had to support the transition from the earlier navigator API surface to the current document API without an extension or a legacy MCP transport. Registration now prefers the current API, falls back safely, uses an abort signal, and cleans up on unmount.

Accomplishments that we're proud of

  • Seven working browser-native tools, not a mocked registration screen
  • Three mutation tools with schema confirmation and separate human approval
  • Hard input and output bounds, including a twelve-session result cap
  • A public demo that reveals no real repositories, prompts, credentials, or sessions
  • The same tool contract wired into the authenticated Conductor dashboard
  • 412 web tests plus type, build, Rust, E2E, CodeQL, dependency, and secret-scanning gates
  • Desktop and mobile browser QA with no horizontal overflow

Conductor existed before this challenge. The WebMCP implementation was added during the submission period in PR #655, with the final judge-facing polish in PR #657.

What we learned

WebMCP is most valuable when a site exposes product semantics rather than raw computer control. A compact, typed contract makes the agent more reliable and the safety boundary easier for a person to understand.

What's next

Next we plan to add richer progress summaries, signed approval receipts, and user-configurable policy tiers while keeping repositories and agent credentials on the user's machine.

Built With

Share this project:

Updates

Submission history