Skip to content
GitHub

Request and transaction boundary

Preview

The hosted Stele MCP exposes stele_create_booking_draft, but production search returned 0 published services during the July 16, 2026 release validation. Because the tool requires a real listing, no successful booking-approval draft is currently possible; invalid or unavailable listing IDs fail closed. Once a listing exists, the tool can return a short-lived, nonbinding wallet-owned review URL at stele.monolythium.com. The review surface cannot approve the draft, send it to a provider, or turn it into a transaction. Booking, payment, escrow, dispute, and reputation writes remain unavailable.

This booking-approval draft is different from a private provider-listing draft in the Studio. Studio drafts are unpublished, remain outside catalog search, do not satisfy the hosted booking tool’s published-listing prerequisite, and cannot be listed, read, updated, deleted, or published through either MCP surface.

The hosted booking-approval draft is nonbinding. It is not a booking, contract, reservation, quote acceptance, invoice, payment instruction, escrow, or provider commitment. It does not lock funds or submit an economic transaction.

Booking-approval flow once a published listing exists

Section titled “Booking-approval flow once a published listing exists”

Production currently has no published listing with which to complete this flow.

  1. Select a real published listing.
  2. Connect Codex or Claude Code and complete OAuth authorization in the browser.
  3. Ask the client to call stele_create_booking_draft with a listing ID, workflow kind, and requested units.
  4. Open the returned Stele action URL and authenticate with the same wallet address.
  5. Review the typed draft. The approval control remains disabled, the draft expires, and no on-chain state changes.

Wallet login and draft creation are separate events. The login signature is an authentication proof only; it cannot authorize a later payment or settlement action.

Stele does not currently expose any of these actions:

  • accept or counter a booking;
  • reserve provider availability;
  • quote or collect a platform fee;
  • sign or submit a payment;
  • lock or release escrow;
  • choose or notify an arbiter;
  • open or resolve a dispute;
  • write a receipt, rating, or reputation record.

The service is pinned to public testnet 69420, with economic writes and hosted signing disabled. Testnet status does not turn a UI demonstration into a transaction.

Do not include secrets, identity documents, medical or legal records, payment credentials, or sensitive attachments in a preview inquiry. End-to-end encrypted rooms and file exchange are not available yet. A future E2EE design must be documented and independently verified before this warning changes.

If economic actions are released later, every action must show the network, asset, amount, recipient, fees, expiry, settlement semantics, and exact signed payload before approval. The application must reread relevant state and simulate the final transaction immediately before the wallet prompt. A hosted service must never sign on the user’s behalf.

Local-agent execution remains a separate, gated design using a dedicated agent wallet and explicit policy controls. It must not reuse a person’s primary wallet or reinterpret an inquiry as permission to spend.