Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Price At

price_at
Read-only

USD PRICE AT A PAST MOMENT - what a token or coin was worth when a transfer happened: up to 500 (asset, time) pairs on ONE chain per call. Use it to value transfers, fees and holdings at the time they occurred (tax and accounting reports, cost basis), years back. NOT a time series - use token_ohlcv / currency_ohlcv; NOT the latest price - use token_price / currency_price.

chain is exactly one of: eth, bsc, matic (Polygon), arbitrum, base, optimism, robinhood, arc, tron, solana, btc, zec, ltc, doge, dash, bch, xrp, xlm, ada (lower case; any other spelling is refused). items is a list of asset@time pairs separated by "|", for example native@2025-01-15 12:00:00|0xdac17f958d2ee523a2206206994597c13d831ec7@1736942400. The asset is a token contract (EVM 0x-hex, Tron base58, Solana mint) or the word native for the chain's own coin; the time is UTC, as YYYY-MM-DD HH:MM:SS or 10-digit unix seconds (up to 4294967295). Identify a token by its contract, never by its symbol.

What is covered: on the EVM chains the native coin and tokens by contract, years of history, a price every 5 minutes for the native coin and the largest tokens and ONE price per UTC day for every other token. On tron TRX and about 200 major tokens, one price per day. On solana SOL and several thousand of the most traded mints, a price every 10 minutes, and no price when the token did not trade in the hour before. On btc, zec, ltc, doge, dash, bch, xrp, xlm and ada the native coin only, hourly, back to 2013-2017; tokens issued on those chains are not priced. USDC on Arc (the native coin and 0x3600...0000) is priced as USDC on Ethereum: ask chain=eth with the contract the Note gives.

One row per pair, in the order given - a pair given twice is answered twice, so row N always answers pair N: Price_Usd and Status - ok; no_price (Note says why - nothing recorded, a future time, an invalid or out-of-range date, an asset this chain does not price); stale (the price had not changed for 2 days, or for 1 hour on an asset priced every 5 minutes - the token had probably stopped trading, do not treat it as a market price); suspect (more than twice, or less than half, the price a day earlier AND a day later - a data glitch, check before using); depeg (USDT, USDC or DAI outside 0.98-1.02). A missing price is never 0 and never today's price - report it as unpriced, do not fill it in. Resolution is how fine the price is (5m, 10m, 1h, 1d); Source is dex (on-chain trades) or vendor (market feed); Fill (vendor only) is origin, interpolate or extrapolate. Price_Time and Age_Seconds say which price point answered: always on the vendor chains (the hour), with with_age=1 on the EVM chains and tron. Up to 500 pairs; pairs after the 500th are ignored - compare Items_Requested with Items_Used.

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": {
      "chain": "<chain>",
      "items": "<items>"
    },
    "name": "price_at"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainYesChain of every pair in this call, exactly one of: eth, bsc, matic, arbitrum, base, optimism, robinhood, arc, tron, solana, btc, zec, ltc, doge, dash, bch, xrp, xlm, ada (lower case). Polygon is matic, BNB Chain is bsc, Ethereum is eth. Any other value is refused.
itemsYesasset@time pairs separated by "|" (up to 500; pairs after the 500th are ignored - compare Items_Requested with Items_Used). asset = token contract (0x-hex on EVM chains, base58 on tron, mint on solana) or native for the chain's own coin; time = UTC, YYYY-MM-DD HH:MM:SS (or YYYY-MM-DD, or with a T and a trailing Z) or 10-digit unix seconds. A pair may be repeated: every position gets its own row. Example: native@2025-01-15 12:00:00|0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48@1736942400. Letters, digits, "@", "|", "-", ":" and spaces only.
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
with_ageNo1 = also return Price_Time and Age_Seconds (which price point answered, and how old it was at the asked time) on the EVM chains and tron - a noticeably heavier call, use it to audit a stale or suspect row, not by default. Ignored on solana; the btc / zec / ltc / doge / dash / bch / xrp / xlm / ada answers always carry both. 0 (default) = prices and statuses only. 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. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnly/non-destructive; the description adds substantial context beyond that. It documents per-chain coverage and resolution (5m native/major tokens on EVM, 1d for others, 1h on UTXO chains), the full Status vocabulary (ok, no_price, stale, suspect, depeg) with thresholds, and the critical rule that a missing price is never 0 and never today's price. Row-ordering guarantees and the Items_Requested vs Items_Used truncation check are also disclosed.

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?

Strongly front-loaded: the one-line purpose and the not-this/use-that routing come first, then coverage, then the return contract. It is long and repeats some schema text (the items format and with_age semantics appear in both places), but nearly every sentence carries decision-relevant information about coverage gaps or status semantics that would otherwise cause wrong results.

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?

There is no output schema, so the description carries the full burden of explaining returns, and it does: one row per pair in input order, Price_Usd and Status, Resolution, Source (dex vs vendor), Fill (origin/interpolate/extrapolate), Price_Time and Age_Seconds, plus Items_Requested/Items_Used. Chain-specific coverage caveats are spelled out per ecosystem, so an agent can predict failure modes before calling.

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 already 100%, so the baseline is 3; the description earns extra credit by tying parameters to consequences — the accepted chain list with Polygon=matic and BNB=bsc aliasing, the asset@time pipe format with a worked example, the "identify by contract, never by symbol" rule, and the caveat that with_age is a heavier audit-only call. Most of this restates the schema, so it lands at 4 rather than 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 specific verb-and-resource framing ("USD price at a past moment — what a token or coin was worth when a transfer happened") and immediately bounds it to 500 (asset, time) pairs on one chain. It explicitly names the siblings it is not (token_ohlcv / currency_ohlcv for time series, token_price / currency_price for latest price), so an agent can discriminate without opening another 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 both positive guidance (value transfers, fees, holdings at time of occurrence, tax/accounting, cost basis, years back) and explicit negative routing to four named alternatives. It also states operational limits: one chain per call, 500-pair cap with pairs after 500 ignored, and the Arc/USDC special case with the exact workaround (chain=eth plus the contract).

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.