Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Arc Transfers In

arc_transfers_in
Read-only

INCOMING Arc (arc, ARC, Arc Network, Circle Arc) transfers to an address — where this wallet received funds from. NOT the opposite direction → use arc_transfers_out. NOT totals per sender → use arc_address_flow_summary. Returns up to limit transfers (default 20, at most 10000), newest first by default; page back with the last row's Cursor. Use to trace the source of funds backwards. For an address with many transfers set min_amount or sort='amount', else large sources hide behind recent dust. Query WITHOUT a currency filter to see where the bulk of funds originated. To identify counterparties, pass the returned addresses to labels_for_addresses. Each row carries the token Contract — a symbol alone can match look-alike clones, so pin the real token with the contract param. Amount is in TOKEN UNITS; amounts of different tokens must never be added together. Each row also carries Price_Usd - the token's USD price at the time of the transfer - and Value_Usd = Amount x Price_Usd, with Price_Status: "ok"; "no_price" = no price is known for this token at that time, so Price_Usd and Value_Usd are empty (never read that as zero); "suspect" = the stored price is more than twice the price one day earlier AND one day later, or less than half of both - a likely data glitch - so Value_Usd is left empty - check the price with price_at. A token has ONE price per day, so its value is approximate. USDC ON ARC IS NOT PRICED HERE: the native coin and the ERC-20 at 0x3600000000000000000000000000000000000000 always read no_price - it is USDC, so price it as USDC on Ethereum with price_at. There is no usd filter: min_amount / max_amount are in token units. For a ranking you can reason about, pin ONE token with contract, or bound the range with min_amount / max_amount. Amount_Raw is the exact amount as an integer in the token's smallest unit and Decimals its scale (Amount = Amount_Raw / 10^Decimals); Block and Tx_Index place the row in the chain. Every row carries Native (1 = the native coin) next to Contract, and Internal = 1 marks a transfer moved by contract code inside a transaction. On Arc most USDC moves through contract code, so internal transfers are counted by default; pass include_internal=0 for top-level transfers only. A transaction's own transfer is top-level, not internal. USDC ON ARC IS ONE ASSET WITH TWO INTERFACES that share a single balance: the NATIVE coin that pays for gas (Native = 1, no contract, 18 decimals) and the ERC-20 token at 0x3600000000000000000000000000000000000000 (6 decimals). Each movement is listed once, under the interface that carried it, so the two together are the address's USDC flow - asset_type="usdc" selects both at once, and Contract tells you which interface a row used. Over a thousand OTHER contracts on this chain print the symbol USDC too and they are unrelated tokens: never identify an asset by its symbol, use Contract and Native. System rows that only repeat a USDC movement already listed here are left out, so nothing is counted twice. Symbol_NonAscii = 1 flags a symbol that is not plain ASCII: normal for CJK / emoji names, also how a look-alike imitates a major token. Each row: Time, Sender, Currency, Symbol_NonAscii, Contract, Native, Amount, Internal, Tx, Cursor, Amount_Raw, Decimals, Block, Tx_Index, Price_Status, Price_Usd, Value_Usd.

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": "arc_transfers_in"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNo"amount" = largest transfers first; "recent" (default) = newest 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
limitNoMax transfers (ordered by `sort`; default newest first). At most 10000.
cursorNoExact paging cursor: pass the Cursor value of the LAST row of the previous page to get the next page. Prefer this over before_time, which skips any rows sharing the last row's timestamp (busy addresses often have hundreds in one second). When set, before_time is ignored and rows come back newest-first whatever sort says. Empty = first page.
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
addressYesWallet/contract address, 0x-hex (case-insensitive).
contractNoRestrict to ONE exact token by its contract address (0x-hex, case-insensitive) — the reliable way to pin a token, since a currency symbol also matches clone tokens. Pass "native" for the native USDC coin only (the 18-decimal interface; asset_type=usdc selects both interfaces of USDC). Empty = no token filter.
currencyNoRestrict to one currency symbol. NOT an identifier — several tokens can share a symbol, so this alone may match a counterfeit; pin the real one with contract. Empty = all. No backslashes. On Arc the symbol "USDC" also matches over a thousand unrelated contracts, so it is not an asset filter - pass asset_type=usdc for the gas asset itself (both of its interfaces), or pin one contract.
after_timeNoOnly transfers at/after this UTC time. Empty = no lower bound. Format: YYYY-MM-DD, YYYY-MM-DD HH:MM[:SS], ISO-8601 like 2026-09-20T00:00:00Z (fraction or +02:00 offset allowed) or 10-digit unix seconds.
asset_typeNoRestrict to one kind of asset. all (default) = tokens and the native USDC coin; native = only the native USDC coin (18 decimals); token = only tokens, the 6-decimal ERC-20 USDC included; usdc = the gas asset through BOTH of its interfaces at once - the native coin and the ERC-20 at 0x3600000000000000000000000000000000000000 - which is the whole USDC flow of an address.all
max_amountNoMaximum transfer amount (token units). 0 (default) = no upper bound. Amounts are in each token's own units and are NOT comparable across tokens, so with sort="amount" a token with inflated or wrong decimals can report billions of units and push real transfers off the page - cap it here, or pin one token with contract.
min_amountNoMinimum transfer amount (token units). 0 = all.
before_timeNoOnly transfers strictly before this UTC time — a coarse upper bound, NOT a paging mechanism (it drops every row sharing the last row's timestamp). Page with cursor instead. Ignored when cursor is set. Empty = no upper bound. Format: YYYY-MM-DD, YYYY-MM-DD HH:MM[:SS], ISO-8601 like 2026-09-20T00:00:00Z (fraction or +02:00 offset allowed) or 10-digit unix seconds.
include_internalNo1 (default) = also count USDC moved by contract code deeper inside a transaction (an internal transfer, for example through a batch sender or a withdrawal contract); 0 = top-level transfers only - the transfer a transaction makes itself, plus token transfers. On Arc most USDC moves through contract code, so internal transfers are counted by default. Only 0 or 1.

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. Changed1 schema field changed
    • changedInput schema / properties / before_time / description
      Previous value: -"Only transfers strictly before this UTC time — page back through history by passing the oldest Time of the previous page. Empty = no upper bound. Format: YYYY-MM-DD, YYYY-MM-DD HH:MM[:SS], ISO-8601 like 2026-09-20T00:00:00Z (fraction or +02:00 offset allowed) or 10-digit unix seconds."New value: +"Only transfers strictly before this UTC time — a coarse upper bound, NOT a paging mechanism (it drops every row sharing the last row's timestamp). Page with cursor instead. Ignored when cursor is set. Empty = no upper bound. Format: YYYY-MM-DD, YYYY-MM-DD HH:MM[:SS], ISO-8601 like 2026-09-20T00:00:00Z (fraction or +02:00 offset allowed) or 10-digit unix seconds."
  3. Changed1 schema field changed
    • changedInput schema / properties / contract / description
      Previous value: -"Restrict to ONE exact token by its contract address (0x-hex, case-insensitive) — the reliable way to pin a token, since a currency symbol also matches clone tokens. Empty = no token filter."New value: +"Restrict to ONE exact token by its contract address (0x-hex, case-insensitive) — the reliable way to pin a token, since a currency symbol also matches clone tokens. Pass \"native\" for the native USDC coin only (the 18-decimal interface; asset_type=usdc selects both interfaces of USDC). Empty = no token filter."
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/destructiveHint, and the description adds substantial behavior beyond that: Price_Status semantics including the 'no_price' vs 'suspect' cases and the rule that empty is never zero, the USDC-on-Arc dual-interface single-balance model, the fact that system rows are de-duplicated, and the warning that over a thousand clone contracts print 'USDC'. These are non-obvious traits an agent would otherwise get wrong.

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

Conciseness3/5

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

The first two lines are exemplary — scope, then the two alternatives — but the body then runs long and repeats material already in the parameter schema (USDC interfaces, Price_Status, amount units, cursor-vs-before_time appear in both). The all-caps warnings aid scanning, but several sentences could be trimmed without losing information.

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?

For a 13-parameter tool with no output schema, the description enumerates every returned field (Time, Sender, Contract, Native, Amount, Internal, Tx, Cursor, Amount_Raw, Decimals, Block, Tx_Index, Price_Status, Price_Usd, Value_Usd) and explains the non-obvious ones. Nothing an agent needs to call or interpret the result is missing.

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 the schema already documents each parameter. The description nonetheless adds cross-parameter reasoning the schema states less prominently: pinning a token with contract rather than symbol, that min/max_amount are in non-comparable token units so sort='amount' can be skewed by bad decimals, and that asset_type='usdc' selects both interfaces. Some of this is restated from the schema, which keeps it below 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?

Opens with a precise verb+resource+scope: 'INCOMING Arc transfers to an address — where this wallet received funds from.' It explicitly names the two nearest siblings it is not (arc_transfers_out for the opposite direction, arc_address_flow_summary for per-sender totals), so an agent can disambiguate without reading any 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 when-to-use guidance ('trace the source of funds backwards'), when-to-adjust (set min_amount or sort='amount' on busy addresses, drop the currency filter to see bulk origin), and named handoffs (labels_for_addresses for counterparties, price_at for suspect prices). It also states the correct paging mechanism (cursor, not before_time) and when internal transfers should be excluded.

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.