DEV Community

livepairai
livepairai

Posted on

I built an MCP server where AI agents pay for their own compute in USDC

Agents can browse docs and call APIs, but they can't do checkout. No credit card form, no OAuth dance, no "verify your email". So when I shipped an AI generation API, the interesting question was: how does an agent pay?

What I built

An MCP server (https://livepairai.com/mcp, streamable HTTP) exposing ~70 image/video models behind one interface. An agent connects, lists models with prices, calls generate, and gets back either a result or an HTTP 402 with payment requirements.

The payment rail is x402 — USDC on Base. The flow:

POST /v1/agent/generate {model, prompt}
← 402 Payment Required

x-payment-requirements: {amount: "400000", currency: USDC, chain: base, payTo} → agent signs USDC transfer, retries with X-PAYMENT header ← 200 + result URL (hosted 48h, auto-deleted)

One HTTP round-trip pattern. No API key, no account, no session — the payment signature is the credential.

What actually happens inside

  • Model catalog with live per-call pricing: GET /v1/agent/models (5s 720p video ≈ $0.40, images ≈ $0.02–0.05)
  • Quote freshness was the annoying part — prices are per-result, so the 402 response carries a short-lived quote the agent must settle before expiry
  • For humans/API keys there's a chat-completions-compatible surface instead, so integrators who want accounting get Authorization: Bearer lp_… and skip the wallet dance entirely

Failure modes I hit

  • Agents that retry the original request without attaching payment — had to make the 402 body self-describing (amount, recipient, expiry, example header) so a generic agent could act on it without me hardcoding the client
  • Wallet-funded agents settling twice on timeout — made fulfillment idempotent on the payment reference
  • The privacy constraint shaped the storage layer: renders live 48h max, never indexed, share links are a separate opt-in path gated by model

Try it

  • MCP endpoint: https://livepairai.com/mcp
  • Agent docs: https://livepairai.com/SKILL.md
  • Manifest: https://livepairai.com/v1/agent/manifest.json

If your agent has a USDC wallet, it can already use this. Curious how others are handling

Top comments (4)

Collapse
 
payload-tools profile image
Payload •

The double settle on timeout one is real, we hit the same thing. Making fulfillment idempotent on the payment reference fixed the serving side, but the other half was teaching the client to reconcile before it pays again: on timeout, check whether the first authorization already landed on chain before signing a second one. Most of the time it has, and the retry just needs the receipt, not a new payment.

Collapse
 
livepairai23 profile image
livepairai •

yeah thank you for pointing out important view

Collapse
 
payload-tools profile image
Payload •

No problem!

Collapse
 
ai_adam profile image
ai_adam •

Đúng điểm đau của agent economy hiện tại. Mình từng gặp case tương tự khi build pipeline cho autonomous research agents — chúng đọc docs, gọi API ngon lành, nhưng đến bước cần thuê GPU spot instance hoặc trả phí API premium thì deadlock vì không có ví, không có KYC.

USDC on-chain giải quyết được phần settlement, nhưng mình lo ngại về:

  1. Gas fee volatility — nếu agent phải sign nhiều tx nhỏ (per-request billing), gas có thể ăn mòn margin compute
  2. Replay/front-run risk — MCP server đóng vai payment gateway, nhưng ai audit logic "verify compute delivered → release funds"? Cần challenge period hay ZK-proof của workload?
  3. Identity & reputation — agent nào cũng có thể spin up wallet mới, nạp $5 USDC, chạy job rác rồi biến mất. Có mechanism slashing/staking không?

Mình thấy hướng prepaid credit + off-chain accounting + periodic on-chain settle (như các CDN/payment processor làm) có thể pragmatic hơn cho high-frequency micro-billing. Bạn có benchmark overhead latency khi inject payment check vào MCP request loop không? (site: labagent .tech)