Bitquery: Crypto & Blockchain Data

Chain Capabilities

chain_capabilities

Read-only

INDEX of the per-blockchain tracing tools — which capabilities exist for which chain, with the chain's aliases and its tool-name prefix. One row per chain, sorted by name; Not_Available lists the capabilities that chain lacks. CALL THIS FIRST when you are unsure whether a tool exists for a chain, or which name it has, instead of guessing a name or concluding from a failed call that a capability is missing. Covers the 19 traced chains (Ethereum, BSC, Polygon, Arbitrum, Base, Optimism, Robinhood, Arc, Tron, Solana, Bitcoin, Zcash, Litecoin, Dogecoin, Dash, Bitcoin Cash, Cardano, XRP Ledger, Stellar) and Hyperliquid, an exchange chain with its own market / trader tool family. Coverage says what a row offers: tracing (per-chain tools under Tool_Prefix) or exchange (Hyperliquid); a chain covered by the market tools only would show market_data, one listed only for its price price_only (Capabilities then names the plain tools and Notes the exact currency_id), one listed with no data none. A name that matches no row returns ONE row with Chain "No match" and Coverage unknown that lists the traced chains: check the spelling or try an alias - a chain that is not in this index has no transfer, address or transaction data here. Tool names are "", e.g. prefix "eth_" + "address_flow_summary" = eth_address_flow_summary. The market/price, trending, trader and label tools are NOT per-chain — they take a blockchain parameter instead and are not listed here. They carry token and swap data for every chain in this matrix EXCEPT Bitcoin, Zcash, Litecoin, Dogecoin, Dash, Bitcoin Cash, Cardano, the XRP Ledger and Stellar, which have no token or DEX data there (nor does Hyperliquid, which has its own hyperliquid_* tools). Most of their native coins are still priced, as currencies rather than tokens (currency_price / currency_ohlcv with currency_id "bid:bitcoin", "zec", "ltc", "doge", "bch", "ada" or "xrp" — price only; BTC's recorded supply and market cap there are wrong by more than 100x); DASH and XLM are not in the currency tools: price_at (chain=dash / chain=xlm, asset native) prices them, as it prices any traced chain's coin or token at a past moment. Each of these chains' Notes says how to price it. Filter with chain (name, alias or prefix), or leave it empty for the whole matrix. One family is deliberately NOT chain-prefixed: the prediction-market tools are named polymarket_* and cover Polygon only — see the Polygon row's Notes. Hyperliquid has no transfer tracing at all: its row lists the hyperliquid_* tools under the same capability column. Answers instantly and never depends on a blockchain data service being reachable. The matrix lists what the server has: a connection limited to part of the tools (for example one without the raw-SQL or market tools) does not offer every tool named here - use the ones in your tool list. Each row: Chain, Coverage, Aliases, Tool_Prefix, Capabilities, Not_Available, Notes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "chain_capabilities"
  }
}

Input Schema

Name	Required	Description	Default
`chain`	No	Chain name, alias or tool prefix to look up (e.g. "polygon", "op", "btc"). Subject words work too where a chain carries a themed tool family — "polymarket" or "prediction markets" reaches Polygon. Empty = return every chain.
`format`	No	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.	rows

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

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"
+}

First observedOct 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With readOnlyHint already covering safety, the description still adds non-obvious behavior: it answers instantly and never depends on a live blockchain data service, a non-matching name returns exactly one "No match"/unknown row listing traced chains, and a server connection limited to a subset of tools will not offer everything named here. Those are operational traits an agent cannot infer from annotations or schema.

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

Conciseness2/5

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

Front-loading is good — the index purpose and the CALL THIS FIRST directive come early — but the body is one massive block that digresses into currency_id examples, the claim that BTC supply/market cap is wrong by 100x, and per-chain pricing recipes that belong to price_at/currency_price rather than to this index. Those sentences bloat an otherwise simple two-parameter lookup tool and make the structure hard to scan.

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 the row fields (Chain, Coverage, Aliases, Tool_Prefix, Capabilities, Not_Available, Notes), defining the Coverage values (tracing / exchange / market_data / price_only / none), and explaining the prefix+capability naming convention with an example. An agent has everything needed to call it and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already documents both `chain` (name/alias/prefix, empty = all) and `format` (rows vs columnar). The description's "Filter with `chain` (name, alias or prefix), or leave it empty for the whole matrix" largely restates that, adding only the polymarket-subject-word nuance, which the schema also carries. Baseline 3 is appropriate when the schema does the parameter work.

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 opening sentence states a specific verb and resource: an INDEX of per-blockchain tracing tools, mapping capabilities to chains plus aliases and prefixes. It explicitly draws the boundary against the non-per-chain families (market/price, trending, trader, label tools) and mentions the polymarket_* exception, so an agent can separate it from siblings like data_coverage or trending_tokens 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 an explicit directive: "CALL THIS FIRST when you are unsure whether a tool exists for a chain, or which name it has, instead of guessing a name or concluding from a failed call that a capability is missing." It also states the inverse condition — that a chain absent from the index has no transfer/address/transaction data here — and names an alternative usage path (market/price tools take a `blockchain` parameter instead).

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

All Bitquery: Crypto & Blockchain Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.