Skip to main content
Glama
covalenthq

GoldRush MCP Server

by covalenthq

log_events_by_address

Retrieve decoded event logs from a smart contract address to monitor on-chain activity, analyze interactions, and build dashboards. Supports multiple blockchains and optional block range filtering.

Instructions

Commonly used to get all the event logs emitted from a particular contract address. Useful for building dashboards that examine on-chain interactions.Requires chainName (blockchain network) and contractAddress (the address emitting events). Optional parameters include block range (startingBlock, endingBlock) and pagination settings (pageSize default 10, pageNumber default 0). Returns decoded event logs for the specified contract, useful for monitoring specific smart contract activity and analyzing on-chain events.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNameYesThe blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet').
contractAddressYesThe smart contract address to get event logs from. Supports ENS, RNS, Lens Handle, and Unstoppable Domain resolution.
startingBlockNoStarting block number to begin search from. Use with endingBlock to define a range.
endingBlockNoEnding block number to search until. Use with startingBlock to define a range.
pageSizeNoNumber of log events to return per page. Default is 10, maximum is 100.
pageNumberNoPage number for pagination, starting from 0. Default is 0.

Implementation Reference

  • Registration and implementation of the "log_events_by_address" MCP tool. The handler calls `goldRushClient.BaseService.getLogEventsByAddressByPage`.
    server.tool(
        "log_events_by_address",
        "Commonly used to get all the event logs emitted from a particular contract address. " +
            "Useful for building dashboards that examine on-chain interactions." +
            "Requires chainName (blockchain network) and contractAddress (the address emitting events). " +
            "Optional parameters include block range (startingBlock, endingBlock) and pagination settings " +
            "(pageSize default 10, pageNumber default 0). " +
            "Returns decoded event logs for the specified contract, useful for monitoring specific " +
            "smart contract activity and analyzing on-chain events.",
        {
            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 smart contract address to get event logs from. Supports ENS, RNS, Lens Handle, and Unstoppable Domain resolution."
                ),
            startingBlock: z
                .union([z.string(), z.number()])
                .optional()
                .describe(
                    "Starting block number to begin search from. Use with endingBlock to define a range."
                ),
            endingBlock: z
                .union([z.string(), z.number()])
                .optional()
                .describe(
                    "Ending block number to search until. Use with startingBlock to define a range."
                ),
            pageSize: z
                .number()
                .optional()
                .default(10)
                .describe(
                    "Number of log events to return per page. Default is 10, maximum is 100."
                ),
            pageNumber: z
                .number()
                .optional()
                .default(0)
                .describe(
                    "Page number for pagination, starting from 0. Default is 0."
                ),
        },
        async (params) => {
            try {
                const response =
                    await goldRushClient.BaseService.getLogEventsByAddressByPage(
                        params.chainName as Chain,
                        params.contractAddress,
                        {
                            startingBlock: params.startingBlock,
                            endingBlock: params.endingBlock,
                            pageSize: params.pageSize,
                            pageNumber: params.pageNumber,
                        }
                    );
                return {
                    content: [
                        {
                            type: "text",
                            text: stringifyWithBigInt(response.data),
                        },
                    ],
                };
            } catch (err) {
                return {
                    content: [{ type: "text", text: `Error: ${err}` }],
                    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 valuable behavioral context by specifying that logs are 'decoded' and documents pagination defaults. However, it lacks details on rate limits, maximum block ranges, or error conditions (e.g., invalid contract address behavior).

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?

While front-loaded with the primary purpose, the description suffers from repetition ('Useful for' appears twice with similar context) and a structural error (missing space after 'interactions.Requires'). It is appropriately sized but could be more efficiently written.

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 an output schema, the description compensates by explicitly stating what is returned ('Returns decoded event logs'). It addresses all 6 parameters (required and optional) and explains their groupings (block range, pagination), providing sufficient completeness for a read-only query tool.

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 description coverage is 100%, establishing a baseline of 3. The description mirrors the schema's content (listing parameters and their purposes) without adding significant semantic depth beyond what the schema already provides (e.g., no additional format guidance or validation rules).

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 uses a specific verb ('get') and resource ('event logs') and explicitly scopes the tool to 'from a particular contract address,' which effectively distinguishes it from the sibling tool 'log_events_by_topic'. The purpose is immediately clear.

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?

The description provides context on when to use the tool ('Commonly used to...', 'Useful for building dashboards', 'monitoring specific smart contract activity'), but fails to mention when NOT to use it or explicitly name 'log_events_by_topic' as the alternative for topic-based filtering.

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