Skip to main content
Glama
covalenthq

GoldRush MCP Server

by covalenthq

pool_spot_prices

Retrieve real-time token pair prices from Uniswap V2/V3 and compatible DEX liquidity pools by specifying blockchain network and pool contract address.

Instructions

Get the spot token pair prices for a specified pool contract address. Supports pools on Uniswap V2, V3 and their forks. Required: chainName (blockchain network), contractAddress (pool contract address). Optional: quoteCurrency (price currency) for value conversion. Returns spot token pair prices with pool details and token metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNameYesThe blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet').
contractAddressYesThe liquidity pool contract address to get spot prices for. Must be a valid Uniswap V2/V3 or compatible DEX pool address.
quoteCurrencyNoCurrency to quote pool token values in (e.g., 'USD', 'EUR'). If not specified, uses default quote currency.

Implementation Reference

  • The `pool_spot_prices` tool registration and handler implementation. It uses `zod` for input validation and `goldRushClient.PricingService.getPoolSpotPrices` to fetch the data.
    server.tool(
        "pool_spot_prices",
        "Get the spot token pair prices for a specified pool contract address. Supports pools on Uniswap V2, V3 and their forks.\n" +
            "Required: chainName (blockchain network), contractAddress (pool contract address).\n" +
            "Optional: quoteCurrency (price currency) for value conversion.\n" +
            "Returns spot token pair prices with pool details and token metadata.",
        {
            chainName: z
                .enum(Object.values(ChainName) as [string, ...string[]])
                .describe(
                    "The blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet')."
                ),
            contractAddress: z
                .string()
                .describe(
                    "The liquidity pool contract address to get spot prices for. Must be a valid Uniswap V2/V3 or compatible DEX pool address."
                ),
            quoteCurrency: z
                .enum(Object.values(validQuoteValues) as [string, ...string[]])
                .optional()
                .describe(
                    "Currency to quote pool token values in (e.g., 'USD', 'EUR'). If not specified, uses default quote currency."
                ),
        },
        async (params) => {
            try {
                const response =
                    await goldRushClient.PricingService.getPoolSpotPrices(
                        params.chainName as Chain,
                        params.contractAddress,
                        {
                            quoteCurrency: params.quoteCurrency as Quote,
                        }
                    );
                return {
                    content: [
                        {
                            type: "text",
                            text: stringifyWithBigInt(response.data),
                        },
                    ],
                };
            } catch (error) {
                return {
                    content: [{ type: "text", text: `Error: ${error}` }],
                    isError: true,
                };
            }
        }
    );
Behavior3/5

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

No annotations provided, so description carries full burden. It compensates for missing output schema by describing return values ('spot token pair prices with pool details and token metadata'), which is essential. However, it omits other behavioral traits like error handling (e.g., invalid pool address), rate limiting, or data freshness/staleness expectations.

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?

Five sentences with zero waste: purpose (1), protocol support (1), required params (1), optional params (1), return value (1). Logical flow from what it does → constraints → inputs → outputs. Front-loaded with the core action.

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 3-parameter tool with 100% schema coverage and no output schema, the description is nearly complete. It describes return structure to compensate for missing output schema. Could be improved with error scenarios (e.g., 'fails if pool not found') or rate limit notes, but adequate for invocation.

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 has 100% description coverage with detailed explanations for each parameter. Tool description organizes parameters by required/optional status and adds minor gloss ('for value conversion'), but largely restates schema content. Baseline 3 is appropriate given schema completeness.

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?

Description opens with specific verb 'Get' and resource 'spot token pair prices', clearly scoped to 'specified pool contract address'. The mention of 'Uniswap V2, V3 and their forks' effectively distinguishes this from siblings like historical_token_prices (historical vs spot) and token_balances (holdings vs pool prices).

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 context by specifying supported protocols (Uniswap V2/V3/forks), which constrains usage appropriately. Explicitly categorizes parameters as Required vs Optional. While it doesn't explicitly name sibling alternatives (e.g., 'use historical_token_prices for past data'), the 'spot' designation and protocol constraints provide sufficient implicit guidance for selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/covalenthq/goldrush-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server