Why I built it

A detailing shop owner can miss a call while working on a car. The hard part is not writing a text. It is deciding which call deserves attention when several people have different deadlines, job values, and follow-up permissions.

I built CallReclaim around one rule: the agent can prepare an editable reply, but only the owner can accept the plan and complete review. Nothing is sent.

What it does

The demo opens with five fictional missed calls. The owner starts by saying how many replies they can handle in the next 30 minutes. A WebMCP agent can then:

  1. Compare the inbox and read the current owner brief.
  2. Stage a rescue plan that fits the owner's capacity.
  3. Link each choice to exact facts recorded on the page.
  4. Open an accepted lead and inspect its conversation.
  5. Draft an editable reply after the owner accepts the plan.
  6. Queue the current draft revision for owner review.

The plan and draft appear in the same desk the owner is already using. The owner can accept or clear the plan, edit the reply, mark the draft reviewed, discard it, or reset the demo.

The agent cannot accept its own plan. It cannot approve a draft. It cannot complete review. It cannot send a message. Those capabilities do not exist in the tool surface or the application.

Why WebMCP fits

A normal interface is good for reading one conversation. The harder task crosses several calls and constraints. WebMCP lets the agent compare the calls, cite the records, and stage a plan in the same live desk the owner sees.

The owner and agent also need a safe way to take turns. If the owner changes the reply capacity, the previous plan no longer applies. If the owner edits a draft, the old revision cannot be queued. Agent drafts also remember which accepted plan and owner brief authorized them.

Without this handoff, the owner has to compare the calls and rebuild the context alone. Here the agent does that cross-record work while the owner keeps the customer decision.

How I built it

The challenge app is a one-page React and TypeScript project built with Vinext and deployed on OpenAI Sites. The top-level page registers five imperative tools with document.modelContext.registerTool(...):

  • list_demo_leads
  • inspect_demo_lead
  • stage_rescue_plan
  • draft_owner_reply
  • queue_for_owner_review

The tools and visible controls use the same state rules. Inputs are bounded with JSON Schema and runtime checks. Tool registration is page-scoped and cleaned up with AbortSignal. Caller transcripts are marked as untrusted content.

The records are deterministic and fictional. There is no database, model API, authentication, telephony provider, tracking, secret configuration, or messaging backend.

The hard parts

The first hard part was capability design. A warning that says "do not send" is weak if a send capability still exists. CallReclaim has no send tool and no messaging backend.

The second hard part was protecting the owner's edit. When they change the plan or draft, the old agent version is rejected.

The third hard part was caller text aimed at the agent. One fictional caller tries to give the agent an instruction. The app treats that as caller text, not as a command. The demonstrated inspection creates no plan or draft.

What I tested

The frozen release passes 14 focused tests, lint, TypeScript checking, production build, dependency audit, and public CI. The tests cover schemas, output budgets, capacity limits, unauthorized leads, unsupported citations, stale plans, owner acceptance, draft gating, owner edits, stale revisions, reviewed work, tool cleanup, and browsers without WebMCP.

I also ran the prompt matrix through fresh public in-app-browser sessions. Direct requests staged the same cited proposal. Ambiguous requests made no changes. Unsafe send requests stopped at the owner gate. Missing follow-up requests stopped before drafting. Stale queue requests preserved the owner's edit. The adversarial reference test found one real identifier bug, which was fixed and re-run before submission.

What I learned

The important decision was what to leave out. The agent can prepare a reply. It cannot approve or send it. Revision checks protect the owner's latest work in code.

The agent sorts the inbox. It stages a plan linked to recorded facts. It prepares an editable reply. The owner completes review. Nothing is sent.

What I built during the challenge

CallReclaim's broader missed-call concept existed before the challenge. During the challenge, I built a separate WebMCP edition with an owner capacity check, a cited plan, five page tools, and revision checks that stop stale work.

What's next

This submission stays fictional. A production version would require customer authorization, secure tenant data, verified messaging consent, provider integrations, audit logging, and a separate operational rollout.

Built With

Share this project:

Updates