Zero-install marketplace access: hosted MCP endpoint, pay on delivery (simplest slice of #941)

[maxy-player]

Spin-off from #941, from the owner's discussion thread (1 Sep 2026). #941 scopes the full universal MCP: local plugin, on-device wallet, fund-first. This issue is the simplest possible zero-install slice of that goal, deliberately narrower so it can ship first.

Revised 1 Sep 2026 (owner's direction): no operator float, no custody, no seller protocol change. The user pays after the result exists; the payment is bridged into the existing ecash settlement path.

Goal

A person using Claude Code, Codex, or Cursor can hire the maxplayer marketplace with nothing installed and no account. They point their agent at one URL, ask for an outcome, and pay a Lightning invoice from a phone wallet only after the answer is ready. The answer lands in the same conversation.

The user's experience, end to end

1. One line in their agent, e.g. claude mcp add --transport http maxplayer https://mcp.maxplayer.ai (URL TBD). Nothing of ours runs on their machine.
2. They ask: "Get this login bug fixed and tested. Spend no more than 500 sats."
3. The agent calls quote. They see the task, the price ceiling, what will be shared, and the expected wait. No money moves.
4. They say go. The agent calls start.
5. The agent polls status until the job is delivered.
6. On delivery the endpoint returns a Lightning invoice for the final price, at or under the ceiling. They pay it from any wallet they already have.
7. The agent calls result. The finished work comes back in the conversation.

No signup. No deposit. No funding step before the work. Nothing to uninstall.

v1 design: a hosted buyer with an empty wallet

• Hosted Streamable HTTP MCP endpoint, unauthenticated. Four tools: quote, start, status, result. Each job gets an opaque job id; that id is the only credential.
• Behind it, buyer logic with a Nostr identity and no sats. It posts the job, collects claims, awards one, and receives the result, exactly as any buyer does today.
• Pay after delivery, bridged through the seller's mint. Today the seller delivers first and waits for the buyer to push ecash (seller state "delivered but unpaid", seller.rs). The seller's claim carries a Cashu payment request (NUT-18 creq, gateway.rs build_seller_creq), not a Lightning invoice, so a phone wallet cannot pay it directly. The bridge:
  1. Seller delivers. Endpoint holds the result.
  2. Endpoint requests a NUT-04 mint quote (a Lightning invoice) from one of the seller's accepted mints for the final amount. This is the same mechanism buyers use to fund today.
  3. Endpoint returns that invoice to the user's agent. User pays it.
  4. Mint honours the quote; endpoint mints the proofs P2PK-locked to the seller and sends them down the existing NIP-17 payment path (payment_wallet.rs, payment_send.rs). Seller sees a standard payment and co-signs the settlement receipt as usual.
  5. Endpoint releases the result.
• No custody. The endpoint never holds spendable balance. The ecash exists for one step and is locked to the seller from creation. Users hold no balance with us at any point.
• Seller code is untouched. Sellers cannot tell this job from any other buyer's.

The one code change: pay-later award

Today the buyer reserves max_sats against its wallet before signing an AWARD (buyer/lifecycle.rs "Reserve before any signing", buyer/reservations.rs). The hosted buyer has an empty wallet, so awarding fails. v1 needs a buyer-side pay-later award mode that skips the wallet reservation for endpoint jobs and instead tracks the pending invoice. Everything after AWARD (result receipt, ACCEPT, pay, receipt) is the existing path.

Risk, stated plainly

A seller who delivers to a buyer that never pays is out the compute. The reservation check normally makes that near-impossible; pay-later removes it for these jobs. Mitigations for v1: a per-job ceiling, a per-source rate limit, and a result retention window after which the unpaid job is closed. Sellers may choose to decline this buyer's jobs.

Explicitly out of scope for v1

• Accounts, deposits, balances, or any stored user identity.
• Any operator float or operator-paid settlement.
• Atomic pay-to-unlock (encrypting the result so paying the invoice hands over the key). Right v2; v1 accepts the seller-side risk above to ship sooner.
• Seller-set deposit thresholds and buyer reputation.
• The local plugin and on-device wallet. That stays in Scope a universal MCP integration for the marketplace #941 / feat(plugin): ship the buyer playbook as a Claude Code plugin #938.
• ChatGPT connector packaging. The same endpoint should serve it, but verifying that is separate work.

Acceptance

From a fresh machine with only Claude Code installed: one claude mcp add line, one ordinary request, a quote with no payment, a go, a Lightning invoice that appears only after delivery, paid from a phone, and the result in the conversation. The seller receives a normal P2PK ecash payment and co-signs the receipt. The endpoint's wallet balance is zero before and after.

Open questions for the owner

1. Per-job ceiling for v1.
2. Public hostname for the endpoint.
3. Unpaid-result retention window (proposal: 24h).

Related

• Scope a universal MCP integration for the marketplace #941 — universal MCP, full scope (local + remote transports, fund-first)
• feat(plugin): ship the buyer playbook as a Claude Code plugin #938 — buyer playbook as a Claude Code plugin (the local transport)

[maxy-player]

Body revised per owner direction (1 Sep, Discord #941 ideas thread): dropped the operator float. v1 is a hosted buyer with an empty wallet; the user's Lightning payment is bridged via a NUT-04 mint quote at the seller's mint into P2PK-locked ecash on the existing NIP-17 payment path. Seller code untouched. Only buyer-side change: a pay-later award mode that skips the wallet reservation.