Overturn

Inspiration

The web was built for people clicking. Some sites later gained APIs; many accumulated PDFs, hidden rules, multi-page forms, phone-only support, and offline handoffs. Browser agents can read those pages, but they still have to guess at the interface and often stall at the one consequential step that matters.

WebMCP changes that by letting a website expose an explicit, typed contract for agents. The remaining adoption problem is substantial: a site owner still has to inspect an existing workflow, decide what should be a read, what should become an editable proposal, and what must wait for a human, then implement and verify the resulting tools.

We built Overturn to make that retrofit process a product.

For the end-to-end proof, we chose one of the hardest common workflows: appealing a health-plan prior-authorization denial. In Medicare Advantage in 2024, plans processed nearly 53 million prior-authorization requests. Only 11.5% of denied requests were appealed, even though 80.7% of appeals were partially or fully overturned (KFF). The fictional Larkspur Health Plan portal in our demo starts where many real workflows still start: a PDF letter, a six-page form, rules that are referenced but not exposed, and a fax or mailing address.

What it does

Overturn Retrofit takes a public URL and:

Scans up to eight same-origin pages for forms, tables, detail pages, documents, offline submission instructions, cited policies, phone-only support, iframes, sign-in requirements, and WebMCP headers.
Produces a 0–100 agent-readiness score and evidence-backed findings grouped as blockers, gaps, and notes.
Recommends a typed WebMCP tool inventory. Reads are marked read-only, writes become on-page proposals, and consequential actions are explicitly human-gated.
Generates a starter document.modelContext.registerTool() module and a Markdown implementation report.
Exposes its own WebMCP meta-tools—analyze_site, get_readiness_report, list_recommended_tools, and get_generated_code—so a developer’s agent can drive the retrofit itself.

The analyzer does not pretend it can infer and safely wire every site’s private business logic. It generates the tool layer and concrete fixes; a developer or coding agent connects app-specific handlers. To prove that the plan is actionable, we ran Retrofit against the fictional legacy portal, implemented its recommendations, and shipped the complete before-and-after experience on the same live site.

Why this is a strong fit for WebMCP

This project depends on WebMCP rather than merely adding it as a feature.

On the Retrofit page, an agent can run the audit, inspect the findings, list the proposed tools, and retrieve the generated code through four page-native tools.
On the rebuilt appeals portal, 14 tools expose the actual workflow: member context, denials, deadlines, policy criteria, drafting, evidence completeness, review type, submission, status, and external review.
The tool surface is state-scoped. Drafting tools appear only in the appeal workspace; after filing, they disappear and status tools take their place.
Every agent call is visible in the Activity panel, and every proposed write is rendered on the page for the person to inspect or edit.

Without WebMCP, an automation agent must inspect the DOM, open PDFs, infer what fields mean, and eventually stops at the fax instruction. With WebMCP, the site itself tells the agent what it may read, what it may propose, and where the person must take over.

How it creates a better user experience

For a site owner, Overturn replaces a blank page with an actionable plan: what blocks agents today, which tools to expose, how to describe and scope them, which actions need confirmation, and the code to start from.

For a person using the retrofitted site, the agent handles the repetitive work—reading the denial, matching records to five policy criteria, drafting one evidence-backed argument per criterion, checking completeness, and calculating deadlines. The person keeps the decisions that are actually theirs: choose records, edit the language, select standard or expedited review, and sign.

The work never disappears into a chat window. Drafts are on the page, labelled and editable. Tool calls are logged. The person sees exactly what changed and remains in control.

What people and agents can do together that was difficult before

Before: an agent can read a denial letter and locate the appeal form, but the workflow is unstructured and ends at a fax or mailing address. It cannot reliably know the plan’s five criteria, prove that the evidence is complete, or safely file the appeal.

After: in one sitting and on one shared page, the agent reads the structured denial and criteria, opens the appeal, drafts five arguments tied to named records, and re-checks completeness as the member attaches evidence and edits the draft. The agent can request submission, but it cannot file. It returns pending_confirmation, the site renders a Sign & submit card, and only the member’s click creates a case number and starts the decision clock.

That read → proposal → human commit pattern can extend beyond appeals to any claim-shaped dispute or regulated legacy workflow.

How we built it

Application: Next.js 16, React 19, TypeScript, Zustand, Tailwind CSS, and Vercel.
Analyzer: deterministic server-side heuristics using Cheerio. Crawling is SSRF-guarded: HTTP(S) only, private network ranges refused, and redirects, response size, page count, and time are capped.
WebMCP layer: document.modelContext.registerTool() with a legacy navigator.modelContext fallback, one AbortController per tool, duplicate-safe registration, readOnlyHint annotations, concise descriptions, and bounded outputs.
Safety: reads are free; writes render as proposals; submit_appeal and request_external_review return pending_confirmation. The server rejects submission without the human-click marker using 403 human_confirmation_required.
State and judge access: each visitor receives an isolated localStorage sandbox. There is no login or database. A replay demonstrates the same flow for browsers without site-tools access.
Verification: a comprehensive Puppeteer smoke suite exercises route scoping, the full appeal flow, generated code, analyzer guards, human-gated submission, and the post-filing tool transition. We also tested the deployed tools in ChatGPT’s in-app browser and WebMCP-enabled Chrome.
Build workflow: we used Claude Code on an NVIDIA DGX Spark for research, implementation, debugging, testing, deployment, and the reproducible FFmpeg/edge-tts video pipeline. The submitted application does not depend on an LLM at runtime.

Challenges we ran into

Designing real human confirmation. WebMCP does not currently provide a tool-level confirmation primitive. We created an application protocol instead: an agent can propose a consequential action, the page renders a confirmation card, and a server-side gate accepts only the person’s click.

Keeping tools synchronized with application state. The useful tool set changes as the member moves from denial to draft to filed case. We built one registry that derives tools from both the route and appeal status, unregisters stale tools, and remains stable under React Strict Mode and hot reloads.

Analyzing arbitrary URLs safely. A URL analyzer can easily become an SSRF proxy or an unbounded crawler. We had to reject private addresses and tightly cap redirects, bytes, pages, and request time while still returning a useful partial report when some pages fail.

Drawing an honest conversion boundary. Static HTML can reveal affordances, but it cannot reveal every private API or JavaScript-only state transition. Generated handlers therefore make app-specific wiring explicit instead of hiding it behind a false “one-click” claim.

Accomplishments we are proud of

Shipped the analyzer, legacy portal, agent-native portal, and readiness record as one coherent live product.
Turned the legacy portal’s 40/100 audit—two blockers, two gaps, and nine recommended tools—into a working portal with 14 domain tools plus four Retrofit meta-tools.
Made the agent’s work visible and editable while enforcing consequential consent on the server, not in a prompt.
Built a complete, reproducible before-and-after demo and an automated verification suite during the hackathon window.

What we learned

Structured reads alone do not complete workflows. Agents also need typed proposals, deterministic validation, explicit commit paths, and post-action status.
Human control works best as product architecture, not as a prompt instruction.
Tool names, descriptions, scope, and lifecycle are part of the user experience.
A generated scaffold is valuable only when it clearly shows what has been inferred and what a developer still needs to connect.

What’s next

Add authenticated repository and CMS integrations so a developer’s agent can open a reviewed implementation change directly.
Analyze JavaScript-rendered applications in addition to server-rendered HTML.
Connect the healthcare proof to real FHIR Prior Authorization APIs and patient-authorized record sources as those interfaces become mandatory in 2027 (CMS-0057-F).
Extend the visible-work, human-commit pattern to billing disputes, benefits appeals, government forms, and other high-friction legacy workflows.

All payers, clinics, people, records, policy identifiers, and case numbers in the demo are fictional and synthetic. Overturn was created during the challenge and is MIT licensed.