Skip to main content
Glama
covalenthq

GoldRush MCP Server

by covalenthq

token_balances

Fetch native and ERC20 token balances for any wallet address across multiple blockchain networks, with options to include NFTs, filter spam, and convert values to different currencies.

Instructions

Commonly used to fetch the native and fungible (ERC20) tokens held by an address. Required: chainName (blockchain network), address (wallet address). Optional: quoteCurrency for value conversion, nft (include NFTs, default false), noNftFetch, noSpam, and noNftAssetMetadata (all default true) to control data returned. Returns detailed token balance information including spot prices and metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNameYesThe blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet').
addressYesThe wallet address to get token balances for. Must be a valid blockchain address.
quoteCurrencyNoCurrency to quote token values in (e.g., 'USD', 'EUR'). If not specified, uses default quote currency.
nftNoInclude NFT token balances in the response. Default is false.
noNftFetchNoSkip fetching NFT metadata. Default is true for better performance.
noSpamNoFilter out spam/scam tokens from results. Default is true.
noNftAssetMetadataNoSkip fetching NFT asset metadata. Default is true for better performance.

Implementation Reference

  • The "token_balances" tool is registered in addBalanceServiceTools function in src/services/BalanceService.ts, where it defines its schema and handler logic using the GoldRush client.
    server.tool(
        "token_balances",
        "Commonly used to fetch the native and fungible (ERC20) tokens held by an address. " +
            "Required: chainName (blockchain network), address (wallet address). " +
            "Optional: quoteCurrency for value conversion, nft (include NFTs, default false), " +
            "noNftFetch, noSpam, and noNftAssetMetadata (all default true) to control data returned. " +
            "Returns detailed token balance information including spot prices and metadata.",
        {
            chainName: z
                .enum(Object.values(ChainName) as [string, ...string[]])
                .describe(
                    "The blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet')."
                ),
            address: z
                .string()
                .describe(
                    "The wallet address to get token balances for. Must be a valid blockchain address."
                ),
            quoteCurrency: z
                .enum(Object.values(validQuoteValues) as [string, ...string[]])
                .optional()
                .describe(
                    "Currency to quote token values in (e.g., 'USD', 'EUR'). If not specified, uses default quote currency."
                ),
            nft: z
                .boolean()
                .optional()
                .default(false)
                .describe(
                    "Include NFT token balances in the response. Default is false."
                ),
            noNftFetch: z
                .boolean()
                .optional()
                .default(true)
                .describe(
                    "Skip fetching NFT metadata. Default is true for better performance."
                ),
            noSpam: z
                .boolean()
                .optional()
                .default(true)
                .describe(
                    "Filter out spam/scam tokens from results. Default is true."
                ),
            noNftAssetMetadata: z
                .boolean()
                .optional()
                .default(true)
                .describe(
                    "Skip fetching NFT asset metadata. Default is true for better performance."
                ),
        },
        async (params) => {
            try {
                const response =
                    await goldRushClient.BalanceService.getTokenBalancesForWalletAddress(
                        params.chainName as Chain,
                        params.address,
                        {
                            quoteCurrency: params.quoteCurrency as Quote,
                            nft: params.nft,
                            noNftFetch: params.noNftFetch,
                            noSpam: params.noSpam,
                            noNftAssetMetadata: params.noNftAssetMetadata,
                        }
                    );
                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?

With no annotations provided, the description carries the full burden. It adds useful behavioral context about performance defaults ('default true for better performance') and return content ('spot prices and metadata'), but omits other critical behavioral traits like rate limits, authentication requirements, or cache behavior.

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?

The description is appropriately sized and logically structured: purpose first, then parameter requirements, then return value summary. While efficient, it dedicates significant space to listing parameters that are already well-documented in the schema, slightly diluting its conciseness.

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?

Given the rich input schema (100% coverage, enums) and lack of output schema, the description provides adequate context by summarizing return values ('detailed token balance information including spot prices'). However, it could better compensate for the missing output schema by describing the response structure or key fields.

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?

The input schema has 100% description coverage, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, primarily organizing parameters into required/optional categories and noting 'for value conversion' for quoteCurrency, but largely repeats the schema's definitions.

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?

The description clearly states the tool 'fetch[es] the native and fungible (ERC20) tokens held by an address,' using a specific verb and resource. It effectively distinguishes from siblings like 'nft_for_address' (by noting NFTs are optional/default false) and 'transactions_for_address' (by focusing on balances, not activity).

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?

While the description identifies required versus optional parameters, it lacks explicit guidance on when to use this tool versus close siblings like 'native_token_balance', 'multichain_balances', or 'historical_token_balances'. The 'Commonly used' phrasing implies preference but does not define selection criteria.

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