Skip to main content
Glama
covalenthq

GoldRush MCP Server

by covalenthq

token_holders

Retrieve current or historical token holders for ERC20/ERC721 tokens across multiple blockchains, with pagination and balance details.

Instructions

Used to get a paginated list of current or historical token holders for a specified ERC20 or ERC721 token.Required: chainName (blockchain network), tokenAddress (token contract address). Optional: blockHeight or date for historical data, pageSize and pageNumber for pagination. Returns list of addresses holding the token with balance amounts and ownership percentages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNameYesThe blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet').
tokenAddressYesThe token contract address to get holders for. Supports ENS, RNS, Lens Handle, and Unstoppable Domain resolution.
blockHeightNoSpecific block height to get historical token holders from. Cannot be used with date parameter.
dateNoSpecific date to get historical token holders from (YYYY-MM-DD format). Cannot be used with blockHeight parameter.
pageSizeNoNumber of token holders to return per page. Maximum is 100.
pageNumberNoPage number for pagination, starting from 0.

Implementation Reference

  • The handler implementation for the 'token_holders' MCP tool. It calls the GoldRush client's getTokenHoldersV2ForTokenAddressByPage method with the provided parameters and returns the formatted response.
    async (params) => {
        try {
            const response =
                await goldRushClient.BalanceService.getTokenHoldersV2ForTokenAddressByPage(
                    params.chainName as Chain,
                    params.tokenAddress,
                    {
                        blockHeight: params.blockHeight,
                        date: params.date,
                        pageSize: params.pageSize,
                        pageNumber: params.pageNumber,
                    }
                );
    
            return {
                content: [
                    {
                        type: "text",
                        text: stringifyWithBigInt(response.data),
                    },
                ],
            };
        } catch (error) {
            return {
                content: [{ type: "text", text: `Error: ${error}` }],
                isError: true,
            };
        }
    }
  • The Zod schema definition for the 'token_holders' tool, defining the input parameters and their validation.
    {
        chainName: z
            .enum(Object.values(ChainName) as [string, ...string[]])
            .describe(
                "The blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet')."
            ),
        tokenAddress: z
            .string()
            .describe(
                "The token contract address to get holders for. Supports ENS, RNS, Lens Handle, and Unstoppable Domain resolution."
            ),
        blockHeight: z
            .union([z.string(), z.number()])
            .optional()
            .describe(
                "Specific block height to get historical token holders from. Cannot be used with date parameter."
            ),
        date: z
            .string()
            .optional()
            .describe(
                "Specific date to get historical token holders from (YYYY-MM-DD format). Cannot be used with blockHeight parameter."
            ),
        pageSize: z
            .number()
            .optional()
            .describe(
                "Number of token holders to return per page. Maximum is 100."
            ),
        pageNumber: z
            .number()
            .optional()
            .describe("Page number for pagination, starting from 0."),
    },
  • Registration of the 'token_holders' tool within the MCP server instance inside the addBalanceServiceTools function.
    server.tool(
        "token_holders",
        "Used to get a paginated list of current or historical token holders for a specified ERC20 or ERC721 token." +
            "Required: chainName (blockchain network), tokenAddress (token contract address). " +
            "Optional: blockHeight or date for historical data, pageSize and pageNumber for pagination. " +
            "Returns list of addresses holding the token with balance amounts and ownership percentages.",
Behavior4/5

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

Without annotations, the description carries the full burden and succeeds in disclosing key behaviors: it notes pagination support, mutual exclusivity of historical query methods (blockHeight vs date), and explicitly describes the return structure ('addresses... with balance amounts and ownership percentages'). It appropriately signals this is a read-only data retrieval operation.

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 well-structured with three distinct sentences covering purpose, parameters, and return values respectively. Information is front-loaded with the core action. Despite a minor formatting issue (missing space after 'token.Required'), every sentence earns its place without redundant verbosity.

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 lack of output schema and annotations, the description adequately compensates by detailing what the tool returns (holder addresses, balances, percentages). It covers all 6 parameters through efficient grouping and explains the pagination and historical query capabilities, providing sufficient context for invocation.

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?

While the schema has 100% description coverage, the description adds valuable semantic grouping by categorizing parameters as 'Required' vs 'Optional' and associating blockHeight/date with 'historical data' and pageSize/pageNumber with 'pagination.' Crucially, it adds the ERC20/ERC721 specificity and 'ownership percentages' context not present in the schema.

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 clearly states the tool retrieves a 'paginated list of current or historical token holders' for 'ERC20 or ERC721' tokens, specifying both the verb (get/retrieve) and resource. It distinguishes from siblings like 'token_balances' or 'erc20_token_transfers' by emphasizing 'holders' and 'ownership percentages,' though the opening 'Used to' is slightly weak.

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

Usage Guidelines2/5

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

The description lists required versus optional parameters but provides no guidance on when to use this tool versus siblings like 'token_balances' or 'historical_token_balances.' It fails to clarify that this tool returns aggregate holder lists rather than balance lookups for specific wallets, leaving the agent to infer usage 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