Skip to main content
Glama
covalenthq

GoldRush MCP Server

by covalenthq

transaction

Fetch and decode blockchain transaction details including logs, internal transactions, and state changes for comprehensive analysis across multiple networks.

Instructions

Commonly used to fetch and render a single transaction including its decoded log events. Required: chainName (blockchain network), txHash (transaction hash). Optional: quoteCurrency (currency to convert to, USD by default), noLogs (exclude event logs, true by default), withInternal (include internal transactions, false by default), withState (include state changes, false by default), withInputData (include input data, false by default). Tracing features (withInternal, withState, withInputData) supported on the following chains: eth-mainnet Returns comprehensive details about the specified transaction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNameYesThe blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet').
txHashYesThe transaction hash to get details for. Must be a valid transaction hash.
quoteCurrencyNoCurrency to quote transaction values in (e.g., 'USD', 'EUR'). If not specified, uses default quote currency.
noLogsNoExclude event logs from the response for faster performance. Default is true.
withInternalNoInclude internal transaction traces. Only supported on eth-mainnet. Default is false.
withStateNoInclude state changes in the response. Only supported on eth-mainnet. Default is false.
withInputDataNoInclude transaction input data in the response. Only supported on eth-mainnet. Default is false.

Implementation Reference

  • The "transaction" tool is registered using `server.tool` and defined with Zod schemas for validation. The handler function calls `goldRushClient.TransactionService.getTransaction` to fetch the transaction details.
    server.tool(
        "transaction",
        "Commonly used to fetch and render a single transaction including its decoded log events.\n" +
            "Required: chainName (blockchain network), txHash (transaction hash).\n" +
            "Optional: quoteCurrency (currency to convert to, USD by default), " +
            "noLogs (exclude event logs, true by default), " +
            "withInternal (include internal transactions, false by default), " +
            "withState (include state changes, false by default), " +
            "withInputData (include input data, false by default).\n" +
            "Tracing features (withInternal, withState, withInputData) supported on the following chains: eth-mainnet\n" +
            "Returns comprehensive details about the specified transaction.",
        {
            chainName: z
                .enum(Object.values(ChainName) as [string, ...string[]])
                .describe(
                    "The blockchain network to query (e.g., 'eth-mainnet', 'matic-mainnet', 'bsc-mainnet')."
                ),
            txHash: z
                .string()
                .describe(
                    "The transaction hash to get details for. Must be a valid transaction hash."
                ),
            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()
                .default(true)
                .describe(
                    "Exclude event logs from the response for faster performance. Default is true."
                ),
            withInternal: z
                .boolean()
                .optional()
                .describe(
                    "Include internal transaction traces. Only supported on eth-mainnet. Default is false."
                ),
            withState: z
                .boolean()
                .optional()
                .describe(
                    "Include state changes in the response. Only supported on eth-mainnet. Default is false."
                ),
            withInputData: z
                .boolean()
                .optional()
                .describe(
                    "Include transaction input data in the response. Only supported on eth-mainnet. Default is false."
                ),
        },
        async (params) => {
            try {
                const response =
                    await goldRushClient.TransactionService.getTransaction(
                        params.chainName as Chain,
                        params.txHash,
                        {
                            quoteCurrency: params.quoteCurrency as Quote,
                            noLogs: params.noLogs,
                            withInternal: params.withInternal,
                            withState: params.withState,
                            withInputData: params.withInputData,
                        }
                    );
                return {
                    content: [
                        {
                            type: "text",
                            text: stringifyWithBigInt(response.data),
                        },
                    ],
                };
            } catch (error) {
                return {
                    content: [{ type: "text", text: `Error: ${error}` }],
                    isError: true,
                };
            }
        }
    );
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates chain-specific limitations (tracing only on eth-mainnet), performance implications (noLogs for faster performance), and default values (USD, true/false flags). However, it lacks explicit mention of error handling (e.g., invalid txHash) or read-only safety guarantees.

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?

The description is well-structured and front-loaded: purpose first, then required parameters, optional parameters with defaults, specific behavioral constraints (chain support), and return value. Every sentence conveys unique information with no redundancy.

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, the description compensates by listing what can be included (log events, internal transactions, state changes, input data). It covers the 7 parameters comprehensively. A score of 5 would require detailing the response structure or error scenarios; 'Returns comprehensive details' remains somewhat vague.

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%, establishing a baseline of 3. The description adds value by specifying 'USD by default' (where the schema only mentions 'default quote currency'), grouping the three 'tracing features' conceptually, and explicitly labeling required vs. optional parameters upfront, which aids agent comprehension beyond raw schema parsing.

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] and render[s] a single transaction including its decoded log events,' using specific verbs and distinguishing it from sibling tools like 'transactions_for_address' (plural) by emphasizing 'single transaction' and requiring a specific 'txHash.'

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?

While it doesn't explicitly name sibling alternatives, it provides critical usage constraints: tracing features (withInternal, withState, withInputData) are only supported on 'eth-mainnet.' It also distinguishes required vs. optional parameters, guiding the agent on minimum viable invocation.

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