Kinstead

Where a family's care plan and their AI agents work side by side — and a human always holds the pen on anything that can't be undone.

Built for the OpenAI WebMCP Challenge.

The problem

Family caregivers manage an enormous amount of life-admin for a relative who can't manage it alone: medications, appointments, insurance and benefits paperwork, bill tracking, provider communication. Most of it is tedious, some of it is genuinely high-stakes (a dosage change, an official form submitted to a government agency), and today an AI agent trying to help has to either guess its way through a UI built for humans, or be locked out of doing anything useful at all.

WebMCP changes that: a page can expose exactly the actions an agent is allowed to take, with a real schema instead of DOM-guessing. But most WebMCP demos treat every tool the same way — agent calls it, it runs. That's fine for adding a todo item. It is not fine for changing someone's blood pressure medication or submitting a Medicaid renewal.

Kinstead is a shared "care circle" app built around one idea: tools are tiered by risk, and irreversible or safety-relevant tools always pause for a real human to see and confirm exactly what's about to happen, using WebMCP's requestUserInteraction(). Low-stakes tools — adding a task, logging an appointment, drafting (not submitting) a form, flagging something for a human — execute immediately, because making an agent ask permission for everything is exactly what makes people stop using it.

Why this is a strong fit for WebMCP

WebMCP's whole premise is that a page, not the agent, decides what an agent is allowed to do and how. Kinstead uses that premise as the actual safety mechanism for a high-stakes domain, not just a convenience layer:

• Read/low-risk tools (get_care_circle_snapshot, add_care_task, log_appointment, draft_benefits_form, flag_for_human_review) execute directly against the shared backend.
• High-risk tools (propose_medication_change, submit_official_form) never complete without a human explicitly confirming — enforced through WebMCP's client.requestUserInteraction(), with a same-page fallback modal so the guarantee holds even on hosts that haven't implemented that part of the spec yet.
• Every action, whether taken by a human clicking a button or an agent calling a tool, lands in the same shared activity log — so a family can see, in one place, what their agent actually did on their behalf.

How it creates a better experience

Without Kinstead, "let an AI agent help manage my mom's care" means either giving it broad, unsupervised access to real accounts (unacceptably risky) or using it as a pure chatbot that can only suggest things a human then has to go do by hand (barely saves any time). Kinstead lets a caregiver say "reorder the prescription, log Tuesday's cardiology appointment, and draft the Medicaid renewal" and have all three actually happen — while a medication change or an official submission still lands in front of a person, with the full context, before it's real.

What becomes possible that wasn't before

• Multiple family members' agents, one shared plan. Because the tools read and write a shared backend (not per-browser local state), Dani's agent and Marcus's agent — running in different sessions, possibly different agent hosts entirely — are coordinating through the same live care circle instead of duplicating or conflicting with each other.
• An agent that can act and knows when not to. The tiered-risk tool design means the agent isn't just faster at drudgery — it's legibly trustworthy about the difference between "fine to do on my own" and "needs a person," which is the actual blocker to letting agents touch anything that matters.

How WebMCP is implemented

Tools are registered client-side via document.modelContext.registerTool() in public/app.js, backed by a small Express API in server.js that is the shared source of truth for the whole care circle (so the state an agent sees and changes is the same state family members see in the browser). See registerKinsteadTools() for all seven tool definitions, their JSON schemas, and the risk-tiered execute() implementations, including the requestUserInteraction() human-confirmation flow for medication changes and form submissions.

Running it locally

npm install
npm start
# open http://localhost:3000

Data is persisted to a local data.json (gitignored) that seeds itself with a sample family on first run.

Testing the WebMCP tools

Open the deployed URL (or localhost:3000) in a WebMCP-capable host:

• ChatGPT's in-app browser — supports WebMCP out of the box.
• Google Chrome 149+ — enable chrome://flags/#enable-webmcp-testing and restart.

Then ask the agent things like:

• "Add a task to reorder Rosa's prescription."
• "Log a cardiology appointment for next Tuesday at 10am."
• "Propose changing Lisinopril to 20mg twice daily because her BP readings have been high." — this should pause for a confirmation dialog on the page before anything changes.
• "Draft a Medicaid renewal for Rosa." then "Submit it." — the submit step should also pause for confirmation.

Deploying

Kinstead is a single small Express app with no external services, so it deploys anywhere that runs Node:

• Render: New → Web Service → connect this repo → build command npm install, start command npm start.
• Railway / Fly.io / Vercel (Node runtime): same idea — install, then npm start.

Set PORT if your host requires a specific port; it defaults to 3000.

Stack

Plain Express + vanilla HTML/CSS/JS on purpose — no framework required to demonstrate real, non-trivial WebMCP tool design, and it keeps the whole project auditable in a few small files.

License

MIT — see LICENSE.