purpose (string, 3–500 characters), the reason for acting recorded in the audit log. Parameters below are in addition to purpose. Organization keys receive the separate management band.
Payments
request_wallet_payment
Requires wallet:spend.
This is the default way to pay. Use submit_approval_request only when you deliberately want a human to review first.
Above the auto-approve threshold,
status: pending with a request_id is normal. A human decides and Reinx then executes the payment automatically. Poll the request rather than creating another payment.
Do not guess the network: ask your human or the recipient. Omission uses this agent’s last settled payment to the address only when its settled history has exactly one network, or infers Solana from an unambiguous Solana address. New EVM recipients and ambiguous history return CHAIN_REQUIRED (new_recipient or ambiguous_history) with allowed_networks; ask, then retry with caip2 and the same idempotency_key. An explicit network always wins. Accepted plain names include arbitrum, base, optimism, polygon, and solana. See network selection and refusal fields.
Do not use a new idempotency_key after CHAIN_REQUIRED, a timeout, or UPSTREAM_ERROR. Retry the same logical payment with the same key; executing is still in flight, not settled.
If the owner removes Reinx’s signing access, auto-approve is suspended and payments that pass policy checks return pending_reason: owner_signature_required with a pending_message. The owner must approve and sign each hop. See the removed-access workflow.
submit_approval_request
Needs only approval:request. Use it only for deliberate human review before anything is spent, including below the auto-approve threshold. request_wallet_payment is the default way to pay. It has the same payment fields and network-selection rules, plus:
Budget and policy limits still apply. On approval the payment runs automatically; poll
get_payment_status until terminal.
get_payment_status
Requires
status:read. A positive wait_seconds long-polls for at most 60 seconds and returns early when status or step changes; terminal results return immediately. After a read timeout or upstream error, retry with the same request_id rather than submitting another payment.
Do not set the wait equal to your MCP client’s deadline. With the TypeScript SDK’s default 60-second timeout, use at most 45 seconds; for a 60-second wait, first configure the client request timeout to 90 seconds. See the client timeout example.
Wallet statuses are pending, executing, settled, failed, denied, expired, and not_found (poll only). retry_after_seconds is non-null exactly while pending or executing: about 10 seconds for a new executing payment under 60 seconds old, then 30 seconds; pending starts at 30 seconds and backs off to 300 seconds as it waits. Honor that delay. While executing, step can be funding_from_treasury, converting, submitting, confirming_on_chain, or awaiting_owner_signature. These are phases, not a strict sequence: submitting can appear before converting, and a step may repeat. Keep polling the same request_id, honoring retry_after_seconds or using wait_seconds. step is null when no detail is recorded; step_since is nullable independently.
The additive pending_reason and pending_message explain when the owner’s approval and passkey signature are required. An approved payment waiting for a signature remains executing, with step: awaiting_owner_signature: the owner must sign the next hop with their passkey; the agent cannot advance it and keeps polling the same request_id. org_signer_revoked means the owner removed Reinx’s signing access; ask the owner to sign or re-add Reinx.
settled means confirmed final on chain. The result normally includes on_chain_tx_hash; if confirmation was recorded but the provider’s hash could not be captured, the hash is null and the payment remains final. Stop polling either way. The result also includes chain_caip2 and recipient: { address, chain_caip2 } when recorded. expires_at is non-null only for a pending human decision. resolved_at is the terminal time. See Payment Workflow for the full field table and polling rules.
Both write responses and status reads include the network display name chain_name and chain_source: provided for an explicit choice, recipient_history for this agent’s settled history, or address_format for Solana inference. History-based selection includes chain_source_request_id and chain_source_settled_at; older records may have null selection context.
Balances and status
check_balance
Requires balance:read.
Returns live wallet holdings plus nullable
spendable_now_cents and limited_by. A $0 agent wallet does not block payments: payments are funded just in time. Use spending capacity rather than wallet holdings as the budget/limit gate. Pending human requests also reduce capacity available for new approval requests.
When amount_cents is supplied, funding_check contains { amount_cents, org_can_fund, reason, checked_at }. org_can_fund is true (reason: ok), false (org_treasury_insufficient), or null (over_spending_capacity or unavailable). This is a coarse yes/no signal for that amount; it exposes no organization treasury balance, shortfall, or headroom number, does not reserve money, and does not net in-flight sibling commitments. Funding is re-checked at execution; ORG_TREASURY_INSUFFICIENT remains possible after a positive check. A failed probe read or older API returns funding_check: null, meaning unknown rather than no funds.
get_agent_status
No parameters beyond purpose. Returns account status and budget, nullable spendable_now_cents and limited_by, and allowed_networks as described below.
For both capacity tools, if capacity cannot be read, spendable_now_cents and limited_by are null and capacity_unavailable is true; the flag is omitted after a successful capacity read. Wallet holdings and account data are read separately. Null capacity means unknown, not zero: retry the read later.
get_spending_rules · list_approved_merchants
No parameters beyond purpose.
get_spending_rules and get_agent_status return allowed_networks: an alphabetical list of { name, display_name, caip2 } for the current environment, with no default/recommended flag. An unavailable list is null with allowed_networks_unavailable: true; retry the read, do not guess a network. UNSUPPORTED_CHAIN errors also name the allowed networks.
While signing is suspended, get_spending_rules and get_agent_status also return auto_approve_suspended: true and auto_approve_suspended_reason: owner_signature_required. These fields are otherwise omitted. Suspension overrides the configured auto-approve threshold while Reinx’s signing access is removed.
get_wallet_addresses
Returns USDC deposit addresses by chain family (
usdc_evm, usdc_solana).
get_budget_utilization · get_spending_summary
get_spending_summary retains by_merchant, by_mcc, and by_day, and adds by_recipient for wallet recipients grouped by address and network. Each entry includes recipient, chain_caip2, chain_name, spent_cents, transaction_count, and last_settled_at. EVM addresses group case-insensitively and return lowercase; Solana case is preserved. by_recipient contains the top 20 recipient/network pairs by spend. Wallet recipients appear in both by_recipient and by_merchant; no existing field is renamed or removed. The summary window is shorter than the 365-day settled history used to infer a payment’s network.
History and feedback
get_transactions
Rows include
payment_type (wallet_transfer or card_purchase) and recipient: { address, chain_caip2 } for recorded outbound wallet payments. Wallet rows have merchant_name: null. Deposits and treasury sweeps have no outbound recipient; counterparty preserves their recorded sender or label. The type names the rail family; the row’s event_type distinguishes payments, deposits, and sweeps.
On history rows, recipient.chain_caip2 can be null when the destination network was not recorded. Do not infer a network from the address.
get_denial_feedback
Includes actionable denial reasons and human feedback.
limited_by and remaining_cents are null when the denial has no recorded budget/limit context; they are not reconstructed from today’s balances.
check_merchant_allowed
Rate limits
General tool calls are limited by plan tier. Payment tools have tighter caps: 10/min per key and 30/min per organization. Honor the delay on a429 response.