ProofMesh WebMCP

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 ProofMesh WebMCP

Inspiration

Release decisions are scattered across CI, security, support, and private team context. Agents can reconcile that evidence, but backend-only agents remove the shared interface and screen-clicking agents are brittle. ProofMesh makes the release room understandable to both people and agents while preserving an explicit human decision boundary.

What it does

ProofMesh asks independent Engineering, Security, and Support agents to verify a launch claim, compares their evidence, and surfaces the contradiction needing the release owner. Through WebMCP, a browser agent can inspect the case, run verification, retrieve conflicts, and stage a proposed resolution. Every call updates the same page the user is watching. The agent cannot seal or ship the release: the owner reviews the proposal and clicks Approve & seal. Only then is a read-only decision-receipt tool registered.

How we built it

The React page registers four domain-level tools with document.modelContext.registerTool: get_release_case, run_release_verification, get_release_conflicts, and prepare_owner_resolution. Each has a focused description and JSON Schema input; read-only tools carry readOnlyHint. Registration is lifecycle-bound with an AbortSignal, reuses the existing verification API and React state, and dynamically registers get_decision_receipt after human approval. A visible activity stream records every agent action.

Why WebMCP

Without WebMCP, an agent must infer state from pixels and repeatedly reread the page. A backend MCP server would lose the live, reviewable release-room context. WebMCP exposes domain capabilities inside the page while keeping actions visible and consequential finalization human-owned.

What people and agents can do together

The agent performs high-friction evidence work and prepares a concrete next step. The human sees the same evidence, edits or rejects the proposal, and owns the final decision. This inspect → verify → explain → prepare → human approve → receipt sequence was previously hard to make both reliable and accountable.

Challenges and lessons

The main challenge was resisting the urge to expose every button. We designed a small, permission-scoped surface, made read versus draft behavior explicit, and withheld irreversible approval from the agent. Agent-native does not mean agent-only; sometimes the safest tool is the one deliberately not registered.

What's next

Dynamic tools for release phases, signed receipts, permission-scoped cross-origin team frames, and evaluation against prompt injection and ambiguous finalization attacks.

Built With

• webmcp