Skip to main content
Glama
covalenthq

GoldRush MCP Server

by covalenthq

transactions_for_block

Fetch all transactions and decoded log events from a specific blockchain block to analyze transaction data and identify notable wallets or activities.

Instructions

Commonly used to fetch all transactions including their decoded log events in a block and further flag interesting wallets or transactions. Required: chainName (blockchain network), blockHeight (block number or latest). Optional: quoteCurrency, noLogs (exclude event logs). Returns all transactions from the specified block.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNameYesThe blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet').
blockHeightYesThe block number to get transactions from. Can be a block number or 'latest' for the most recent block.
pageYesPage number for pagination, starting from 0. Each page contains multiple transactions from the block.
quoteCurrencyNoCurrency to quote transaction values in (e.g., 'USD', 'EUR'). If not specified, uses default quote currency.
noLogsNoExclude event logs from transactions for faster performance. Default varies by implementation.

Implementation Reference

  • The handler function for 'transactions_for_block', which uses GoldRushClient to fetch paginated transactions for a given block.
        async (params) => {
            try {
                const response =
                    await goldRushClient.TransactionService.getTransactionsForBlockByPage(
                        params.chainName as Chain,
                        params.blockHeight,
                        params.page,
                        {
                            quoteCurrency: params.quoteCurrency as Quote,
                            noLogs: params.noLogs,
                        }
                    );
                return {
                    content: [
                        {
                            type: "text",
                            text: stringifyWithBigInt(response.data),
                        },
                    ],
                };
            } catch (err) {
                return {
                    content: [{ type: "text", text: `Error: ${err}` }],
                    isError: true,
                };
            }
        }
    );
  • Zod schema defining the input parameters for 'transactions_for_block'.
    {
        chainName: z
            .enum(Object.values(ChainName) as [string, ...string[]])
            .describe(
                "The blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet')."
            ),
        blockHeight: z
            .union([z.string(), z.number(), z.literal("latest")])
            .describe(
                "The block number to get transactions from. Can be a block number or 'latest' for the most recent block."
            ),
        page: z
            .number()
            .describe(
                "Page number for pagination, starting from 0. Each page contains multiple transactions from the block."
            ),
        quoteCurrency: z
            .enum(Object.values(validQuoteValues) as [string, ...string[]])
            .optional()
            .describe(
                "Currency to quote transaction values in (e.g., 'USD', 'EUR'). If not specified, uses default quote currency."
            ),
        noLogs: z
            .boolean()
            .optional()
            .describe(
                "Exclude event logs from transactions for faster performance. Default varies by implementation."
            ),
    },
  • Tool registration for 'transactions_for_block' within the McpServer.
    server.tool(
        "transactions_for_block",
        "Commonly used to fetch all transactions including their decoded log events in a block and further flag interesting wallets or transactions.\n" +
            "Required: chainName (blockchain network), blockHeight (block number or latest).\n" +
            "Optional: quoteCurrency, noLogs (exclude event logs).\n" +
            "Returns all transactions from the specified block.",
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 correctly discloses that decoded log events are included by default and can be excluded via noLogs. However, it claims the tool 'Returns all transactions' without mentioning pagination behavior, which contradicts the presence of the required 'page' parameter and could mislead about response completeness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured logically with purpose first, then parameters, then return value. However, the omission of the 'page' parameter wastes the agent's time by requiring schema cross-referencing to discover required fields. The 'further flag interesting wallets' clause adds conceptual clutter without clear behavioral meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 should provide comprehensive invocation context. It fails to mention the required pagination parameter ('page'), explain pagination mechanics, or describe the structure of returned transaction data beyond 'all transactions'. This leaves significant gaps for correct tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description selectively documents parameters, completely omitting the required 'page' parameter while mentioning optional ones like quoteCurrency. This inconsistency fails to provide the compact parameter overview needed for quick invocation, falling below the baseline expectation for a 5-parameter tool.

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 fetches transactions with decoded log events from a specific block, using specific verbs and resources. It distinguishes from siblings like 'transactions_for_address' by specifying the block-based scope. However, the phrase 'further flag interesting wallets or transactions' is vague—it is unclear if the tool performs this flagging or if this is merely a suggested use case.

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?

While the description lists required parameters (chainName, blockHeight), it critically omits the 'page' parameter which the schema marks as required. This creates misleading invocation guidance. It also fails to mention when to use this versus 'transaction' (singular) or 'transactions_for_address', or explain the pagination behavior implied by the page parameter.

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