Etherscan

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

Annotations already declare the operation as read-only, open-world, idempotent, and non-destructive, so the safety profile is covered. The description adds useful context about the kind of data returned, but it does not describe behavior such as error cases, response shape, or default chain-id handling. It adds moderate value beyond annotations but is not rich in behavioral detail.

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?

The description is a single sentence that front-loads the action and resource, then provides a useful parenthetical list of example attributes. There is no filler or redundant restatement of the tool name, making it compact and effective.

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?

With no output schema, the description provides a reasonable sense of return contents by listing categories such as trust rating and source-code status. It could be more explicit about default chain behavior and handling of unknown addresses, but for a simple read-only lookup with well-defined parameters, it is substantially complete.

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 description coverage is 100%, so both parameters are already documented with types, formats, and an example for chainid. The description does not add parameter-specific semantics beyond indicating the result is tied to an address. Baseline 3 is appropriate given the complete 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 uses a specific verb and resource: it retrieves address labels and attributes, with concrete examples like token type, trust rating, and contract name. This clearly differentiates it from sibling tools such as get_contract_abi or get_token_info, making the tool's distinct purpose immediately recognizable.

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 description clearly implies the use case: when an agent needs public metadata or labels for a blockchain address. It does not explicitly name alternatives or exclusion conditions, but the domain and examples make it obvious when this tool is appropriate relative to the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'closest' behavior and the seconds unit, but it does not mention tie-breaking, default 'before' behavior, or edge cases when no block exists.

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?

The description is a single focused sentence with no filler. It front-loads the operation, resource, and key input constraint while leaving parameter details to the schema.

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 read-only lookup tool with full schema coverage and safety-bearing annotations, the description is complete. It states the result ('block number') and the input (Unix timestamp in seconds), which is sufficient for an agent to select and call the tool correctly.

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 description coverage is 100%, so the schema fully documents all three parameters. The description only restates that the timestamp is in Unix seconds, adding no semantic information 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 uses a specific verb and resource: 'Get the block number closest to a given Unix timestamp (seconds).' It clearly defines what is returned and the input concept, and it is distinct from all sibling tools, none of which map timestamps to block numbers.

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 description makes the core use case clear: convert a Unix timestamp into the closest block number. It does not explicitly name alternatives or exclusions, but no sibling tool serves this exact purpose, so the intended usage is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds 'verified' and 'JSON' but does not explain behavior for unverified contracts, error cases, or chain fallback behavior; this is acceptable but not rich.

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?

A single well-formed sentence that front-loads the key verb and resource with no filler or redundancy. Every word contributes to meaning.

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 read-only lookup with full schema coverage and safety annotations, this description is nearly complete. It states the JSON return format; the only notable omission is behavior when no verified ABI exists, which is a minor gap.

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 description coverage is 100%, with address pattern and chainid examples/defaults already documented. The description adds no parameter-level detail beyond naming the contract address, so the baseline of 3 applies.

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 states a specific verb ('Get') and a clear resource ('verified ABI (JSON) for a contract address'). This distinguishes it from sibling tools like get_contract_source or get_contract_creation, which address different artifacts.

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?

No explicit guidance is given on when to use this tool versus alternatives, and no conditions or exclusions are mentioned. Among many similar get_* tools, the description leaves the agent to infer routing from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already communicate read-only, idempotent, non-destructive behavior, so the description only needs to add context. It adds the returned fields but not edge-case behavior such as how missing or non-contract addresses are handled; this is acceptable but not exceptional given the 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?

One sentence that states the operation, key outputs, and cardinality constraint with no filler. The most important identifying information is front-loaded.

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 low-complexity read tool, the schema covers both parameters and annotations cover safety. The description names the two outputs despite the lack of an output schema; only minor details like exact response field names and error behavior are omitted.

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 description coverage is 100%: chainid default/format and contractaddresses pattern/min/max are already documented. The description's 'up to 5' repeats the schema's maxItems rather than adding new parameter meaning.

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 names a specific resource (contract addresses), a specific verb (get), and the exact returned data (creator address and creation transaction hash). It also states the batch scope of up to 5, distinguishing it from sibling contract tools like get_contract_abi and get_contract_source.

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 context is clear: use this tool when you need contract creation provenance for one or more addresses. It does not explicitly enumerate alternatives or exclusion cases, but the sibling names are dissimilar enough that no alternative would be confused.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), lowering the burden. The description adds the qualifier that the source is 'verified', implying behavior for unverified contracts but without stating it. No contradiction exists, but there is little extra behavioral context beyond the schema and 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?

Single sentence with no filler, front-loaded with the verb and object. It is easily scanned and every word earns its place.

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 low-complexity read-only tool with no output schema, the description states the core return value ('verified source code and metadata') and the schema covers parameter defaults. It lacks an explicit note about unverified contracts or chainid behavior, but these are minor given annotations. Complete enough for a simple call.

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 description coverage is 100%, so both address and chainid are documented in the input schema. The description adds no parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate.

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 uses a specific verb ('Get') and resource ('verified source code and metadata for a contract address'), making the tool's function unambiguous. It is distinguishable from sibling tools such as get_contract_abi, though it does not explicitly name alternatives. This is clear but relies on the reader to infer differentiation.

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?

No guidance is given for when to choose this tool over get_contract_abi, get_contract_creation, or other sibling tools. The description only states what it does, not when to use it or when not to. This leaves selection to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the 'first funded' temporal scoping and clarifies that the result is an address, not a transaction list. It does not mention edge cases like missing funding history, but the safety profile is fully covered.

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?

The definition is a single, waste-free sentence that front-loads the verb and the result concept. Every word contributes meaning.

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?

With only two parameters, complete schema documentation, and read-only/idempotent annotations, the tool is easy to invoke correctly. The lack of an output schema is mitigated by the description stating the output is an address, though edge cases are not discussed.

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%: both address and chainid already include validation patterns and descriptive text. The description does not add parameter-specific detail beyond saying the address is the one to trace, so the schema carries the burden.

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 is specific: it names the operation (get), the resource (an address), and the precise result (the address that first funded it). This clearly distinguishes it from siblings like get_transactions or get_contract_creation by focusing on the initial funding source.

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 use case is clear: given an address, return the source of its initial funds. It does not explicitly name alternatives or exclusions, but among the many get_* siblings its purpose is unique enough that an agent can infer when to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description only needs to add context. It adds that the data is 'current' and sourced from the gas tracker, which aligns with the annotations and gives the agent useful situational awareness.

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?

The description is a single sentence that states the action, source, and output categories with no filler. It is front-loaded and every word earns its place.

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 read-only tool with one optional parameter and no output schema, the description plus annotations cover the essentials. The only minor gap is exact output units or JSON format, but the named return categories are sufficient for correct invocation.

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?

The input schema fully documents the only parameter, including pattern, example chain IDs, and default behavior, so the description does not need to repeat it. Since schema description coverage is 100%, the baseline of 3 is appropriate.

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 uses a specific verb ('Get'), names the resource ('gas tracker'), and identifies the exact output categories ('safe / propose / fast'). It is clearly distinct from the many transaction/address/contract sibling tools.

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 description implies the tool is for retrieving current gas price recommendations, and no sibling tool covers gas prices, so there is no direct alternative to confuse it with. However, it does not explicitly state when to use it or mention that chainid is optional depending on server configuration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It adds a little context via address/txhash lookup modes, but says nothing about rate limits, data availability, pagination behavior, or response structure, and it does not contradict the 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?

The description is a single, front-loaded sentence that names the resource and the two primary lookup modes without filler. It repeats nothing from the schema and earns every word.

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 read-only list tool with strong annotations and full schema coverage, the description is sufficient for basic invocation: it tells the agent the resource and the two access paths. It does not explicitly state the return shape or enforce that address/txhash are mutually exclusive, but neither omission prevents a reasonable agent from selecting and calling the tool.

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?

The schema already has 100% parameter description coverage, so the description is not required to explain each field. The address-vs-txhash distinction is present in both the schema and the description, and the description adds no new format, default, or mutual-exclusivity detail 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 states a specific verb and resource ('Get internal transactions') and identifies two query modes: by address or by parent transaction hash. It is clear and distinct from the sibling get_transactions by the word 'internal' and the mention of 'parent transaction hash,' though it does not explicitly contrast itself with that sibling.

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 description gives no guidance about when to choose this tool over alternatives like get_transactions, get_logs, or get_transaction_by_hash. It only describes what the tool does, not when it should be used and when it should not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful topic semantics (topic0 is usually the keccak256 event-signature hash) but does not disclose operational details like pagination or return behavior, which annotations do not cover.

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?

Three tight sentences: what the tool does, the key topic convention, and the required input condition. No filler, and the most important usage rule is front-loaded.

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?

Despite 13 parameters, the schema documents every parameter completely. The description provides the core selection/invocation insight (what topic0 means and that at least one filter is needed), which is enough for an agent to use the tool correctly alongside the schema and annotations.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining why topic0 matters (event-signature hash), how adjacent-topic operators combine filters, and the minimum filter requirement, going slightly beyond the schema's per-parameter wording.

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?

States the specific action 'Search event logs' with clear filters (contract address and/or topics) over a block range. This distinguishes it from sibling transaction/token tools without needing to open the schema.

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?

Gives clear usage context: event logs, block range, address/topic filters, and the explicit requirement to provide an address and/or at least one topic. It does not name alternative tools with exclusions, but no sibling directly competes for event logs, so the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The annotations already establish that this is read-only, idempotent, and non-destructive. The description adds the return unit ('in wei') and clarifies that the tool queries native coin balances rather than contracts or tokens, providing useful semantic context beyond the 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?

The description is a single sentence with no filler. It front-loads the key scoping information (native coin, address, wei) and is immediately understandable.

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 read-only balance lookup, the description together with the fully described schema and safety annotations covers everything needed to call the tool correctly. The unit and resource are explicit, and no missing behavioral or return information is critical.

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?

The input schema documents all three parameters with descriptions, so schema coverage is 100%. The description does not need to repeat parameter details and adds no extra parameter-level nuance beyond what the schema already provides.

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 states a specific verb and resource: 'Get the native coin (e.g. ETH) balance of an address'. It also specifies the unit (wei), making the tool's purpose unmistakable and distinguishing it from token balance queries.

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 phrase 'native coin' implies this is for native balances rather than token balances, but no sibling tool is explicitly named and no when-to-use vs. when-not-to-use guidance is provided. The usage context is only implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish that this is read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds that the result is a list of chains/chain IDs, but does not describe the output structure, ordering, or any other behavioral nuance. Given the simple zero-parameter nature, this is reasonable, but it adds only minimal behavioral context beyond 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?

The description is a single sentence with no filler. It front-loads the verb and resource, and every word adds value. This is an example of appropriately concise specification.

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 tool with no parameters, no output schema, and a trivially simple purpose, the description is complete. An agent knows exactly what action to perform and what information to expect. No additional context is necessary to invoke this tool correctly.

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?

The input schema has zero properties, so there are no parameters to document. The baseline for no parameters is 4, and the description correctly avoids inventing parameter details. It focuses on the output, which is appropriate here.

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 states a specific verb ('Get') and a precise resource ('list of chains / chain IDs supported by the API'). It clearly distinguishes this from sibling tools, which focus on individual assets or transactions, making the tool's scope unmistakable.

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 description implies the usage context: call this when you need to know which chains or chain IDs the API supports. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. For a tool with no overlapping siblings, the implied guidance is adequate but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark the operation read-only, idempotent, open-world, and non-destructive. The description adds non-obvious behavior by disclosing that tokens without a USD price are omitted from results, which could surprise callers expecting a complete balance report. This is genuine added transparency beyond the structured 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 filler; the core operation is first, followed by the essential output/filter detail. Every clause earns its place and the text is appropriately sized for the tool's complexity.

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 read-only paginated list tool, the description covers the required semantics (address-based ERC-20 balances), output shape (human-readable quantities and USD values), and noteworthy filtering behavior. The schema covers all parameter details and annotations cover safety, so no critical invocation-relevant information is missing.

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 description coverage is 100%, so address, chainid, page, and offset are already documented. The description does not add parameter-level detail beyond mentioning that balances are tied to 'an address' and that USD filtering occurs; it neither compensates for gaps nor overrepeats schema content.

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?

Clearly identifies the operation ('Get'), resource ('ERC-20 tokens held by an address'), and output characteristics ('human-readable quantities and USD values'). It also states an important selection behavior (filtering tokens without USD prices), which distinguishes it from sibling balance/list tools like get_native_balance and get_token_transfers.

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 description implies the tool should be used when an agent needs an address's ERC-20 holdings with USD valuations, but it never explicitly states when to prefer it over siblings or when not to use it (e.g., native balance via get_native_balance, token metadata via get_token_info). No alternatives or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so safety is covered. The description adds the returned field set but does not disclose potential data sparsity, missing socials, price availability, or default chain behavior beyond the schema.

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?

A single, front-loaded sentence with a clear field list and no filler words. It efficiently communicates the tool's purpose without restating schema or annotation content.

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 read-only metadata lookup with only two well-documented parameters and annotations covering safety, the description is largely sufficient. It could be improved by explicitly noting that price/socials may be absent, but the openWorldHint and 'etc.' provide acceptable openness.

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 description coverage is 100%, with both chainid and contractaddress described. The description adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate.

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?

Description names a specific verb ('Get') and resource ('token project details and social links for a contract') with an explicit field list. This clearly differentiates it from sibling tools like get_token_balances, get_token_top_holders, and get_token_transfers, which serve different purposes.

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 description implies usage: when you need token metadata and social links rather than balances or transfers. However, it does not explicitly mention sibling alternatives or state when not to use this tool, leaving usage boundaries to be inferred from the field list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some context by noting that results include each holder's address and quantity, but it does not disclose ordering semantics, the unit of quantity, pagination behavior, or defaults beyond what the schema provides.

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?

The description is a single concise sentence that front-loads the core verb and resource. It contains no filler and every phrase contributes 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 read-only query with well-documented parameters and annotations, the description covers the operation, the target resource, and the basic return shape. It is missing minor details like ordering direction and quantity unit, but nothing blocks a competent agent from invoking the tool correctly.

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 description coverage is 100%, so the schema already documents contractaddress, limit, and chainid. The description does not add meaningful parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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 operation ('Get'), the resource ('top holders of an ERC-20 token contract'), and the output content ('each holder's address and quantity'). It does not explicitly differentiate itself from sibling tools like get_token_balances, but the 'top holders' framing makes the purpose distinct and unambiguous.

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 description explains what the tool does but gives no guidance on when to use it or when to prefer a sibling such as get_token_balances or get_token_info. There are no exclusions, prerequisites, or contextual hints beyond the implied use case of inspecting token holder distributions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the default token standard (erc20) and the optional contract filter behavior, which is useful beyond the annotations. It doesn't mention pagination or response limits, but those are hinted in the schema (page/offset).

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?

The description is compact and front-loaded with the core purpose, followed by the optional filter and token-standard guidance. The token-standard list and defaults are useful and concise. Minor redundancy exists with the schema's enum documentation, but the practical guidance is worthwhile.

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 read-only list endpoint with fully documented schema and 100% parameter coverage, the description is sufficient for an agent to select and invoke it. Output structure is absent, but no output schema exists and the description's role in describing returns is minor. The lack of explicit pagination behavior guidance is a small gap.

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 description coverage is 100%, so the schema already documents every parameter. The description adds value by explaining the default standard and the filtering concept, but it does not elaborate on parameter relationships, like how contractaddress only applies to the chosen standard. This is adequate but not exceptional.

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 states a specific verb ('Get') and resource ('token transfer events for an address'), and adds optional filter context. It doesn't explicitly contrast with sibling tools like get_internal_transactions or get_transactions, but the token-specific focus and standard selection make the purpose clear and reasonably distinctive.

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 description conveys clear usage context: use this tool for token transfer events, optionally filtered by token contract, with a token standard selector. It does not explicitly name alternatives or exclusion conditions, but the narrow scope and token-standard discussion imply when it applies versus sibling transaction/log tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by disclosing that the tool returns null for unknown or pending hashes and enumerating the receipt fields returned. This goes beyond the structured annotations without contradicting them.

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?

A single well-structured sentence front-loads the core action, follows with the return content, and ends with the null behavior. No wasted words; every clause earns its place.

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 getter with no output schema, the description covers the essential return fields and the null case. It is slightly incomplete only in not differentiating from receipt_status, but the tool can still be invoked correctly with the given information.

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 description coverage is 100%, so the schema already documents txhash and chainid fully. The description does not add parameter-specific context beyond the schema, which is fine but not value-adding. Baseline 3 applies.

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 states the verb 'Get' and the resource 'transaction receipt', listing the concrete contents (gas, logs, contract address). However, it does not explicitly distinguish itself from the closely named sibling get_transaction_receipt_status, so it falls short of full differentiation.

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?

There is no explicit guidance on when to use this tool versus alternatives like get_transaction_receipt_status or get_transaction_status. The null-for-pending clause hints at one use case but does not state exclusions or selection conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover safety traits (readOnly, idempotent, non-destructive), so the description's added value is the 1/0 result coding and the Post-Byzantium limitation. It does not describe behavior for pre-Byzantium transactions or not-found cases, but there is no contradiction with the 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?

One concise sentence communicates the operation, output mapping, and a key constraint with no filler. The most important information is front-loaded.

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 low-complexity tool with full schema coverage, the description is mostly sufficient, and the 1/0 mapping compensates for the missing output schema. The main gap is the lack of sibling disambiguation and undefined edge-case behavior for pre-Byzantium blocks, which leaves some room for agent misrouting.

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%: both txhash and chainid are documented with formats and defaults. The description adds no parameter-level semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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?

Description uses a specific verb and resource ('get receipt status'), and explicitly defines the output meaning (1 = success, 0 = failed), so the core behavior is clear. It does not explicitly differentiate from sibling tools like get_transaction_receipt or get_transaction_status, which an agent could confuse with this one.

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 'Post-Byzantium only' constraint gives a clear precondition for use. However, no alternative tool is mentioned, so the description leaves it to the agent to infer when to prefer get_transaction_receipt or get_transaction_status instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds only the external-transaction scoping, which is useful but does not add deeper behavioral context such as pagination behavior, default chain handling, or result variability.

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?

The description is a single, front-loaded sentence that states the core action and resource with no filler. The '(external)' clarification is packed efficiently into the main clause.

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?

Although the tool has seven parameters and no output schema, the schema documents all parameters thoroughly and annotations cover safety and idempotence. The description adds the essential semantic distinction between external and internal transactions, which is enough for an agent to invoke the tool correctly for the common use case.

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 description coverage is 100%, so all seven parameters are already documented with types, constraints, and descriptions. The tool description does not add parameter-level meaning beyond restating the address focus, so the baseline of 3 is appropriate.

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 names a specific verb ('Get'), a clear resource ('list of normal (external) transactions'), and the scope ('for an address'). The parenthetical '(external)' usefully distinguishes this from internal-transaction tools, so the agent immediately knows what kind of data to expect.

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 description gives clear context that this tool returns external transactions only, which implicitly excludes internal transactions and points toward the sibling get_internal_transactions. It does not explicitly name an alternative or state when-not-to-use, but the external/internal distinction is enough to guide selection in most cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already convey read-only, idempotent, non-destructive behavior, so the description need not repeat them. It adds the useful detail that the tool detects failed or erroring contract executions, but does not explain output semantics, error cases, or chainid defaulting. This is adequate but not deeply transparent.

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?

A single front-loaded sentence with a useful parenthetical; no filler or repetition of the schema. It earns its place.

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?

The tool is simple, params are fully documented, and annotations cover side-effect safety, but there is no output schema or stated return format. A caller can invoke it, but less clear what exact status values/results to expect and how they differ from receipt-based status tools.

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 description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already documents for txhash and chainid.

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 operation ('Get the contract execution status') and the resource (transaction), and adds the useful detail that it detects failed/erroring executions. It is understandable on its own, though it does not explicitly distinguish it from the closely named sibling get_transaction_receipt_status.

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?

No guidance is given about when to use this tool instead of alternatives such as get_transaction_receipt_status, get_transaction_receipt, or get_transaction_by_hash. The description implies a status check but does not state exclusions or preference conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.