Inspiration

Small businesses lose time and cash flow not because they do not know invoices are overdue, but because follow-up is messy. A freelancer, tutor, consultant, or agency owner has to decide who to chase first, what tone to use, whether a payment link exists, whether a client promised to pay, and when to stop sending reminders.

Most payment dashboards are built for humans clicking around tables. I wanted to explore what changes when the dashboard becomes agent-operable through WebMCP.

What It Does

Payment Recovery Agent turns overdue receivables into a structured recovery workflow.

A human business owner stays in control of sensitive customer communication, while a browser agent can use WebMCP tools to:

  • inspect the recovery snapshot
  • list at-risk payments
  • identify the highest-priority overdue invoice
  • create a guarded recovery plan
  • generate a payment handoff
  • draft a WhatsApp-ready reminder
  • mark promise-to-pay or recovered payments
  • simulate verified payment success
  • generate an audit trail

The result is not just a reminder tool. It is a human-supervised recovery workflow where overdue money becomes prioritized, actionable, and auditable.

Why WebMCP

WebMCP is a strong fit because payment recovery depends on page-local state and safe sequencing.

Without WebMCP, an agent would need to scrape visible tables, infer which invoice is selected, guess what buttons do, and risk taking the wrong action. With WebMCP, the site exposes explicit tools for each recovery step.

The agent gets structured access to the workflow, and the human gets a clear interface for supervision.

Human + Agent Experience

The human decides what kind of follow-up is appropriate and remains responsible for customer-sensitive actions.

The agent handles the repetitive work:

  • ranking the recovery queue
  • preparing next actions
  • drafting messages
  • attaching payment handoffs
  • updating recovery state
  • summarizing audit history

This division of labor matters because payment recovery is not one action. It is a sequence of decisions where mistakes are costly: chasing the wrong person, over-messaging, sending a reminder after payment, or forgetting a promise-to-pay.

How I Built It

The app is a static web app built with HTML, CSS, and vanilla JavaScript.

It registers 9 WebMCP tools using document.modelContext.registerTool(), with fallback support for navigator.modelContext:

  • get_recovery_snapshot
  • list_at_risk_payments
  • draft_recovery_message
  • create_recovery_plan
  • mark_promise_to_pay
  • mark_payment_recovered
  • create_razorpay_link
  • simulate_razorpay_paid
  • generate_audit_trail

Tool schemas use JSON Schema with additionalProperties: false. Read-only tools are marked with annotations.readOnlyHint: true, and state-changing tools are marked as write actions.

The app uses synthetic demo data only and stores state in the browser for the demo. Every state-changing action writes to an audit trail.

Challenges

The main challenge was designing WebMCP tools that felt like a real agent workflow, not just buttons exposed to an agent. I had to decide which actions should be read-only, which actions change state, what guardrails belong in the outputs, and how to make the agent-human collaboration obvious in a short demo.

Another challenge was keeping the project public and demo-safe while still making it feel realistic. The app uses synthetic receivables and simulated payment handoffs rather than private production data or real payment credentials.

What I Learned

I learned that WebMCP is most powerful when the website exposes meaningful workflow steps, not generic UI actions. The best tools are not "click this button" wrappers. They are bounded capabilities with clear inputs, structured outputs, and human-readable audit trails.

What Is Next

A production version would connect payment handoffs to a secure backend, create payment links server-side, verify payment success through webhooks or signatures, and sync with the user's real invoice/payment system.

Built With

Share this project:

Updates

Submission history