Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Xrp Transfers In

xrp_transfers_in
Read-only

INCOMING XRP Ledger (xrp, XRP, ripple, XRPL) transfers to an r-address — where this account received XRP and issued tokens from, newest first: sender, amount, currency, Destination_Tag, record Type and transaction type per row. Use it to trace the source of funds backwards, and with destination_tag to list the deposits of ONE customer of an exchange account. Page back through older history with cursor: pass the Cursor value of the LAST row of a page — unlike before_time it never skips rows that share a ledger. Same record types and amount rules as xrp_transfers_out; for the aggregated view use xrp_address_flow_summary. AMOUNTS: Amount / Currency is what this account actually received (the delivered amount, never the inflated face value of a partial payment); Sent_Amount / Sent_Currency is what the sender actually spent. They differ on a cross-currency payment, and can also differ on a payment of an issued token (for example by the issuer's transfer fee). XRP is in XRP (not drops). TYPE: payment = a Payment from another account (Sender = this account means a currency conversion); trade = a standing exchange offer of this account was filled; other = one leg of an account deletion, check, escrow release, payment-channel claim, AMM or NFT sale, or path-payment rounding, so Sender is EMPTY here. Rounding remainders of that kind below 0.000001 (floating-point leftovers of token payments and offer fills, no real value; a token issuer receives hundreds of thousands) are hidden unless include_dust=1. For an account deletion, cashed check, AMM or NFT sale the paying leg is a separate record of the same transaction: open the Tx with xrp_tx_transfers to see who paid. An escrow release or payment-channel claim pays out what was locked in an EARLIER transaction, so its payer is not in that transaction. nft_trade / mint / burn = NFTs (Currency is the NFT id). Fees never appear here (the fees an account paid are listed by xrp_transfers_out with include_fees=1), and neither do failed transactions — except a failed (expired) NFT offer acceptance, which still shows its nft_trade record although the NFT did not move; xrp_tx_transfers shows Success. Pass type='payment' for payments only. CURRENCY: native XRP is always Currency_Id 413663; any other currency is an issued token, and its Currency_Id identifies only the CODE — look-alike issuers airdrop counterfeit "RLUSD", "USD" and similar tokens under the same code. Pin the real token with currency_id plus issuer (keeps payments that delivered that issuer's token). USD: Price_Usd is the hourly USD price of Currency at the time of the transfer and Value_Usd = Amount x Price_Usd - for XRP only (Price_Status ok). An issued token has no price here (Price_Status no_price, both columns null): never assume one, a currency code says nothing about the token's value. The newest hour may not be priced yet. Amounts and their filters stay in TOKEN UNITS (there is no usd filter), and amounts of different currencies must not be compared or added together: pin ONE currency with currency_id, or bound the range with min_amount / max_amount. Destination_Tag: "0" = no tag. An account whose incoming payments nearly all carry different tags is a shared (exchange / custodial) deposit account. Rows carry no labels: identify senders with labels_for_addresses(chain='ripple') — coverage is sparse, mostly exchange reserve wallets. Covers the LAST 90 DAYS by default; raise days to reach older history (a short or empty page can just mean the window ended, not that the history did). Records arrive a few minutes after the ledger closes. Returns limit transfers per page (default 20, at most 1000), newest first, plus any records identical in every field to the last one (so a page can exceed limit); a sort='amount' page is a top-N and carries no Cursor. Each row: Time, Sender, Currency, Currency_Id, Amount, Sent_Currency, Sent_Currency_Id, Sent_Amount, Destination_Tag, Type, Tx_Type, Ledger, Tx, Price_Usd, Value_Usd, Price_Status, Cursor.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "xrp_transfers_in"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoHow far back to search, in days (default 90, max 20000). The window ends at the newest bound in play (cursor or before_time, else today) and reaches `days` back from it; an explicit after_time overrides the lower edge. An empty or short page can simply mean the window ran out - raise days to search deeper.
sortNo"recent" (default) = newest first; "amount" = largest Amount first. Ranking by amount returns a TOP-N, not the head of a page-walk: such a page carries no Cursor, so start a walk with sort='recent'.recent
typeNoRecord type: "payment", "trade", "other", "nft_trade", "mint" or "burn" (see the tool description). Empty (default) = every type except fees. Any other value is rejected.
limitNoMax transfers per page (1-1000); a page can exceed it by a few rows when identical records share the last position.
cursorNoExact paging cursor: pass the Cursor value of the LAST row of the previous page to get the next page. When set, before_time is ignored and rows come back newest-first whatever sort says. Empty = first page. Records identical in every field (several equal offers filled, or a batch of NFT mints, in one transaction) always come back together, so a page can hold a few rows more than limit.
formatNoShape of the returned data. "rows" (the default) returns one item per row. "columnar" returns a single item, {"columns":[...],"rows":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.rows
issuerNoKeep only PAYMENTS that delivered a token issued by this r-address (e.g. the real RLUSD issuer rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De) — the way to separate a real token from look-alike issuers of the same code. The issuer is matched on what this account RECEIVED (Delivered_Issuer in xrp_tx_transfers). Other record types and XRP carry no issuer, so they are dropped when this is set. Empty (default) = no issuer filter.
addressYesClassic XRP Ledger account address (starts with "r", 25-35 base58 characters), case-sensitive. An X-address (starts with "X") is not accepted: split it into its classic address and destination tag first.
currencyNoRestrict to one received currency by its code as shown in Currency ("XRP", "RLUSD", "USD" or the 40-character hex code, in any letter case). A code is NOT a token identifier — several issuers use the same code — so pin the real one with issuer. Empty = all. No backslashes.
after_timeNoOnly transfers at/after this UTC time, "YYYY-MM-DD", "YYYY-MM-DD HH:MM:SS" or ISO "2026-09-20T00:00:00Z" (the form Time comes back in). Overrides the lower edge of the days window. Empty = no lower bound.
max_amountNoMaximum received amount in the currency's own units. 0 (default) = no upper bound. Amounts are NOT comparable across currencies, so with sort="amount" a token with a huge supply can push real transfers off the page - cap it here, or pin one currency with currency_id.
min_amountNoMinimum received amount in the currency's own units (XRP, not drops). 0 = no lower bound. Rounding remainders without a sender are already hidden (see include_dust); set this to drop small real transfers as well.
before_timeNoOnly transfers strictly before this UTC time ("YYYY-MM-DD", "YYYY-MM-DD HH:MM:SS" or ISO "2026-09-20T00:00:00Z" (the form Time comes back in)) — a coarse upper bound, NOT a paging cursor: it skips every row that shares the last row's timestamp, so page with cursor instead; before_time is ignored when cursor is set. Empty = now.
currency_idNoRestrict to one received Currency_Id (413663 = native XRP). Faster than currency. It identifies a currency CODE shared by every issuer of that code; add issuer to pin one token. 0 (default) = all.
include_dustNo0 (default) hides rounding remainders: records of Type "other" with no counterparty and an Amount below 0.000001 - floating-point leftovers of payments and offer fills that carry no value (a token issuer collects hundreds of thousands of them, and they would fill every page). 1 = show them too.
destination_tagNoOnly transfers carrying this destination tag (digits) — on an exchange deposit account, the deposits of one customer. Empty (default) = any.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
      +  "default": "rows",
      +  "description": "Shape of the returned data. \"rows\" (the default) returns one item per row. \"columnar\" returns a single item, {\"columns\":[...],\"rows\":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only safety, and the description goes far beyond them: fees and failed transactions are excluded (with the expired-NFT-offer exception), dust rows below 0.000001 are hidden by default, the default window is the last 90 days with a short page possibly meaning window exhaustion, records lag the ledger close by minutes, and sort='amount' pages carry no Cursor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and sibling routing, and the labeled sections (AMOUNTS, TYPE, CURRENCY, USD) make the long body navigable. It is still unusually verbose for a single tool and repeats cursor/window guidance already carried by the parameter descriptions, costing context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating every returned field and explaining Amount vs Sent_Amount, Price_Status/Value_Usd nullability, and per-page limit behaviour. For a 16-parameter tool, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 is the floor, and the description still adds cross-parameter meaning the schema doesn't assemble: currency_id identifies only a code while issuer pins the real token (counterfeit RLUSD warning), amounts are not comparable across currencies, cursor vs before_time trade-offs, and destination_tag='0' semantics. It is somewhat duplicative of the already-rich schema text, so not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb+resource and scope (incoming XRPL transfers to an r-address, newest first) and even lists the row shape. It explicitly positions itself against siblings xrp_transfers_out and xrp_address_flow_summary, so an agent can pick it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete use cases (trace source of funds backwards; destination_tag to isolate one customer's deposits), names the alternatives and when to prefer them (xrp_transfers_out for fees, xrp_address_flow_summary for the aggregated view, xrp_tx_transfers to find the payer of the other leg, labels_for_addresses for sender identity).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.