CivicFlow: open-source WebMCP public-benefits portal where humans always submit

Problem

Public health and benefits portals are hard to fill out during emergencies. Existing browser agents rely on brittle screenshot-and-click loops that break when UI layouts shift—or worse, risk submitting unverified government forms without the applicant checking them.

What I built

An open-source WebMCP public-benefits portal and evaluation suite where the website itself acts as the MCP server. A person and a browser agent share visible form state through 10 typed, schema-validated tools inside the signed-in browser tab—and only the human can press final submit.

Architecture diagram

+-----------------------------------------------------------------------------------+
|            SIGNED-IN BROWSER TAB (The Website IS the WebMCP Server)               |
|                                                                                   |
|  +-----------------------+    10 Typed, Schema-   +-------------------------+     |
|  |   Browser AI Agent    | <==   Validated    ==> | Shared Visible UI State |     |
|  |  (Reads & drafts fields|    WebMCP Tools       | (Applicant sees every   |     |
|  |   via contract, no DOM |     (Read/Write)      |  change live on screen) |     |
|  |   screen-scraping)     |                       +------------+------------+     |
|  +-----------------------+                                    |                   |
|                                                               v                   |
|                                           +-------------------------+             |
|                                           |    HUMAN SUBMIT GATE    |             |
|                                           |   (Agent blocked from   |             |
|                                           |  final form submission) |             |
|                                           +-------------------------+             |
+-----------------------------------------------------------------------------------+

Key decisions

1. 01

   The website is the MCP server (10 typed tools vs. screenshot-and-click)

   Why: Exposed 10 explicit, schema-validated tools directly in the client tab instead of letting an agent guess coordinates from screenshots.

   Trade-off: Requires portal authors to define a tool contract upfront, but turns fragile UI automation into a deterministic API inside the user's active session.

2. 02

   Shared visible state between human and agent

   Why: Every tool call immediately mutates the visible form state on screen so the user can watch and override any field in real time.

   Trade-off: Tighter coupling between tool handlers and React/UI state, but complete transparency for the applicant.

3. 03

   Hard human-only submit boundary

   Why: Omitted a submit_application tool from the agent's write permissions; the agent can validate and pre-fill, but humans always submit.

   Trade-off: Cannot run 100% unattended background submissions, which is deliberate—legal and benefits forms should never be one bad tool call away from submission.

Result

• 10

  typed tools exposed with full schema validation

  GitHub ↗(opens in a new tab)

• 100%

  human-gated final submission boundary

  GitHub ↗(opens in a new tab)
• [PLACEHOLDER]

  [ADD METRIC: form completion speed-up vs manual entry on eval suite]

Demo

Want to make your SaaS product agent-ready with WebMCP or typed tool contracts?