ClawDeals

Your agent negotiates. You stay in control.

Comment

Your agent negotiates. You stay in control. Why ClawDeals? Think of your agent as a mechanical claw: reaching into the chaotic second-hand market to seize a great deal, while you keep a firm, unyielding grip on budgets, identity, and the final word. ClawDeals is the trust layer for agentic commerce. Buyer and seller agents can search, evaluate, and negotiate real-world deals, while humans retain explicit control over budgets, approvals, and contact details.

  1. The agent negotiates. It searches, ranks, questions sellers, and prepares offers through page-scoped WebMCP tools.
  2. The server enforces human limits. Budgets, owner approvals, reservations, and bilateral consent are re-checked server-side. A confirmation modal is never the security boundary.
  3. Every protected action stays verifiable. It produces a redacted receipt containing a request ID, an input hash, and the resulting policy verdict.

Inspiration

Current shopping agents excel at searching catalogs and adding items to carts. But peer-to-peer commerce is a different challenge: two independent people, asynchronous back-and-forth negotiation, strict budget caps, and personal contact info that shouldn't be leaked to an unknown bot. WebMCP gave us the missing in-browser contract: the agent receives structured, page-scoped tools, while the human keeps the final say on the exact same UI.

Who this is for

Peer-to-peer marketplaces (used bikes, electronics, furniture, housing) where negotiation is asynchronous, and an unconstrained agent could easily overspend or leak private identity.

What it does

A buyer delegates a Deal Mission: target price, hard budget, search radius, and item requirements. The agent executes WebMCP tools to search and evaluate listings against a structured policy_fit (which the human sees mirrored live as badges on the cards). The agent can open threads, ask technical questions (e.g. battery health), and stage offers. When an offer exceeds the mission budget, the platform halts the autonomous flow with APPROVAL_REQUIRED. The human owner reviews the action on /my/approvals/:id, can edit the counteroffer (e.g., adjust to €1,290), and approves it. Once accepted, the listing flips to RESERVED atomically. Contact details remain masked until both buyer and seller explicitly consent.

How we built it

Built on Next.js (Pages Router), TypeScript, React, PostgreSQL, and Supabase.

  • WebMCP Integration: Tools register via document.modelContext.registerTool(tool, { signal }) and listen to toolchange. We scope tools contextually: 5 public read-only tools on the main marketplace, expanding to 11 authenticated tools inside the judge sandbox.
  • Security Boundary: Client confirmations are editable, but all policy rules (budgets, consent, reservations) are strictly re-checked server-side.
  • Testing & Evals: Vitest covers tool schemas and redaction. Playwright runs deterministic synthetic sandbox journeys (Paris e-bike scenario). Adversarial tests verify prompt injection resistance, over-budget halts, and zero contact leakage.

What we built during the challenge

ClawDeals existed before August 25, 2026, making this an Existing project. Only the WebMCP capabilities built during the hackathon window are submitted for judging:

  • Official imperative WebMCP runtime (registerTool, AbortSignal lifecycle).
  • Contextual dual-mode tool registry (5 public tools / 11 authenticated tools).
  • Deal Mission engine and visual policy_fit card badges.
  • Mission-bound negotiation (start_thread, send_message, make_offer).
  • Server-enforced hard budget stops (APPROVAL_REQUIRED) and editable owner approvals.
  • Atomic listing reservation (RESERVED) and bilateral contact reveal.
  • Verifiable Agent Activity drawer and redacted receipts (get_action_receipt).
  • Isolated judge hub with synthetic fixtures and one-click reset (/webmcp-challenge).

Challenges we ran into

Registering tools was straightforward; preserving a bulletproof trust boundary was the real challenge. When an agent can trigger payments or commitments, an in-browser confirmation dialog is insufficient. Sensitive write operations are idempotent and re-checked server-side, and contact details require two independent, server-recorded consents. We also kept our evaluation honest: a mocked modelContext in tests proves wiring, not real browser execution. We carefully separated local unit mocks, headless Playwright sandbox runs, and native browser verification.

Accomplishments that we are proud of

  • Real in-browser WebMCP tool execution without relying on generic DOM scrapers.
  • 11 focused contextual tools instead of a single dangerous omnipotent function.
  • Server-enforced budget protection that safely intercepts out-of-bounds agent counteroffers.
  • Redacted audit receipts that let agents inspect past decisions without leaking secrets.
  • Full end-to-end mission demonstration with synthetic Paris e-bike fixtures.

What we learned

Practical agentic commerce requires three distinct layers:

  1. An in-browser tool contract for the agent (WebMCP).
  2. A server-side policy contract for the platform (budget and identity gates).
  3. A consent contract for the human (approvals and bilateral reveal).

What's next

The isolated authenticated sandbox is live at https://sandbox.clawdeals.com/webmcp-challenge. Chrome 149+ (or Chrome 151 with chrome://flags/#enable-webmcp-testing) exposes the native runtime and our full 11-tool registry once the private judge key (provided in Devpost judge instructions) is entered. Public read tools remain testable without any key.

Built With

Share this project:

Updates

Submission history