Skip to main content
Glama

Crypto Price Lookup

crypto_prices
Read-only

Crypto price and token price lookup: live spot price and 24h change for BTC, ETH, SOL and other coins by ticker, or for any DEX-traded token by chain:address, in USD and other currencies. Data from DefiLlama. Three modes: (1) coins as CoinGecko-style IDs or tickers (up to 50) for live price and 24h change, converted to the requested currencies; (2) tokens as chain:address (e.g. base:0x833589fC…, ethereum:0x6982…) for any DEX-traded token; (3) at (past ISO date or unix seconds) for historical USD prices of coins and tokens. Params: coins, tokens, currencies (default ['usd']), at. Price: $0.002 USDC per call, paid inside this MCP call via x402 (USDC on Base, Solana, Polygon or Arbitrum). x402 MCP clients such as @x402/mcp pay automatically. Free sample: call with the example input {"coins":["bitcoin","ethereum"],"currencies":["usd"]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoPast ISO date or unix seconds for historical USD prices
coinsNoList of coin IDs or ticker symbols. Accepts CoinGecko IDs (e.g. 'bitcoin', 'ethereum') or common tickers (e.g. 'BTC', 'ETH', 'SOL'). Max 25 coins per call.
tokensNoTokens as chain:address, e.g. base:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
currenciesNoTarget currencies. Default: ['usd']. Supported: usd, btc, eth and every ECB currency (eur, gbp, jpy, chf, aud, cad, ...).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / currencies / description
      Previous value: -"Target fiat currencies. Default: ['usd']. Supported: usd, eur, gbp, jpy, chf, aud, cad, btc, eth."New value: +"Target currencies. Default: ['usd']. Supported: usd, btc, eth and every ECB currency (eur, gbp, jpy, chf, aud, cad, ...)."
  2. Changed3 schema fields changed
    • addedInput schema / properties / at
      Added value: +{
      +  "description": "Past ISO date or unix seconds for historical USD prices",
      +  "type": "string"
      +}
    • addedInput schema / properties / tokens
      Added value: +{
      +  "description": "Tokens as chain:address, e.g. base:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "coins"
      -]
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds critical non-obvious behavior: a per-call cost ($0.002 USDC) paid via x402 inside the call, which chains/networks are accepted, and that certain MCP clients auto-pay. This pricing/auth context is valuable beyond annotations; free sample call is a nice touch.

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?

Well front-loaded with purpose and modes, but the description is dense and includes a long pricing/payment paragraph and a prosy free-sample sentence. Every part is relevant, yet the pricing detail could be trimmed slightly without losing agent utility.

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

Completeness4/5

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

Covers purpose, modes, parameter roles, cost model, and payment mechanism. No output schema exists, so the description would ideally describe return values (e.g., shape of price/24h change data), which it doesn't; but for an agent selecting and invoking the tool, the key decisions are covered.

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 coverage is 100%, so the schema already documents all four parameters in detail. The description summarizes the params (coins, tokens, currencies default, at) but adds no new semantics beyond what the schema states. Note a minor inconsistency: description says 'up to 50' coins while schema says 'Max 25 coins'.

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?

States a specific verb+resource (price and token price lookup) with concrete scope: live spot price and 24h change for tickers, DEX tokens, and historical prices. Clearly distinguishes itself from siblings like defi_tvl, exchange_rates, and token_* tools by focusing on price data.

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

Usage Guidelines4/5

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

Provides clear mode selection guidance (three enumerated modes with examples) so an agent knows how to formulate requests for coins vs tokens vs historical. Does not explicitly name when NOT to use or point to specific sibling alternatives, but the mode structure gives strong usage context.

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.

Resources