Grapevine Care

• 

  Coverage Dashboard 5

• 

  Coverage Dashboard 4

• 

  Coverage Dashboard 1

• 

  Coverage Dashboard 3

• 

  Coverage Dashboard 2

Inspiration

Care does not happen in one shift. A coordinator must reconcile schedules, caregiver readiness, resident-specific context, missing verification, visit records, and handoffs—often while plans change. Conventional dashboards scatter that context across screens and leave people to reconstruct what is known, what is still unknown, and who must decide next.

We built Grapevine Care to explore how WebMCP can give an agent structured access to the same evolving, page-scoped state as a human coordinator without taking authority away from residents, caregivers, or clinical professionals.

What it does

Grapevine Care is a fictional, safety-first caregiver-continuity simulation. Its primary experience is one compressed Care Team Day across three residents:

1. At 9:15 AM, Evelyn's visit lacks a verification record. The agent prepares a bounded inquiry; Luis answers in his own voice; the coordinator records the disposition.
2. At 11:30 AM, Elena is available for Walter but lacks resident-specific readiness. The agent prepares an orientation packet and follow-up; Elena reports completion; the coordinator verifies it.
3. At 2:15 PM, Maya calls out for Rose. The server evaluates four caregivers against eight named constraints, and the agent explains why only Jordan is eligible before a scheduler approves.
4. At 5:00 PM and 7:35 PM, the coordinator requests and verifies Jordan's readiness and visit record instead of impersonating her.
5. At 8:00 PM, Jordan approves the prepared handoff, Luis confirms receipt, and the coordinator verifies both sides.

Time is the spine of the experience. The clock cannot advance until the current decision is resolved, escalated, deferred with a reason, or waiting on an identified person. Advancing time never reveals the answer to an open question.

Why WebMCP

WebMCP makes this workflow meaningfully better because an agent can traverse resident context, schedule constraints, readiness evidence, and handoff state through structured tools rather than scraping the interface or guessing through UI controls.

People and agents work together through one visible state machine:

observe → investigate → prepare → human decision → document → advance

The agent does the connective work—finding context, comparing evidence, evaluating constraints, and preparing the next bounded action. People provide self-reports and retain authority over assignments, verification, and consequential decisions.

How we built it

The application exposes twenty purpose-built WebMCP tools through document.modelContext.registerTool. Only the subset valid for the current workflow state is registered. Read tools expose structured context, knowns, unknowns, provenance, versioned snapshots, and deterministic constraint results. Preparation tools stage bounded inquiries, orientation, coverage, or handoff records; they do not contact a person or change an assignment without a visible human decision.

The server—not the model—enforces time gates, caregiver eligibility, snapshot freshness, idempotency, and legal workflow transitions. The agent cannot diagnose, make clinical or emergency determinations, change care plans, assign staff, answer for a caregiver or resident, or release medication.

The stack includes React 19, TypeScript, Vite, a Cloudflare Worker API, D1 persistence, Zod runtime validation, generated JSON Schema inputs, OpenAI Sites packaging, and Vitest.

Challenges

The hardest problem was not maximizing what an agent could do; it was designing precisely where automation should stop. We separated preparation from execution, kept resident and caregiver responses on human-only surfaces, made unknowns explicit, and bound consequential proposals to fresh evidence and schedule snapshots.

We also hardened the app for different WebMCP browser implementations, including implementations where registerTool returns synchronously rather than as a Promise.

Accomplishments

• One coherent six-block Care Team Day across Rose, Walter, and Evelyn.
• Twenty state-dependent WebMCP tools with bounded schemas and explicit authority limits.
• Deterministic eight-constraint caregiver eligibility with no opaque suitability score.
• Versioned evidence and schedule snapshots with stale-state rejection.
• Idempotent preparation and conditional state transitions.
• Per-browser isolated demo runs and deterministic reset.
• Coordinator-led readiness, visit-record, and two-sided handoff loops.
• Responsive, keyboard-focusable, reduced-motion-aware interface.
• Thirty-one automated tests covering server invariants, WebMCP registration, safety boundaries, state transitions, and browser compatibility.

What we learned

Building for WebMCP shifted our thinking from exposing interface controls to exposing accountable jobs. A useful agent tool needs more than structured input: it needs provenance, explicit unknowns, freshness guarantees, idempotency, and a clear statement of who still owns the decision.

We also learned that human-in-the-loop design is strongest when authority boundaries are enforced by the product and server state—not merely requested in a prompt.

Project origin

Grapevine Care was created during the submission period as a distinct healthcare adaptation of the MIT-licensed Project Grapevine foundation. The public repository contains a detailed origin record and timestamped commit history distinguishing the retained foundation from the healthcare-specific domain model, workflows, tools, interface, and judge scenario.

Testing

Open the live application in the latest ChatGPT desktop app's in-app browser with Site Tools enabled. Reset Care Team Day and confirm that the opening block reads 9:15 AM · Morning verification. Ask:

I am taking over the care coordinator desk. Tell me what needs attention now, investigate what is unknown, and prepare the next safe step for my review.

Continue through Evelyn's inquiry, Walter's readiness loop, Rose's coverage recovery, Jordan's visit evidence, and the two-sided handoff. The clock remains blocked at every unresolved decision.

Safety note

This is a deterministic competition simulation, not production healthcare software. It has no protected health information, real messaging, electronic health record, pharmacy, workforce, medical-device, or emergency-service integration. All residents, caregivers, responses, and events are fictional.

Built With

• cloudflare-d1
• cloudflare-workers
• codex
• openai-sites
• react
• typescript
• vite
• vitest
• webmcp
• zod