VoiceGuard

A browser agent spots risk while the human keeps the controls.

Comment

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 VoiceGuard

Inspiration

Voice AI can listen, reason and respond in real time, but consequential calls still need accountable human judgment. Conventional browser automation forces an agent to infer meaning from buttons and dashboards, while a hidden backend tool can remove the shared context that helps a person supervise safely. We wanted the agent and operator to work from the same visible page without giving the agent invisible authority.

What it does

VoiceGuard is a synthetic voice-operations cockpit with four WebMCP site tools. An agent can inspect the current call state, audit visible guardrails, draft short operator guidance, or stage a pause request. The first two tools are read-only. The latter two change only visible draft or request state. A trusted human click is required before guidance can be applied or the synthetic call can be paused.

The public demo deliberately exposes no tool for dialing, sending guidance, speaking, listing contacts, starting campaigns, transferring or hanging up. Every call, person, transcript and metric on the page is fictional.

Why WebMCP is a strong fit

Supervision depends on live shared context: phase, latency, transcript, policy signals and pending actions. WebMCP lets the browser agent discover narrow, schema-defined actions directly on that same page instead of scraping the DOM or calling a detached backend. Tool calls update a visible activity trace, so the operator can see what the agent read or prepared.

This makes the experience faster and less ambiguous while preserving the human-first interface. The agent finds the signal. The human owns the action.

How we implemented WebMCP

The static top-level page registers four imperative tools with document.modelContext.registerTool. Each tool has a narrow JSON Schema, bounded text inputs and explicit read-only or untrusted-content annotations. The two draft-only tools return structured proof that no call action was executed. Human review buttons require trusted click events.

The optional ?inspector=1 view is a transparent native test client. It uses document.modelContext.getTools() and executeTool() to show the exact JSON returned by Chrome's WebMCP implementation. The app has no backend and makes no network request after loading.

Challenges we ran into

The main challenge was designing useful agent actions without quietly creating an unsafe control plane. We removed every direct call action and separated drafting from execution. We also treated transcript text as untrusted page content, bounded all inputs, made tool activity visible, and built native Chrome tests that prove the page remains live until a human confirms a pause.

Accomplishments

  • Four working top-level WebMCP tools with native Chrome discovery and execution tests.
  • A polished responsive shared workspace rather than a hidden JSON-only demo.
  • Visible synthetic-data and autonomy boundaries throughout the product.
  • A clean-room public repository with no production dependency or credential.
  • Automated static, browser, responsive, safety and public-deployment checks.

What we learned

The most interesting WebMCP design question is not how many actions an agent can take. It is which actions should remain deliberately unavailable. Narrow tools, shared state and visible confirmation can make an agent more useful without making it less accountable.

What's next

Next we would connect the same interface contract to an authenticated pilot, add role-based tool availability, retain privacy-safe audit events, and test the workflow with real operators under explicit consent and legal review. None of those future production capabilities are represented as part of this synthetic contest demo.

Built With

Share this project:

Updates

Submission history