"Cardano" matching MCP tools:

• ada_address_profileA

  Bitquery: Crypto & Blockchain DataA

  Cardano (ada, ADA, cardano) address PROFILE, one row per asset: total received, sent and current balance of ADA and of every native token at this address, receiving / spending output and transaction counts, first / last activity, plus the address type, whether it is a script, its Stake_Key and its distinct senders / receivers. Use to triage a Cardano address during tracing - how much flowed, what it holds now, who controls it. NOT who it deals with → use ada_address_flow_summary. Cardano outputs carry several assets at once, so every amount is PER ASSET and amounts of different assets are never added together. currency="ADA" (default) returns the ADA row; currency="" lists every asset, most active first. ADA amounts are in ADA, not lovelace. A token amount is scaled by the token's registered decimals when they are known (Decimals > 0); most tokens have none registered, and their amounts are raw on-chain units. Never USD - for the ADA price use currency_price with currency_id "ada". Received / Sent are cumulative TURNOVER, not holdings: every output ever paid to the address (its own change included - Cardano does not mark change) and every input it spent, so the same coins count again each time they pass through and a busy exchange wallet's totals can exceed the ADA supply. Balance = received minus spent at THIS address only. A wallet usually spreads its funds over many addresses that share one Stake_Key, and staking rewards are not included until withdrawn. Balance is empty for stake addresses and for an asset whose recorded history does not reconcile (more spent than received - typically a token without an on-chain identity, Currency_Id with an empty Asset_Fingerprint). Stake_Key (stake1...) is the staking credential of a base address: different payment addresses that share one Stake_Key almost always belong to the same wallet. Byron (Ae2... / Ddz...) and enterprise (addr1v... / addr1w...) addresses have none. When the staking part is a script (addr1x... / addr1y...), Stake_Key is spelled stake1u... here while explorers show the same account as stake17... - either spelling works as address. Is_Script = 1: the funds are controlled by a script - a smart contract (DEX pool, order book, lending) or a multi-signature wallet; for a stake address only the stake17... spelling reports it. Distinct_Senders / Distinct_Receivers count counterparties across all assets, the address itself included when a transaction pays back to it. Role from the ratio: senders >> receivers = consolidator, the reverse = distributor, thousands of both = a hub (exchange or contract - do not trace deeper). The whole history is read, so a busy exchange or DEX address can take a while - retry on a timeout. No address labels are returned here: identify the address with labels_for_addresses(chain='cardano') in one call - it holds the proof-of-reserves wallets of the large exchanges, and an empty answer there is a coverage gap, not a clean address. Data lags the chain by a few minutes.

  ConnectorOAuth

• ada_address_flow_summaryA

  Bitquery: Crypto & Blockchain DataA

  ADDRESS FLOW SUMMARY / top counterparties of a Cardano (ada, ADA, cardano) address in one call: address type, Is_Script, Stake_Key, lifetime receiving / spending transaction counts and distinct senders / receivers, plus TOP RECEIVERS (the recipients of its recent spending transactions, itself excluded) and TOP SENDERS (the input addresses of its recent receiving transactions). NOT only the statistics, without counterparties → use ada_address_profile. Call this FIRST when triaging a hop; use ada_flow_edges for the full edge list and older periods. Role reflects the LIFETIME counts (Receiving_Txs, Spending_Txs, Distinct_Senders, Distinct_Receivers, all assets), not the max_txs scan: receive_only (it never spent anything) / send_only (spends with no recorded receipt) / no_transfers (neither) / hub (thousands of senders AND receivers — an exchange or contract, don't trace deeper) / consolidator (senders ≫ receivers) / distributor (receivers ≫ senders) / relay (neither dominates). The distinct counts include the address itself when a transaction pays change back to it. READING THE TOP ARRAYS: positional 7-tuples [counterparty, amount, currency, asset_fingerprint, txs, same_stake_key, symbol_nonascii] (the Top_Fields column lists these names in the same order), one entry per (counterparty, asset), largest amount first (most txs first when currency is empty), equal entries in a fixed order. For a receiver, amount = what it received in those transactions; for a sender, amount = the value of ITS inputs in those transactions, which can include its own change. Cardano outputs are not labeled as change: an output that returns to the payer counts as a recipient like any other. So the address's own spending transactions count as receiving transactions when it gets change back, and the addresses it spends together with show up as senders; same_stake_key = 1 marks an address of the same wallet, not a real counterparty. currency="ADA" (default) ranks ADA; a token fingerprint (asset1...), policy id or Currency_Id ranks that token; currency="" gives one entry per (counterparty, asset) ranked by txs, and amounts of different assets must not be compared or added. ADA amounts are in ADA, not lovelace. A token amount is scaled by the token's registered decimals when they are known (Decimals > 0); most tokens have none registered, and their amounts are raw on-chain units. Never USD - for the ADA price use currency_price with currency_id "ada". SCOPE: the arrays cover the most recent max_txs spending and max_txs receiving transactions (default 1000 each) - Spend_Txs_Scanned / Receipt_Txs_Scanned and the Oldest_* times state what was read; the lifetime counts cover the whole history but come from the same aggregate as the arrays, so they can run slightly below ada_address_profile, which is exact. On a script address (DEX pool, order book) the counterparties are the contract's users. A small share of transactions (a few hours of blocks in March 2023 among them) is missing from this aggregate, and so are most outputs of a token MINTED in the same transaction (freshly minted tokens, LP and receipt tokens rarely show up as token edges); ada_tx_flow on a single transaction is always complete. Stake_Key (stake1...) is the staking credential of a base address: different payment addresses that share one Stake_Key almost always belong to the same wallet. Byron (Ae2... / Ddz...) and enterprise (addr1v... / addr1w...) addresses have none. No address labels are returned here: identify the address and its counterparties with labels_for_addresses(chain='cardano') - pass Address and the Top_Receivers / Top_Senders counterparties in ONE call; an empty answer there is a coverage gap, not a clean address. For the full labelled list in USD, totals by label type, or a set of addresses → counterparties.

  ConnectorOAuth

• ada_address_receivedA

  Bitquery: Crypto & Blockchain DataA

  INCOMING Cardano (ada, ADA, cardano) outputs of an address - every asset amount it received (tx, output index, Direction, time), newest first. Indexed by address (fast). Use to see what an address received and in which transactions. NOT what this address spent → use ada_sent_from_address. NOT sums over its whole history → use ada_address_flow_summary or ada_address_profile. Returns up to limit rows (default 20, at most 1000), newest first; page back with the last row's Cursor - a page shorter than limit is the last one. Set sort='amount' with one asset selected for the largest receipts instead: a top-N page with no Cursor. One row per asset per output: an output carrying ADA plus two tokens is three rows sharing Tx and Output_Index. currency="ADA" (default) returns the ADA rows; pass a token fingerprint (asset1...), policy id or Currency_Id to follow a token, or currency="" for every asset. Amounts of different assets are never added together. ADA amounts are in ADA, not lovelace. A token amount is scaled by the token's registered decimals when they are known (Decimals > 0); most tokens have none registered, and their amounts are raw on-chain units. Never USD - for the ADA price use currency_price with currency_id "ada". Direction: not_change / unknown for ordinary outputs - Cardano outputs are NOT labeled as change, so not_change does not mean a payment from someone else: often it is the address's own change coming back in a transaction it spent in (compare with ada_sent_from_address, or open the Tx with ada_tx_flow). stake_registration rows are staking deposits to a stake1... address, not payments. NOTE: a UTXO output has no single sender. To see who paid, open the Tx with ada_tx_flow - its inputs are the payers. Data lags the chain by a few minutes. `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, Tx, Output_Index, Direction, Currency, Symbol_NonAscii, Asset_Fingerprint, Policy_Id, Currency_Id, Decimals, Amount, Cursor.

  ConnectorOAuth

• ada_flow_edgesA

  Bitquery: Crypto & Blockchain DataA

  MONEYFLOW GRAPH EDGES out of a Cardano (ada, ADA, cardano) address: Source -> Target, where the targets are the recipients of the transactions this address spent in (every output except those back to the address itself), per asset - Amount, Txs, Target_Stake_Key and Same_Stake_Key (1 = the target shares the source's staking credential, so it is most likely the same wallet rather than a counterparty). Building block for a MoneyFlow DIAGRAM - call per address / hop, collect edges, render Mermaid `graph LR`, stop at exchange nodes. NOT one transaction's outputs → use ada_tx_flow. NOT its spending transactions one by one → use ada_sent_from_address. Returns up to limit rows (default 20, at most 500), one per recipient and asset, largest Amount first. currency="ADA" (default) gives ADA edges; pass a token fingerprint (asset1...), policy id or Currency_Id to follow a token, or currency="" for one edge per (target, asset) - then edges of different assets are not comparable and are ranked by Txs. ADA amounts are in ADA, not lovelace. A token amount is scaled by the token's registered decimals when they are known (Decimals > 0); most tokens have none registered, and their amounts are raw on-chain units. Never USD - for the ADA price use currency_price with currency_id "ada". NOTE: in UTXO every recipient of a spend transaction is attributed to the spending address; on a script address (DEX pool, order book) the edges are the contract's users. Cardano outputs are not labeled as change: an output that returns to the payer counts as a recipient like any other. Change sent to the wallet's other addresses therefore appears as an edge: Same_Stake_Key = 1 marks it for base addresses; for Byron / enterprise addresses check ada_related_addresses. SCOPE: reads the address's most recent max_txs spending transactions (default 1000). Two scope columns on every row state what was covered (how many of those transactions were read and the time of the oldest one); a non-empty Next_Cursor means older transactions may exist - pass it as cursor to continue with the next older batch. When nothing matched in the transactions read, ONE row comes back with an empty address column that carries only these scope columns - that means nothing in this batch, not in the whole history. A small share of transactions (a few hours of blocks in March 2023 among them) is missing from this aggregate, and so are most outputs of a token MINTED in the same transaction (freshly minted tokens, LP and receipt tokens rarely show up as token edges); ada_tx_flow on a single transaction is always complete. The edges carry no labels: identify the Targets with labels_for_addresses(chain='cardano') in one call and stop at exchange nodes; an empty answer there is a coverage gap, not a clean address. `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: Source, Target, Target_Stake_Key, Same_Stake_Key, Currency, Symbol_NonAscii, Asset_Fingerprint, Policy_Id, Currency_Id, Decimals, Amount, Txs, Spend_Txs_Scanned, Oldest_Spend_Time, Next_Cursor.

  ConnectorOAuth

• ada_mintsA

  Bitquery: Crypto & Blockchain DataA

  MINT AND BURN history of a Cardano (ada, ADA, cardano) native token or NFT collection: every mint (positive Amount) and burn (negative Amount) with time and transaction, newest first. Use for "when and how much of token X was minted / burned", supply changes, NFT drops. Pin the token with currency: its fingerprint (asset1..., one asset) or its 56-hex policy id (every asset of that policy - e.g. a whole NFT collection), or a Currency_Id returned by the other ada tools. A ticker is accepted but is not unique - check Asset_Fingerprint. Native ADA is never minted. ADA amounts are in ADA, not lovelace. A token amount is scaled by the token's registered decimals when they are known (Decimals > 0); most tokens have none registered, and their amounts are raw on-chain units. Never USD. SCOPE: the last `days` days (default 365), counted back from today on the first page and from the cursor on every next page - so a page walk keeps going back past the first window, and a page shorter than limit only means that window ran out: pass its last Cursor to look further back, or use days=0. days=0 reads the whole history, which is slower (may time out - retry). The minter and the recipients are not in these rows - open the Tx with ada_tx_flow (its outputs receive the minted tokens). Net supply created = the sum of Amount over the whole history (days=0). Data lags the chain by a few minutes.

  ConnectorOAuth

• ada_related_addressesA

  Bitquery: Crypto & Blockchain DataA

  LIKELY SAME-OWNER Cardano (ada, ADA, cardano) addresses (common-input heuristic): addresses whose inputs were spent together with this address's inputs in the same transactions. NOT the addresses it paid → use ada_flow_edges. Same_Stake_Key = 1: shares this address's staking credential - near-certain same wallet. Co_Input_ADA is ADA only; tokens are not summed. Returns up to limit rows (default 20, at most 500), most Shared_Txs first. Use to expand an address into its wallet during tracing. CAVEATS: on a SCRIPT address (addr1w..., addr1z..., addr1x... - a DEX pool, order book or other contract) co-spending is NOT ownership: every user of the contract spends together with it, so the list is its users. Use ada_address_flow_summary for such an address. Batching services and shared exchange wallets break the heuristic the same way. Stake_Key (stake1...) is the staking credential of a base address: different payment addresses that share one Stake_Key almost always belong to the same wallet. Byron (Ae2... / Ddz...) and enterprise (addr1v... / addr1w...) addresses have none. SCOPE: reads the address's most recent max_txs spending transactions (default 1000). Two scope columns on every row state what was covered (how many of those transactions were read and the time of the oldest one); a non-empty Next_Cursor means older transactions may exist - pass it as cursor to continue with the next older batch. When nothing matched in the transactions read, ONE row comes back with an empty address column that carries only these scope columns - that means nothing in this batch, not in the whole history. A small share of transactions (a few hours of blocks in March 2023 among them) is missing from this aggregate; ada_tx_flow on a single transaction is always complete. No address labels are returned here: identify the related addresses with labels_for_addresses(chain='cardano') in one call; an empty answer there is a coverage gap, not a clean address. Each row: Related_Address, Stake_Key, Same_Stake_Key, Shared_Txs, Co_Input_ADA, Spend_Txs_Scanned, Oldest_Spend_Time, Next_Cursor.

  ConnectorOAuth

• ada_tx_flowA

  Bitquery: Crypto & Blockchain DataA

  Full flow of one or several Cardano (ada, ADA, cardano) transactions, per asset: every INPUT (payer address and amount; staking-reward withdrawals appear as inputs from a stake1... address with Note withdrawal, a returned stake deposit with Note stake_deregistration), every OUTPUT (receiver and amount; a staking deposit is an output to the stake1... address with Note stake_registration, other protocol deposits are outputs with an empty Address and Note deposit), tokens MINTED or BURNED (Side=mint, a burn has a negative Amount) and the transaction FEE (Side=fee, in ADA). THE hop primitive for Cardano tracing: follow a receiver to its own spends (ada_sent_from_address) and repeat. Outputs are not labeled as change (Note not_change / unknown on ordinary outputs): an output back to one of the transaction's input addresses, or to an address with the same Stake_Key, is the payer's change, not a recipient. One row per asset: an output carrying ADA and two tokens is three rows with the same Position. Per transaction and asset the rows balance: for ADA, inputs = outputs + fee; for a token, inputs + minted (burns negative) = outputs. ADA amounts are in ADA, not lovelace. A token amount is scaled by the token's registered decimals when they are known (Decimals > 0); most tokens have none registered, and their amounts are raw on-chain units. Never USD - for the ADA price use currency_price with currency_id "ada". Stake_Key (stake1...) is the staking credential of a base address: different payment addresses that share one Stake_Key almost always belong to the same wallet. Byron (Ae2... / Ddz...) and enterprise (addr1v... / addr1w...) addresses have none. tx_hash is the 64-hex transaction id as returned by the other ada tools; pass up to 50 separated by "|" - the Tx column attributes each row. currency="" (default) returns every asset. No address labels are returned here: identify the inputs and outputs with labels_for_addresses(chain='cardano') in one call; an empty answer there is a coverage gap, not a clean address.

  ConnectorOAuth

• chain_list_tablesA

  Bitquery: Crypto & Blockchain DataA

  TABLES of one per-chain transfer database (list the tables of eth, bsc, polygon, tron, solana, bitcoin …) — the SHOW TABLES equivalent for eth_api, bsc_api, matic_api (Polygon), arbitrum_api, base_api, optimism_api, robinhood_api, arc_api, tron_api, solana, bitcoin, bitcoin_flow, ripple / ripple_flow (XRP Ledger), cardano / cardano_flow, altcoin / altcoin_flow (Litecoin, Dogecoin and Dash in one database), bitcash / bitcash_flow (Bitcoin Cash) and stellar — with each table's engine, sort key, partition key and approximate row count (Total_Rows; empty for most solana, bitcoin, ripple, cardano, altcoin and stellar tables, where no quick count exists). Only the tables you should query are listed, under the name to use in SQL. The sort key is what makes raw SQL fast: filter on its LEADING columns first (e.g. the address of transfers_sender / transfers_receiver, the transaction hash of the *_tx tables); a query that skips them scans far more data and may time out. Next steps: chain_describe_table for one table's columns, chain_search_columns to find which table has a column, then that chain's <chain>_transfers_raw_sql to run the SQL (bitcoin and bitcoin_flow → btc_transfers_raw_sql, matic_api → matic_transfers_raw_sql, ripple* → xrp_transfers_raw_sql, cardano* → ada_transfers_raw_sql, altcoin* → ltc_ / doge_ / dash_transfers_raw_sql with the chain's blockchain_id filter, bitcash* → bch_transfers_raw_sql, stellar → xlm_transfers_raw_sql). Prefer a specialized per-chain tool whenever one answers the question — chain_capabilities lists them. For trading_rt (DEX trades, prices, OHLC bars) use list_tables; list_databases describes every database.

  ConnectorOAuth

• labels_for_addressesA

  Bitquery: Crypto & Blockchain DataA

  BATCH label lookup for a LIST of addresses — label many wallets, counterparties or holders in ONE call: each labeled address comes back with all its on-chain labels (entity / category / CEX-deposit / mixer / scam / token-clone / …). Use to label any set of addresses you already have — e.g. the counterparties returned by a transfer / flow / holders tool. Those rows carry NO label field on Ethereum, BSC, Polygon, Arbitrum, Base, Optimism, Tron, the XRP Ledger, Stellar or Cardano, so this call is the step that identifies them. Only the Solana rows and the Bitcoin-style rows of Bitcoin, Zcash, Litecoin, Dogecoin, Dash and Bitcoin Cash have an inline label field at all, and it is SPARSE on Solana and EMPTY on all the others (the inline list holds none of their addresses) — batch those addresses into this call; a blank one still needs it. Zcash, Dash, Robinhood and Arc have no label coverage at all. Most Bitcoin Cash entries are stored in the old 1… / 3… address form, so CashAddr (q… / p…) addresses find only a few. Addresses may be separated by commas, pipes, spaces or newlines (any mix), so a counterparty list can be pasted straight from another tool's output. Each label comes back CHAIN-QUALIFIED as chain/label_type:label_value. On EVM chains one address is the same owner everywhere, and a label is stored under the chain it was observed on — so LEAVE chain EMPTY (the default) unless you truly need one chain only; filtering by chain hides an exchange/entity tag that was recorded under a different EVM chain. Sources lists every source behind the address's labels and Source_Count how many there are. Labels that disagree (e.g. cex-deposit-address AND cex-hot-wallet for one exchange) come from different sources: a source whose name contains "heuristic" was inferred from transfer patterns, while sanctions lists, official proof-of-reserves disclosures and verified sources are curated — trust the entity they agree on and prefer the curated role. address_labels shows which source recorded which label. Source names: workflow:<name> is a Bitquery labelling pipeline - curated imports such as sanctions and issuer block lists, proof-of-reserves disclosures, research sets and label-provider enrichment - except that a name containing "heuristic" marks labels inferred from transfer patterns (most exchange-deposit labels); labels-query-service:<provider> was fetched on demand from an outside label provider when the address was looked up (one provider's view, not reviewed); a plain name is the dataset itself (ofac, uk-ofsi, eu-sanctions, japan-mof, france-gels and israel-nbctf are sanctions lists; walletexplorer and bitcoinabuse are public Bitcoin datasets), and a name containing "verified" is a reviewed import. To answer "which TRADERS of token X are labeled (CEX-deposit / mixer / …)", do it in two steps: first call top_traders_by_token (or accumulating_/profitable_traders_by_token) to get the trader addresses, then pass them here and match by address. For ALL labels of ONE address use `address_labels`; to list every address carrying a label use `addresses_by_label`. Only addresses that carry a label come back, and every such row says OK in its Status column — an address missing from the answer carries no label, a meaningful negative. When NONE of the addresses is labeled, the answer is ONE row whose address is empty and whose Status says NO_LABELS_FOUND: the lookup ran and found nothing, the same negative, not a failed call. Coverage varies by chain AND by label kind — exchange deposit / hot-wallet tags are broad on the EVM chains and Tron, mixer tags exist essentially only for Bitcoin, and sanctioned / darknet tags sit mostly on Bitcoin, Tron and Ethereum. So an empty result on a given chain means "not labeled there", not "clean".

  ConnectorOAuth

• get_token_pricesA

  RealtapB

  Prices of up to 100 Cardano tokens in one call (ADA and USD per token), optionally with the change of the ADA price over windows from 5 minutes to 90 days (percent). Use it instead of calling `get_token` repeatedly when you hold a list of units. A null change means the token did not trade yet at the start of that window; 30d and 90d only reach back as far as our history. Prices come from DEX pools: check liquidity with `get_token` before quoting a thin token.

  ConnectorNo auth

• build_delegation_transactionA

  RealtapB

  Build an unsigned Cardano transaction that delegates a wallet's stake to a pool and/or its voting power to a DRep (or to "abstain" / "no-confidence"), for a wallet that signs for itself. Give the wallet's base address (or $handle) and at least one of `pool` and `drep`. Returns the transaction as CBOR hex with its hash, the fee and deposit (the refundable stake-key deposit, currently 2 ADA, only when the stake key is not registered yet), the certificates in plain words, the inputs and the single output that returns everything to the wallet, a read-back of the transaction decoded independently of the builder, the cost worked out from the transaction itself (`cost`), warnings and how to sign and submit it. Both the payment key and the stake key must sign. Refuses when the pool is unknown or retiring, the DRep is unknown or retired, the wallet already delegates there, the address is an enterprise or script address, or there is not enough ADA. Realtap never signs, holds keys or submits: nothing happens until the owner of the address signs and submits it. Call it only when that owner asked to stake or delegate; check the pool or DRep first with `get_stake_pool` or `get_drep`. Limited to a few calls per minute.

  ConnectorNo auth

• ada_wallet_ledgerA

  Bitquery: Crypto & Blockchain DataA

  WALLET LEDGER of a set of Cardano (ada, ADA, cardano) addresses - one row per transaction AND asset that touches the client's addresses, NETTED over the whole set: what the set received, what it spent and the difference, so change paid back to one of the client's own addresses is neither income nor a payment. Built for accounting and tax ledgers, wallet statements and reconciliation. NOT one address's raw outputs or inputs - use ada_address_received / ada_sent_from_address; NOT the addresses inside one transaction - use ada_tx_flow. Pass EVERY payment address of the wallet in `addresses` (up to 50 per call). Netting covers only the addresses passed, and Cardano outputs are never labeled as change, so an address of the same wallet that is left out looks like an outside party - its change shows as a payment out and its inputs as someone else's (Fee_Shared = 1 is the usual sign). There is no lookup by stake key: collect the wallet's addresses first (ada_related_addresses, and the Stake_Key column of ada_tx_flow marks addresses of the same wallet). One row per asset: a transaction moving ADA and two tokens is three rows sharing Tx; a token that only passed through (spent and received back in full, as change) is not listed. Amounts of different assets are never added together. Received / Spent / Net are in the asset's units (ADA, not lovelace; a token is scaled by its registered decimals when Decimals > 0, else raw on-chain units); Received_Raw / Spent_Raw / Net_Raw are the exact on-chain integers as strings (lovelace for ADA) - use them when every digit matters. Net = Received - Spent, negative on a payment. Direction is the transaction's, the same on all its rows: in (the set funded no input - a receipt), out (the set funded inputs and at least one output went elsewhere), self (the set funded inputs and every output came back to it - only the fee left). The fee columns are on the ADA row only. Fee_ADA is the fee of the whole transaction; Fee_Paid_ADA the set's part of it: all of it when the set funded every input, nothing when it funded none, and - when other addresses funded inputs too (Fee_Shared = 1) - the fee split by ADA input value (Input_Share; fee x spent / all inputs, rounded half up to a whole lovelace), which is an estimate - what the other parties paid is Fee - Fee_Paid. On an outgoing payment the ADA that went to others is -Net - Fee_Paid. Staking is visible on the ADA row too: Tx_Withdrawal_ADA is the staking reward the transaction withdrew into its outputs (it arrives as part of Received - that is when a reward becomes visible; rewards are not listed as they accrue), and Tx_Deposit_ADA a deposit the transaction paid (positive, e.g. 2 ADA to register a stake key) or got back (negative). Stake / reward addresses are not ledger addresses and are not accepted. Price_Usd is the USD price of ADA at the start of the transaction's hour (hourly market data), on ADA rows only; Value_Usd = Net x Price_Usd, signed like Net, and Fee_Usd = Fee_Paid x Price_Usd. Price_Status: ok; no_price (no market price for that hour - the newest hour or two have none yet - or a token row: tokens are not priced here; the USD columns are null, never a guess and never today's price); suspect (the price is more than twice, or less than half, the price one day earlier AND one day later - a likely data glitch, so Value_Usd and Fee_Usd are left empty). Rows come newest first in block order (Block, Tx_Index), ADA first inside a transaction. `limit` counts TRANSACTIONS, so a page can hold more rows than limit. The window is the last `days` (default 365), or after_time ... before_time for a fixed period such as a tax year. Page with cursor: pass the Cursor of the LAST row, with every other argument unchanged, to get the next older page. after_time and before_time bound every page, so no page leaves the period. With after_time set, a page with fewer transactions than `limit` is the end of the period; without it each page looks `days` back from its cursor, so a walk continues into older history until a page comes back short. currency="" (default) lists every asset, "ADA" the coin only, a numeric Currency_Id one token. Addresses_Requested / Addresses_Used on every row say how many distinct addresses were passed and how many were read. No rows = no transaction of these addresses in the window. Counterparties are not listed: pass a Tx to ada_tx_flow. SCAN COST grows with the window and with the number of addresses, not with limit: prefer a fixed period to a very large `days`. A window in which the addresses have more than 200,000 input or output records is refused - narrow it.

  ConnectorOAuth

• ada_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Cardano databases (`cardano`, `cardano_flow`). The ada_* tools are the PRIORITY; use this ONLY when none can answer. No query optimizer here: filter on the per-key tables and NEVER JOIN big tables (use `IN (SELECT …)`); never GLOBAL IN (it reads the whole table). Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home This data runs on an older release of the engine: some functions and syntax in that reference (map() and toJSONString() among them) do not exist here — when a statement is refused for an unknown function or setting, use the forms shown in this description. DATA MODEL: UTXO model with native tokens — EVERY table has ONE ROW PER ASSET: `currency_id` (native ADA = 7029218, token_index = -1) and `value` UInt64 in RAW units. ALWAYS group by currency_id and divide by `dictGetFloat64('currency','divider',toUInt64(currency_id))` (1e6 for ADA; 1, i.e. raw units, for a token without registered decimals and for an unknown id); a plain sum(value) adds lovelace to token units and is meaningless, and sum() of large token values can overflow — sum toFloat64(value). TOKENS: token identity via the `currency` dict: 'symbol' / 'name' (a ticker or the hex asset name; '-' for an unknown id), 'asset_id' (fingerprint asset1…), 'decimals', 'properties' (YAML text; policy id = `extract(dictGetString('currency','properties',toUInt64(currency_id)), 'policyId: ([0-9a-f]{56})')`). Tickers are not unique — match tokens by fingerprint or policy id. A dictGet in WHERE runs for EVERY row read (no short-circuit), so filter by address / tx / currency_id first. Addresses are plain strings (`addr1…` bech32 lowercase, `stake1…` reward accounts, Byron base58 `Ae2…` / `Ddz…` case-sensitive); a script reward account (`stake17…` on explorers) is mostly recorded in its `stake1u…` spelling, whose checksum differs — look such an account up with ada_address_profile or ada_sent_from_address, which match both spellings. `stake_key` = the staking credential of a base address — on enterprise addresses (`addr1v…` / `addr1w…`) the column holds the payment credential re-encoded as `stake1u…`, which is NOT a staking key. Tx id: `tx_id_bin = unhex('<64hex>')`, output `hex(tx_id_bin)`. Time = `tx_time`. Date-times come back as 'YYYY-MM-DD hh:mm:ss' UTC; select formatDateTime(tx_time, '%FT%TZ') for ISO-8601 (2026-09-21T15:04:18Z), the shape the other tools return. TABLES: db `cardano`, partitioned by month on `tx_date` (add a plain `tx_date` bound whenever you can — inside `… OR …` it prunes nothing): inputs_by_address / outputs_by_address (key address; inputs carry output_tx_id_bin / output_index of the spent output and `source` Enum input/withdrawal/stake_deregistration; outputs carry `direction` — only not_change / unknown on ordinary outputs: change is NEVER labeled, so not_change includes change back to the payer), inputs_by_tx / outputs_by_tx / transactions (fee_value, deposit_value, metadata) / mints (key tx_id_bin — pass `(tx_date, tx_id_bin) IN (…)` when the date is known, otherwise every month is probed; to reuse one lookup in several UNION ALL branches write `(tx_date, tx_id_bin) IN identity((SELECT groupArray((tx_date, tx_id_bin)) FROM cardano.transactions WHERE tx_id_bin IN (…)))`, which runs once; `toInt64(value)` is negative for a burn), blocks (key block). Deposits are already rows: a stake registration is an output to the stake1… address (direction stake_registration), other protocol deposits an output with an empty address (deposit), a refund an input (stake_deregistration) — per transaction ADA inputs = outputs + fee_value and, per token, inputs + mints = outputs; do not add deposit_value on top. db `cardano_flow`: tx_inputs / tx_outputs keyed (block, tx_index), not partitioned — the cheap way to expand many transactions: `(block, tx_index) IN (SELECT block, tx_index FROM cardano.inputs_by_address WHERE address = '…')` (output_type commission / spend — never change; the commission row has an empty address). This copy is INCOMPLETE: it misses some transactions (a few hours of blocks in March 2023 among them) and most outputs of a token minted in the same transaction — use cardano.*_by_tx for exact per-transaction totals. address_transfers (AggregateFunction columns → -Merge; its amount columns ADD ALL ASSETS together and its stake_key is empty — use it for counts only). Address labels: none in this data — use labels_for_addresses(chain='cardano'). LIMITS: read-only; returns the rows of your query. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x). A result of more than 25,000 rows is not cut off - the whole query fails with an error - so aggregate (GROUP BY, count) or add a LIMIT of at most 25,000.

  ConnectorOAuth

• address_labelsA

  Bitquery: Crypto & Blockchain DataA

  Look up all known LABELS for a blockchain ADDRESS — entity, category, CEX deposit/hot wallet, mixer, gambling, scam, token-clone, contract type, NFT collection, ENS, … Works for both wallets and token/contract addresses. Use for "what / who is this address", "is this token a scam or a clone", "is this wallet a CEX or mixer". To label MANY addresses at once use `labels_for_addresses`; to list every address carrying a label use `addresses_by_label`; to resolve a human name to a stored value use `find_label_values`. Backed by the Bitquery address-label directory (directory.labels). Coverage: token/contract labels are dense on EVM (Ethereum, BSC, Polygon); exchange deposit / hot-wallet labels are broad on the EVM chains and Tron; wallet (EOA) labels are densest on Tron and Bitcoin; mixer labels exist essentially only for Bitcoin, and sanctioned / darknet tags sit mostly on Bitcoin, Tron and Ethereum. Pass chain='' (the default) to search every chain — recommended on EVM, where one address is the same owner on every chain and its label may be stored under a different one. Tracing note: MOST tracing rows carry NO label field, so this call is what puts a name on a counterparty. On Ethereum, BSC, Polygon, Arbitrum, Base, Optimism, Tron, the XRP Ledger, Stellar and Cardano NONE of the transfer / flow tools return a label — always look the address up here (or pass the whole counterparty list to `labels_for_addresses`). Only the Solana tools (address_flow_summary, flow_edges, trace_next_hop, transfers_in/out) and the Bitcoin-style tools of Bitcoin, Zcash, Litecoin, Dogecoin, Dash and Bitcoin Cash (address_profile, address_flow_summary, flow_edges, related_addresses, tx_flow) carry an inline label field at all, and even there it is SPARSE on Solana and EMPTY on every other chain (the inline list holds none of their addresses — batch those addresses into labels_for_addresses) — never treat a blank inline label as "unlabeled", always confirm it here. On the XRP Ledger (chain='ripple'), Cardano (chain='cardano'), Stellar (chain='stellar'), Litecoin (chain='litecoin') and Bitcoin Cash (chain='bitcoin-cash') the directory is sparse, mostly exchange reserve wallets; Dogecoin (chain='dogecoin') holds about 40,000 addresses, almost all exchange reserve wallets. Most Bitcoin Cash entries are stored in the old 1… / 3… address form, so a CashAddr (q… / p…) lookup finds only a few of them. Robinhood, Zcash, Dash and Arc have no label coverage at all, so an empty result there is a coverage gap, not a finding. An empty result while find_label_values shows rich coverage (e.g. 'binance') is a meaningful NEGATIVE signal, not missing data. One row per chain + label_type + label_value; recorded_at is the newest record of it. Several sources can record labels for one address. Rows that agree are merged: Sources lists every source behind a label and Source_Count how many there are. Labels that disagree stay separate — typically the same entity in different roles, e.g. cex-deposit-address AND cex-hot-wallet for one exchange, or a token-contract next to a token-clone. Such a conflict comes from different sources; weigh it by Source_Count and by the kind of source: sanctions lists (ofac, uk-ofsi, eu-sanctions …), official proof-of-reserves disclosures and verified sources are curated, while a source whose name contains "heuristic" was inferred from transfer patterns (broad, less certain) — trust the entity they agree on, and prefer the curated role when they differ. Source names: workflow:<name> is a Bitquery labelling pipeline - curated imports such as sanctions and issuer block lists, proof-of-reserves disclosures, research sets and label-provider enrichment - except that a name containing "heuristic" marks labels inferred from transfer patterns (most exchange-deposit labels); labels-query-service:<provider> was fetched on demand from an outside label provider when the address was looked up (one provider's view, not reviewed); a plain name is the dataset itself (ofac, uk-ofsi, eu-sanctions, japan-mof, france-gels and israel-nbctf are sanctions lists; walletexplorer and bitcoinabuse are public Bitcoin datasets), and a name containing "verified" is a reviewed import.

  ConnectorOAuth

• chain_describe_tableA

  Bitquery: Crypto & Blockchain DataA

  COLUMNS of one table in a per-chain transfer database — the DESCRIBE TABLE equivalent for eth_api, bsc_api, matic_api, arbitrum_api, base_api, optimism_api, robinhood_api, arc_api, tron_api, solana, bitcoin, bitcoin_flow, ripple, ripple_flow, cardano, cardano_flow, altcoin, altcoin_flow, bitcash, bitcash_flow and stellar: exact column name (case-sensitive), type, default kind and expression, comment, and whether the column is part of the sort key (filter on those first) or the partition key. Call it before writing SQL for <chain>_transfers_raw_sql: guessed column names fail, and the column sets differ between chains (tron has Transaction_FeePayer and no Transaction_From; solana, bitcoin and the other non-EVM databases use lower-case names). `table` is a name from chain_list_tables, e.g. transfers_sender, calls_to, events_tx, transfers_to, inputs_by_address; a "<database>." prefix is accepted. An EMPTY result means that database has no such table — call chain_list_tables. For trading_rt use describe_table.

  ConnectorOAuth

• chain_search_columnsA

  Bitquery: Crypto & Blockchain DataA

  FIND COLUMNS by name inside one per-chain transfer database (eth_api, bsc_api, matic_api, arbitrum_api, base_api, optimism_api, robinhood_api, arc_api, tron_api, solana, bitcoin, bitcoin_flow, ripple, ripple_flow, cardano, cardano_flow, altcoin, altcoin_flow, bitcash, bitcash_flow, stellar) — which table has a column like "fee", "signature", "topic", "balance" or "prediction", with its exact name and type. `query` is a case-insensitive substring of the column name ("_" is literal), or a LIKE pattern when it contains % (e.g. "Transaction_%"); `table` optionally narrows the search to table names matched the same way (e.g. "events"). Returns at most 100 rows — exactly 100 means there are more, so narrow `query` or `table`. Then call chain_describe_table for the full column list of one table and <chain>_transfers_raw_sql to query it. Searches one database per call; for trading_rt use search_columns. Before hand-written SQL, check chain_capabilities: holders, contract calls and events, transaction history and flow tracing already have specialized tools.

  ConnectorOAuth

• list_databasesA

  Bitquery: Crypto & Blockchain DataA

  CATALOG of the databases raw SQL can reach — the SHOW DATABASES equivalent. For each database: what it holds, which tool runs SQL against it, how to see its tables, and which specialized tools answer the same questions without SQL. Call it before writing raw SQL against an unfamiliar database. Takes no parameters and answers instantly. trading_rt comes first: DEX trades, OHLC / volume bars, prices and supply for every trading chain over the last ~30 days — query it with execute_sql, browse it with list_tables, describe_table and search_columns. The per-chain databases (eth_api, bsc_api, matic_api, arbitrum_api, base_api, optimism_api, robinhood_api, arc_api, tron_api, solana, bitcoin, bitcoin_flow, ripple, ripple_flow, cardano, cardano_flow, altcoin, altcoin_flow - Litecoin, Dogecoin and Dash in one database, rows told apart by blockchain_id - bitcash, bitcash_flow for Bitcoin Cash, and stellar) hold transfers, calls, events, transactions and balances; browse them with chain_list_tables, chain_describe_table and chain_search_columns (pass the database name) and query each one with that chain's <chain>_transfers_raw_sql tool (xrp_, ada_, ltc_ / doge_ / dash_, bch_ and xlm_transfers_raw_sql for the ones above after bitcoin_flow). zcash and zcash_flow are queried with zec_transfers_raw_sql but the schema browser does not cover them: that tool's description lists their tables. stellar_flow is not browsable either - it starts in December 2023 and misses some ledgers, so query stellar instead. Address labels have no SQL access at all — use the label tools. Prefer a specialized tool whenever one answers the question: it already filters on the right keys and is far cheaper than hand-written SQL.

  ConnectorOAuth

• get_market_historyA

  RealtapB

  The Cardano DEX market over a timeframe, per day (per week over a year, per month beyond two years): volume in ADA, settled swaps, makers (distinct trading wallets per day) and trading fees (volume times pool fee), for all DEXes together or one DEX. Returns the totals of the full UTC days of the range, their change against the equally long period before (null when that period is not stored), each period, and the DEXes of the range by volume with their share. The running day and the day our history starts on are marked partial and left out of totals; `coverage` says which days are counted and where history starts. Use it for "how much traded on Cardano last month", "is volume growing", "market share of Minswap over 90 days".

  ConnectorNo auth

• crypto_priceA

  Inferventis — Financial Data, News & Web MCPA

  Retrieves real-time price data for any cryptocurrency listed on CoinGecko. Returns the current price in any fiat currency, 24-hour percentage change, market capitalisation, and 24-hour trading volume. Supports all major cryptocurrencies including Bitcoin (BTC), Ethereum (ETH), Solana (SOL), XRP, Cardano (ADA), Dogecoin (DOGE), Polygon (MATIC), Chainlink (LINK), Avalanche (AVAX), and 10,000+ additional coins. Use crypto_price when an agent needs the full market picture for a digital asset — price, change, market cap, and volume in one call. Prefer crypto_price_lite when only the spot price and 24h change are needed and a smaller response payload is preferred. Use crypto_fx_rates (via CoinAPI) when converting a specific amount between a cryptocurrency and fiat, or between two cryptocurrencies. Do not use this tool for fiat-to-fiat currency conversion (e.g. USD to EUR) — use currency_convert instead. Do not use when historical price data for a specific past date is required — this tool returns live spot prices only.

  ConnectorNo auth

• crypto_priceA

  Inferventis MCP ServerA

  Retrieves real-time price data for any cryptocurrency listed on CoinGecko. Returns the current price in any fiat currency, 24-hour percentage change, market capitalisation, and 24-hour trading volume. Supports all major cryptocurrencies including Bitcoin (BTC), Ethereum (ETH), Solana (SOL), XRP, Cardano (ADA), Dogecoin (DOGE), Polygon (MATIC), Chainlink (LINK), Avalanche (AVAX), and 10,000+ additional coins. Use crypto_price when an agent needs the full market picture for a digital asset — price, change, market cap, and volume in one call. Prefer crypto_price_lite when only the spot price and 24h change are needed and a smaller response payload is preferred. Use crypto_fx_rates (via CoinAPI) when converting a specific amount between a cryptocurrency and fiat, or between two cryptocurrencies. Do not use this tool for fiat-to-fiat currency conversion (e.g. USD to EUR) — use currency_convert instead. Do not use when historical price data for a specific past date is required — this tool returns live spot prices only.

  ConnectorNo auth

• get_cip_historyA

  canton-ccpediaA

  Get the status-transition timeline of a single Canton Improvement Proposal (CIP): each dated from->to change (e.g. Draft->Review->Final). Use for 'how/when did CIP-X move through governance' questions. Returns history only, not the proposal body (get_cip) or vote tallies (get_cip_votes). Canton ecosystem only. Not Cardano or other 'CIP' schemes.

  ConnectorNo auth