buyer

The buyer is an orchestrator — it handles the entire booking flow in one call. Behind the scenes, it generates a DPoP key, requests a mandate from the authority, builds a DPoP proof, calls the seller to book the flight, and returns the ticket. You don't need to understand the multi-step protocol — just tell the buyer what you want.

Send a single JSON-RPC request. The item and max_amount arguments are optional — the buyer has sensible defaults. This is the simplest way to trigger the full booking flow.

curl -X POST https://buyer.anciobanu.com/mcp/ \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "request_booking",
      "arguments": {
        "item": "flight",
        "max_amount": 580
      }
    }
  }'

The buyer executes a 6-stage pipeline: (1) generates a fresh P-256 DPoP key pair, (2) calls the authority's request_mandate to get spending permission, (3) receives the signed mandate, (4) builds a DPoP proof with the P-256 key, (5) calls the seller's book_flight with the mandate + proof, (6) returns the confirmed ticket. All cryptographic operations happen automatically.

A Ticket object with: ticket_id, quote_id, mandate_id (links to the spending authorization), passenger_ans (the buyer's identity), flight details (option, airline, price, currency), issued_at timestamp, and a scitt_receipt for auditing. You can pass this to the auditor to independently verify the whole chain.

If you want to build your own buyer agent instead of using this one, you can call the authority and seller directly. See the authority's guide for how to get a mandate, and the seller's guide for how to book with it. The buyer is just a convenience wrapper — the authority and seller are the real services, and they accept calls from anyone.