Countersign

• 

  The full evidence board: bounded claims, the human review queue, and the live WebMCP tool count.

• 

  The seven baseline tools with their read and write annotations. Publication is not among them.

• 

  Instruction-like evidence is labelled UNTRUSTED and given zero weight, yet preserved as quoted source material.

• 

  Deterministic consistency findings, reproducible byte-for-byte across identical calls.

• 

  An agent-staged assessment waits in the human review queue. No tool can approve it.

• 

  Human approval is what exposes the publication capability.

• 

  Eight tools now: publish_approved_brief carries the dynamic annotation.

• 

  The approved brief, published unchanged and with its grounding chain intact.

Inspiration

Investigation leads often have to reconcile contradictory reports under time pressure. An agent can reduce the reading and drafting load, but an unreviewed synthesis should not silently become an official statement. I built Countersign to explore a stricter division of responsibility: software can inspect and propose quickly, while people retain accountable approval.

The name describes the product rule. A consequential artifact needs a human countersign before an agent can receive the capability to release it.

What it does

Countersign is a fictional evidence room containing six claims and fifteen evidence records. A WebMCP agent can:

1. inspect a bounded incident and list its claims;
2. retrieve evidence through stable IDs and explicit trust metadata;
3. run deterministic consistency checks;
4. stage a cited assessment for human review; and
5. create a brief from human-approved assessments.

The agent cannot approve an assessment or brief. Those decisions exist only in the visible human interface.

The final boundary is stronger than a disabled button. publish_approved_brief is absent from tool discovery until a person approves a brief. Approval changes the page's capability surface from seven tools to eight. The tool then releases only the unchanged approved artifact and disappears after the last eligible brief is published.

Why WebMCP

A vision-only agent would have to scrape cards, infer controls, and guess how evidence relates to claims. Countersign instead exposes a small typed contract through document.modelContext.registerTool(...).

WebMCP is part of the governance model, not a wrapper around the UI:

• five baseline tools are genuinely read-only and perform no workspace mutation;
• two write tools can create drafts but cannot cross an approval boundary;
• claim and evidence responses carry untrustedContentHint;
• schemas reject unknown fields, malformed values, and cross-claim citations;
• deterministic checks exclude instruction-like evidence from scoring; and
• human approval dynamically grants and revokes the one-shot publication capability.

This lets a person and an agent share one workflow without sharing the same authority.

Human review that is actually reviewable

An approval screen shows the proposal alongside every cited excerpt, source, reliability label, trust boundary, and structured ID. Brief review shows the complete chain from approved assessment to claim and evidence. The released bulletin keeps that provenance visible and can be copied or downloaded as Markdown.

The human gate therefore reviews evidence, not just an opaque agent conclusion.

How I built it

I built the application with React, TypeScript, Vite, and Zustand, then deployed it as a static Netlify site. The scenario and state are browser-local, so judges need no account, API key, external model, or private data.

The seven baseline WebMCP tools are:

• get_incident_overview
• list_claims
• inspect_claim_evidence
• check_evidence_consistency
• get_review_status
• stage_claim_assessment
• create_brief_draft

publish_approved_brief is the eighth, dynamic tool. Its handler rechecks live eligibility, accepts no replacement body, returns structured grounding, and becomes undiscoverable when no approved unpublished brief remains.

Vitest covers validation, read-only purity, state gates, pagination, structured grounding, and deterministic logic. Playwright covers the visible human workflow, accessibility focus, responsive behavior, concurrent approved briefs, and the dynamic tool lifecycle. A separate Chrome harness exercises the native document.modelContext discovery and execution API against the production origin.

Challenges

The hardest problem was making capability registration follow application state without becoming fragile. Chrome 151 can omit the callback options argument, and aborting a registration synchronously during its own execution can cancel the result. I added compatibility handling, delayed technical removal while keeping business validation immediately one-shot, and a regression test for multiple eligible briefs so the page never races itself into a duplicate tool name.

Another challenge was response size. list_claims now returns all six compact records in the normal path and also exposes offset, nextOffset, and hasMore for bounded pagination.

Finally, I had to separate a security signal from a security claim. The application marks hostile text as untrusted and excludes it from deterministic scoring. The automated demo uses a deterministic native WebMCP client, not a language model, so I do not claim that it evaluates an LLM's prompt-injection resistance.

What I learned

WebMCP tool design is not only about choosing functions. It also requires deciding when a capability should exist, what state a read-only call may change, which outputs require distrust, and where human accountability belongs.

I also learned that deterministic software and agent reasoning should not compete for the same job. Fixed code is better for replayable consistency checks and state enforcement; an agent is useful for navigating and drafting from bounded material; a person remains responsible for consequential release decisions.

Potential impact

The demonstrated workflow targets incident investigation leads who need to turn contradictory reports into one traceable, human-approved brief. The same capability-shaped consent pattern could support newsroom verification desks, compliance case reviews, research evidence synthesis, or incident postmortems.

This prototype does not claim production readiness. A real deployment would need authentication, durable storage, role-based authorization, privacy controls, real source connectors, and domain-specific validation. The contribution here is a reusable WebMCP governance primitive: approval changes what the agent is technically capable of doing.

Built With

• css3
• html5
• netlify
• playwright
• react
• typescript
• vite
• vitest
• webmcp
• zustand