Skip to main content
Glama

get_dex_price

Query exact DEX spot prices and liquidity across Base and Solana to retrieve on-chain pool reserves and quotes for trading decisions.

Instructions

    [Cost: $0.001 USDC on Base & Solana] Live multi-chain DEX spot price oracle and liquidity quoter.
    
    Keywords: dex price, spot quoter, uniswap, aerodrome, raydium, orca, solana dex price, get_dex_spot_price.
    Direct on-chain smart contract pool queries across Base L2 (Uniswap v3, Aerodrome) and Solana (Raydium, Orca).
    Returns exact pool reserves, active liquidity, slot/block height, and price quotes.

    Supported chains:
      - 'base' (default): EVM pairs (WETH-USDC, cbBTC-USDC, AERO-USDC)
      - 'solana': SPL pairs (SOL-USDC, BONK-USDC, JUP-USDC, RAY-USDC, WIF-USDC, SOL-USDT)

    Args:
        pair: Target trading pair symbol (e.g. 'WETH-USDC' for Base, 'SOL-USDC' for Solana).
        chain: Target blockchain network ('base' or 'solana', default: 'base').
        amount: Token input amount to quote (default: 1.0).
        payment_signature: Optional x402 Base/Solana USDC transaction hash or developer mock key.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pairNoWETH-USDC
chainNobase
amountNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does disclose two non-obvious traits: a per-call cost of $0.001 USDC and an x402 payment/payment_signature requirement for settling it. It also states what is returned (pool reserves, active liquidity, slot/block height, price quotes). It stops short of stating failure modes, supported-amount limits, or rate limits.

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?

Cost and one-line purpose are front-loaded, followed by supported chains and args in scannable blocks. The 'Keywords:' line is SEO-style padding that adds little for an agent, but overall length is proportionate to a multi-chain tool with four undocumented parameters.

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?

For a 4-parameter tool with no annotations and no output schema, the description covers what the tool does, what it costs, what it returns, the supported chains/pairs, and every argument. The main omission is any statement of how this differs from the sibling dex-price tools.

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 description coverage is 0%, so the description must compensate, and it largely does: pair format is exemplified per chain, chain enumerates 'base'/'solana' with the default, amount is described as token input with default 1.0, and payment_signature is explained as an x402 USDC tx hash or mock key. The pair parameter's own default (WETH-USDC) is left to the schema, a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Live multi-chain DEX spot price oracle and liquidity quoter', with named venues (Uniswap v3, Aerodrome, Raydium, Orca) and supported pairs. However, it never differentiates itself from the near-identical siblings 'get_dex_spot_price' and 'get_solana_dex_price' — it even lists 'get_dex_spot_price' as a keyword, which muddies rather than clarifies the boundary.

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

Usage Guidelines3/5

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

Usage is implied: on-chain pool queries across Base and Solana for spot prices and quotes. The cost line ($0.001 USDC) gives practical context for deciding to call it. But with two obvious sibling alternatives, there is no explicit when-to-use-this-vs-that guidance, so the agent must infer routing.

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