Skip to main content
Glama
blockscout

Blockscout MCP Server

Official

get_transaction_info

Read-only

Retrieve detailed blockchain transaction data including decoded parameters, token transfers, fee breakdowns, and transaction types for analysis and debugging.

Instructions

Get comprehensive transaction information.
Unlike standard eth_getTransactionByHash, this tool returns enriched data including decoded input parameters, detailed token transfers with token metadata, transaction fee breakdown (priority fees, burnt fees) and categorized transaction types.
By default, the raw transaction input is omitted if a decoded version is available to save context; request it with `include_raw_input=True` only when you truly need the raw hex data.
Essential for transaction analysis, debugging smart contract interactions, tracking DeFi operations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chain_idYesThe ID of the blockchain
transaction_hashYesTransaction hash
include_raw_inputNoIf true, includes the raw transaction input data.

Implementation Reference

  • The main asynchronous handler function that fetches transaction data from Blockscout API, processes it (including truncation), transforms it, and returns a structured ToolResponse with TransactionInfoData.
    @log_tool_invocation
    async def get_transaction_info(
        chain_id: Annotated[str, Field(description="The ID of the blockchain")],
        transaction_hash: Annotated[str, Field(description="Transaction hash")],
        ctx: Context,
        include_raw_input: Annotated[
            bool | None, Field(description="If true, includes the raw transaction input data.")
        ] = False,
    ) -> ToolResponse[TransactionInfoData]:
        """
        Get comprehensive transaction information.
        Unlike standard eth_getTransactionByHash, this tool returns enriched data including decoded input parameters, detailed token transfers with token metadata, transaction fee breakdown (priority fees, burnt fees) and categorized transaction types.
        By default, the raw transaction input is omitted if a decoded version is available to save context; request it with `include_raw_input=True` only when you truly need the raw hex data.
        Essential for transaction analysis, debugging smart contract interactions, tracking DeFi operations.
        """  # noqa: E501
        api_path = f"/api/v2/transactions/{transaction_hash}"
    
        await report_and_log_progress(
            ctx,
            progress=0.0,
            total=2.0,
            message=f"Starting to fetch transaction info for {transaction_hash} on chain {chain_id}...",
        )
    
        base_url = await get_blockscout_base_url(chain_id)
    
        await report_and_log_progress(
            ctx, progress=1.0, total=2.0, message="Resolved Blockscout instance URL. Fetching transaction data..."
        )
    
        response_data = await make_blockscout_request(base_url=base_url, api_path=api_path)
    
        await report_and_log_progress(ctx, progress=2.0, total=2.0, message="Successfully fetched transaction data.")
    
        processed_data, was_truncated = _process_and_truncate_tx_info_data(response_data, include_raw_input)
    
        final_data_dict = _transform_transaction_info(processed_data)
    
        transaction_data = TransactionInfoData(**final_data_dict)
    
        notes = None
        if was_truncated:
            notes = [
                (
                    "One or more large data fields in this response have been truncated "
                    '(indicated by "value_truncated": true or "raw_input_truncated": true).'
                ),
                (
                    f"To get the full, untruncated data, you can retrieve it programmatically. "
                    f'For example, using curl:\n`curl "{str(base_url).rstrip("/")}/api/v2/transactions/{transaction_hash}"`'
                ),
            ]
    
        instructions = [
            (
                "To check for ERC-4337 User Operations related to this tx, call "
                f"`direct_api_call` with endpoint `/api/v2/proxy/account-abstraction/operations` "
                f"with query_params={{'transaction_hash': '{transaction_hash}'}}."
            )
        ]
        return build_tool_response(data=transaction_data, notes=notes, instructions=instructions)
  • Registration of the get_transaction_info tool with the FastMCP server instance, including annotations.
        structured_output=False,
        annotations=create_tool_annotations("Get Transaction Information"),
    )(get_transaction_info)
  • Pydantic models defining the output schema for get_transaction_info: TransactionInfoData (main), TokenTransfer, and DecodedInput. Used in the tool's return type ToolResponse[TransactionInfoData].
    # --- Model for get_transaction_info Data Payload ---
    class TokenTransfer(BaseModel):
        """Represents a single token transfer within a transaction."""
    
        model_config = ConfigDict(extra="allow")  # External APIs may add new fields; allow them to avoid validation errors
    
        from_address: str | None = Field(alias="from", description="Sender address of the token transfer if available.")
        to_address: str | None = Field(alias="to", description="Recipient address of the token transfer if available.")
        token: dict[str, Any] = Field(description="Token metadata dictionary associated with the transfer.")
        transfer_type: str = Field(alias="type", description="Type of transfer (e.g., 'transfer', 'mint').")
    
    
    # --- Model for get_transaction_info Data Payload ---
    class DecodedInput(BaseModel):
        """Represents the decoded input data of a transaction."""
    
        model_config = ConfigDict(extra="allow")  # External APIs may add new fields; allow them to avoid validation errors
    
        method_call: str = Field(description="Name of the called method.")
        method_id: str = Field(description="Identifier of the called method.")
        parameters: list[Any] = Field(description="List of decoded input parameters for the method call.")
    
    
    # --- Model for get_transaction_info Data Payload ---
    class TransactionInfoData(BaseModel):
        """Structured representation of get_transaction_info data."""
    
        model_config = ConfigDict(extra="allow")  # External APIs may add new fields; allow them to avoid validation errors
    
        from_address: str | None = Field(
            default=None,
            alias="from",
            description="Sender of the transaction if available.",
        )
        to_address: str | None = Field(
            default=None,
            alias="to",
            description="Recipient of the transaction if available.",
        )
    
        token_transfers: list[TokenTransfer] = Field(
            default_factory=list, description="List of token transfers related to the transaction."
        )
        decoded_input: DecodedInput | None = Field(
            default=None,
            description="Decoded method input if available.",
        )
    
        raw_input: str | None = Field(default=None, description="Raw transaction input data if returned.")
        raw_input_truncated: bool | None = Field(default=None, description="Indicates if raw_input was truncated.")
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable behavioral context beyond annotations: it specifies that raw input is omitted by default to save context, explains the enriched data types returned (decoded parameters, token metadata, fee breakdown), and notes the tool's utility for specific use cases. No contradictions with annotations exist.

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, starting with the core purpose, followed by key differentiators, parameter guidance, and use cases. Each sentence adds distinct value without redundancy, and the length is appropriate for the tool's complexity. There is no wasted text.

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 tool's complexity (enriched transaction data) and lack of an output schema, the description does a good job explaining what information is returned (decoded parameters, token transfers with metadata, fee breakdown, transaction types). However, it doesn't detail the exact structure or format of the enriched data, which could be helpful for an agent. Annotations cover safety aspects adequately.

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%, so the schema fully documents the three parameters (chain_id, transaction_hash, include_raw_input). The description adds minimal semantic value beyond the schema: it clarifies that include_raw_input=True is for 'raw hex data' and implies chain_id selects the blockchain, but doesn't provide additional details like format examples or constraints. This meets the baseline for high schema coverage.

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's purpose with specific verbs ('get comprehensive transaction information') and resources ('transaction'), distinguishing it from siblings like 'transaction_summary' by emphasizing enriched data including decoded parameters, token transfers, fee breakdown, and transaction types. It explicitly contrasts with standard eth_getTransactionByHash, establishing its unique value.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool ('essential for transaction analysis, debugging smart contract interactions, tracking DeFi operations') and when to use the include_raw_input parameter ('only when you truly need the raw hex data'). It implicitly contrasts with simpler alternatives like 'transaction_summary' by highlighting comprehensive data, though it doesn't name specific siblings as alternatives.

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/blockscout/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server