Quickstart

Make the first payment

Your agent can now check its spending capacity and use request_wallet_payment, the default way to pay within the rules you set:

// check_balance — read capacity and a coarse funding signal for this amount
{ "purpose": "Check capacity and funding before subscribing to data feed", "amount_cents": 4900 }

// request_wallet_payment
{
  "purpose": "Pay for the market data API subscription",
  "amount_cents": 4900,
  "recipient": "0x0000000000000000000000000000000000000001",
  "caip2": "eip155:8453",
  "idempotency_key": "datafeed-2026-07"
}

amount_cents and idempotency_key are required. All MCP input and output fields use snake_case.For your first payment to a new EVM address, caip2 is required. It accepts a CAIP-2 id or case-insensitive network name such as base. Do not guess the network: ask your human or the recipient, and check allowed_networks from get_spending_rules or get_agent_status. Later omission uses this agent’s settled history only if that address has exactly one network; a Solana-format address can infer Solana. An explicit network always wins. A new EVM recipient or ambiguous history returns CHAIN_REQUIRED with allowed networks; ask, then retry with caip2 and the same idempotency_key. Do not use a new key after a timeout or UPSTREAM_ERROR either.Use spendable_now_cents and limited_by from check_balance or get_agent_status for the enforced budget and limit gates. Both fields are nullable: if capacity cannot be read, both are null and the optional boolean capacity_unavailable is true. The flag is omitted after a successful capacity read. Wallet holdings and account data are read separately from capacity. Null capacity is unknown; retry the capacity read later. The wallet normally holds little or no balance because payments are funded just in time; its live balance is not the affordability gate. Funding can still be refused when the payment runs.A $0 agent wallet does not block payments. Supplying amount_cents to check_balance adds funding_check: { amount_cents, org_can_fund, reason, checked_at }, a coarse yes/no/unknown treasury signal with no treasury balance. It does not reserve funds; funding is re-checked at execution and ORG_TREASURY_INSUFFICIENT remains possible.Payments within the auto-approve threshold normally start executing. Other policy rules can still route them to review or deny them. An over-threshold payment normally returns status: pending with a request_id and appears in the human’s Approvals queue.Poll get_payment_status with that request_id, honoring retry_after_seconds while pending or executing. Approval runs the payment automatically; do not submit another payment. Stop polling on settled, failed, denied, or expired. The poll tool can also return not_found; check the id in that case. A settled payment is confirmed final on chain and normally includes on_chain_tx_hash. If the provider’s hash could not be captured, the hash is null and the payment is still final; stop polling.Executing is still in flight, not settled. The delay is about 10 seconds for a new executing payment, then 30 seconds; pending starts at 30 seconds and backs off to 300 seconds as it waits. For an agent-side long-poll, add wait_seconds (integer 0–60, default 0); it returns early on a status or step change or a terminal result.Use submit_approval_request only when you deliberately want a human to review before any spend, including below the threshold. It uses the same payment fields and network rules, needs only approval:request, and still enforces budget and policy limits.

Getting Started

Concepts

MCP Tools

Orchestrators

API Reference

Support

What’s next

​What’s next

What’s next