Skip to main content
​
The MCP server can now create and change cards, with an mcp:write key

​
createUserCards and updateUserCard — the first writes

The MCP server used to be read-only. Two tools now change something, and both need the new mcp:write scope, checked on every call. Existing keys are unaffected: without the scope a key connects exactly as before, and is refused only when a write is attempted.Scopes are fixed when a key is created and can’t be added to an existing one. To start writing, create a new key at Settings → API keys with MCP + Write selected, then revoke the old one.

​
createUserCards

Creates one card, or queues a batch of up to 30. A single card comes back immediately; a batch doesn’t, since issuing thirty cards outlives the request. You get a batchId instead, and call the same tool with that id to read the batch’s progress (cardsCreated, cardsFailed, cardIds). Nothing is created when batchId is set.Retrying is safe without an idempotency key: a batch already running with the same recipe and size is returned (alreadyRunning: true) rather than queued a second time.Name a batch with nicknamePrefix (plus optional nicknameStartAt and nicknamePadding) — nickname would repeat the same label on all 30 cards.Bulk is a business-account feature. Without it, a quantity above 1 creates one card and the response says so — created, requested and bulkUnavailable: true, alongside the card.

​
updateUserCard

Changes one card per call: status, nickname, spendingLimit, spendingInterval. It returns the card’s state after the change, so you don’t have to list cards again to see the result.canceled is permanent. To stop a card temporarily, use inactive or locked — both reversible with active.

​
One less id to pass

You no longer need to send a cardIssuerUserId: if your account has a single card-issuer account it’s filled in for you. If it holds more than one, the tool lists the ids you can choose from.
​
getCashbackSummary: cashback, with pending broken out

​
getCashbackSummary — your LootRush Rewards cashback

Cashback was visible on the site but nowhere in the API. The new getCashbackSummary returns it across every enrolled card-issuer account, and it also comes back as a cashback section on getAccountBalance and getUserCards — the same treatment cardBalance gets.

​
Four cashback balances, not one “pending”

Cashback isn’t a single balance with a pending amount. It has four states, and only one of them is money the cardholder can use today:total is the headline (available + redeeming), taken as-is from the same source the site shows, so it can’t drift from it.Also returned: expiring (the soonest slice about to lapse), and monthProgress — this month’s spend buckets with their rate ladder, which is what answers “what rate am I on”.

​
enrolled: false is not “zero”

An account with no cashback-active card issuer gets zeros and enrolled: false. Those zeros mean cashback is not switched on, which is a different answer from earned nothing. Read the flag before quoting the number.

​
No card ids

The tool takes no cardId or cardIssuerUserId — enrollment is resolved from your identity server-side. The only parameter is an optional month (YYYY-MM) for the rate ladder.

​
Currencies are never added together

If your accounts disagree about currency, the headline fields stay zero and a byCurrency array carries the real per-currency split.
​
aggregate: totals without paging

​
aggregate — totals over your whole slice, in one call

The listing tools return rows, so answering “how much did I spend last month” meant paging every one of them and adding up client-side — slow, and wrong the moment a page is missed. The new aggregate tool returns the number instead, computed over the whole filtered set.
  • Ops: sum, count, avg, min, max, median.
  • Break it down by a column (groupBy) or by time (timeBucket: day, week, month).
  • Sources: cardTransactions and accountHistory.

​
Listing responses now carry a datasetId

getUserCardTransactions and getAccountHistory return a datasetId alongside their rows, plus aggregatable, groupable and ops describing what you can ask of them.Pass that handle to aggregate and the total covers exactly the slice you just listed — the handle stores that call’s filters, never its rows, and expires after 15 minutes. You can also skip the listing entirely and pass source + filters straight to aggregate.

​
Three things to know about the numbers

  • A partial result says so. If the slice exceeded the row cap the response carries complete: false with the coverage it does have. Check it before quoting the number.
  • Currencies are never merged. Amounts in different currencies come back as separate entries.
  • Declined card attempts don’t count as spend. Money columns on cardTransactions are split by status unless you pin one — only settled (and on_hold, still authorising) is money that left the account.
Read-only and scoped to your own account, like every other tool.
​
MCP card tools + card balance

​
New card tools on the MCP server

Three new read-only tools give your AI assistant a full view of your card balance and its history — the data the LootRush app shows, now available over MCP.
  • getUserCardBalanceMovements — your card balance (collateral) ledger. Each entry carries its running balance and previous balance — the statement-style running total that card transactions don’t include. Results are grouped per card issuer so each running-balance series stays coherent. Optional cardIssuerUserId, page/pageSize, startDate/endDate.
  • getUserCardSummary — a point-in-time snapshot of your cards: per-card balance, status, and limits as of any instant (asOf, defaults to now).
  • getUserCardBalanceAutomation — your spending-limit auto-refill history: each automatic balance top-up (amount, status, retries, on-chain tx hash, and when it ran).
All three are read-only and scoped to your own account.

​
Card balance now in getAccountBalance and getUserCards

Both tools now return a normalized cardBalance block — { total, pendingDeposit, pendingWithdraw } — the card collateral shared across your cards. In getAccountBalance it is reported as its own bucket and is not added into totalUsdValue (which stays crypto + tokenized + available wallet stablecoins).The getAccountBalance reference now also covers the availableStableUsdValue and stableCoins fields (your live on-chain wallet stablecoins), and getUserCards returns the raw balances payload alongside cardBalance when you need the licensed / non-licensed split.See the MCP Server reference for the full field and parameter tables.