get_transaction_by_hashGet the full transaction object for a transaction hash (from, to, value, input data, gas, gas price, nonce, block number/hash, transaction index). Returns null if the hash is unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| txhash | Yes | Transaction hash. | |
| chainid | No | Numeric chain id (e.g. 1=Ethereum, 56=BNB, 137=Polygon). Defaults to server config. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds a valuable behavioral detail beyond those annotations: it returns null for unknown hashes, which is important for an agent deciding how to handle missing data. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The verb and resource are front-loaded, and the field list and null-return behavior are compactly placed. Every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup tool, the definition is complete: the schema documents all inputs, annotations cover safety and side-effect profile, and the description enumerates the returned fields and the null behavior. No output schema exists, but the field list compensates adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both txhash and chainid are already documented with types, patterns, and defaults in the schema. The description only restates 'transaction hash' and adds no new parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (transaction by hash), the verb (get), and the exact fields returned, making the purpose unambiguous. It implicitly distinguishes itself from receipt/status siblings by promising the 'full transaction object,' but it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call it when you need the full transaction object for a known hash. However, it gives no explicit guidance about when to prefer this over related siblings like get_transaction_receipt or get_transaction_status, leaving that differentiation to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target clearly distinct data types: balances, transactions, logs, contracts, tokens, gas, and chains. The main confusion risk is between get_transaction_status, get_transaction_receipt_status, and get_transaction_receipt, which all relate to transaction outcomes and could be easily misselected.
Every tool follows the get_<object> or get_<object>_<qualifier> snake_case pattern. The naming is highly predictable and makes the tool purpose evident from the name alone.
20 tools is on the heavier side, approaching the upper bound for a coherent MCP server. However, given Etherscan's broad read-only domain—addresses, transactions, contracts, tokens, logs, and gas—the count is defensible even if it feels somewhat large.
The toolset covers the major Etherscan data-access patterns: balances, normal/internal transactions, receipts, token transfers, contract ABI/source/creation, logs, and gas. Obvious gaps like fetching a block by number/hash or listing transactions within a block are missing, but agents can accomplish most explorer workflows.