Skip to main content
Glama
Sign In

Tollkit Crypto

by io.github.UltraStarz
OverviewDiscussionsAdmin

Token price

token_price
Read-only

Get a token's current USD price on Base, Ethereum or Solana, read from its deepest on-chain pool (Uniswap v3 against USDC or WETH; on Solana, Orca Whirlpools against USDC or SOL) rather than a price API. Returns the pool used, how much liquidity backs the price, and a flag when the pool is too thin to trust.

$0.001 USDC per call over x402. Failed calls cost nothing. Call without payment to get a quote.

When to use: You need a token's current USD price straight from the chain. Use instead: price_history for past prices; token_check for price plus safety warnings; crypto_market_pulse for BTC, ETH and SOL at once. Parameters: token: ERC-20 contract or SPL mint ("SOL" works on Solana). chain: base (default), ethereum or solana. Returns: price_usd, the pool used, its liquidity, and a thin_liquidity flag when the price shouldn't be trusted.

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": {
      "token": "<token>"
    },
    "name": "token_price"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNo"base" (default), "ethereum" or "solana".
tokenYesERC-20 contract or SPL mint to price ("SOL" works on Solana).
paymentNoBase64 x402 payment payload. Omit it to receive a quote; sign that and call again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial context beyond them: the price source (deepest on-chain pool), return fields including liquidity and a thin_liquidity trust flag, and the x402 pricing/quote workflow. It stops short of detailing rate limits or failure modes beyond 'failed calls cost nothing', but the behavioral picture is strong.

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

Conciseness5/5

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

Well front-loaded: purpose, source methodology, pricing, and usage routing appear in a logical order. Every section earns its place, and the structured headings ('When to use', 'Use instead', 'Parameters', 'Returns') make it easy 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?

With no output schema, the description compensates by listing the return fields (price_usd, pool, liquidity, thin_liquidity). It also covers payment prerequisites and the quote flow, so an agent has everything needed to call it correctly.

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%, so the schema already documents token, chain, and payment, including defaults and the quote workflow. The description restates this without adding syntax or format details beyond the schema, so the baseline 3 is appropriate.

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 and resource (get a token's current USD price) along with the supported chains and the on-chain pool methodology. This clearly distinguishes it from siblings like price_history and crypto_market_pulse.

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?

Explicitly provides a 'When to use' clause and names alternatives with their distinguishing conditions: price_history for past prices, token_check for safety warnings, crypto_market_pulse for BTC/ETH/SOL together. The x402 payment flow is also clearly explained.

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

All Tollkit Crypto toolsInspect
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.

Resources