Skip to main content
Glama
covalenthq

GoldRush MCP Server

by covalenthq

multichain_balances

Fetch native and token balances for a single wallet across up to 10 EVM chains. Retrieve paginated spot or historical balances, specify networks, quote currency, and time filters with one API call.

Instructions

Fetch paginated spot & historical native and token balances for a single address on up to 10 EVM chains with one API call. Requires walletAddress. Optional parameters include chains array to specify networks, quoteCurrency for value conversion, limit (default 10), pagination (before), and cutoffTimestamp to filter by time. Use this to get a comprehensive view of token holdings across different blockchains.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletAddressYesThe 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.
beforeNoPagination cursor to get balances before this point. Use the 'before' value from previous response.
limitNoMaximum number of token balances to return. Default is 10, maximum is 100.
chainsNoArray of blockchain networks to query balances from. Can be chain names or chain IDs. If not specified, queries all supported chains.
cutoffTimestampNoUnix timestamp to filter balances by last activity. Only returns tokens with activity after this time.

Implementation Reference

  • The async handler function for the multichain_balances tool. Calls goldRushClient.AllChainsService.getMultiChainBalances with walletAddress, quoteCurrency, before, limit, chains, and cutoffTimestamp. Returns the result via stringifyWithBigInt or an error.
        async (params) => {
            try {
                const response =
                    await goldRushClient.AllChainsService.getMultiChainBalances(
                        params.walletAddress,
                        {
                            quoteCurrency: params.quoteCurrency as Quote,
                            before: params.before,
                            limit: params.limit,
                            chains: params.chains as ChainID[] | ChainName[],
                            cutoffTimestamp: params.cutoffTimestamp,
                        }
                    );
                return {
                    content: [
                        {
                            type: "text",
                            text: stringifyWithBigInt(response.data),
                        },
                    ],
                };
            } catch (error) {
                return {
                    content: [{ type: "text", text: `Error: ${error}` }],
                    isError: true,
                };
            }
        }
    );
  • Zod schema definitions for the multichain_balances tool inputs: walletAddress (string, required), quoteCurrency (enum from validQuoteValues, optional), before (string cursor, optional), limit (number, default 10, optional), chains (array of chain names or chain IDs, optional), cutoffTimestamp (number, optional).
    {
        walletAddress: 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."
            ),
        before: z
            .string()
            .optional()
            .describe(
                "Pagination cursor to get balances before this point. Use the 'before' value from previous response."
            ),
        limit: z
            .number()
            .optional()
            .default(10)
            .describe(
                "Maximum number of token balances to return. Default is 10, maximum is 100."
            ),
        chains: z
            .array(
                z.union([
                    z.enum(
                        Object.values(ChainName) as [string, ...string[]]
                    ),
                    z.number(),
                ])
            )
            .optional()
            .describe(
                "Array of blockchain networks to query balances from. Can be chain names or chain IDs. If not specified, queries all supported chains."
            ),
        cutoffTimestamp: z
            .number()
            .optional()
            .describe(
                "Unix timestamp to filter balances by last activity. Only returns tokens with activity after this time."
            ),
    },
  • Registration of the tool named 'multichain_balances' via server.tool() call within addAllChainsServiceTools(). Also includes the description string.
    server.tool(
  • src/server.ts:68-68 (registration)
    Top-level registration: addAllChainsServiceTools(server, goldRushClient) is called from createServer() to register all AllChainsService tools including multichain_balances.
    addAllChainsServiceTools(server, goldRushClient);
  • Helper function stringifyWithBigInt used by the handler to serialize the response data, converting BigInt values to strings.
    export function stringifyWithBigInt(value: any): string {
        return JSON.stringify(
            value,
            (_, val) => (typeof val === "bigint" ? val.toString() : val),
            2
        );
    }
Behavior3/5

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

With no annotations, description carries full burden. It implies read-only ('Fetch') and mentions pagination, but lacks details on data freshness, rate limits, or side effects. Adequate but not thorough.

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?

Three well-structured sentences: purpose, parameter list, use case. No fluff, every sentence adds value.

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 main functionality with 6 parameters described. Missing response structure details, but given no output schema, the description provides sufficient context for the agent to use it.

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 coverage is 100%, but the description adds value by explaining each parameter's role in context, such as cutoffTimestamp for filtering by time and chains for network specification. Exceeds baseline.

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 fetches paginated spot and historical balances for a single address across up to 10 EVM chains, distinguishing it from single-chain siblings like token_balances and bitcoin_balances.

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?

It explicitly notes required walletAddress, optional parameters (chains, quoteCurrency, limit, before, cutoffTimestamp), and the use case for comprehensive cross-chain view. Slightly lacking explicit alternatives or when-not-to-use, but still clear context.

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