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

Beyond the readOnly/openWorld/non-idempotent annotations, the description adds important operational context: pending hashes return 404 uncharged, failed calls are free, pricing is $0.01/call via x402 or card key, and repeats are charged again. These are material behavioral and billing details an agent should know before calling.

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 purpose and return content are front-loaded, and the description is dense but readable. Some clauses repeat annotation-level facts, such as read-only behavior and non-free repeats, but the extra pricing and error details generally earn their 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 one-parameter tool with no output schema, the description supplies enough detail: it enumerates the receipt fields, explains the 404 case, and discloses billing behavior. An agent has what it needs to call and interpret 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?

Schema coverage is 100%, so the single hash parameter is already well documented. The description still adds a concrete example and clarifies that a pending or unknown hash produces a 404 rather than a normal receipt, which is useful handling semantics 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 resource and chain (transaction receipt on Arbitrum One / eth_getTransactionReceipt) and enumerates the returned fields: status, gas used, effective gas price, fee, logs, and contract creation. It explicitly distinguishes itself from arb_tx by saying sender, value, and calldata belong there.

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?

It gives an explicit use case — confirming that a payment or call went through — and names arb_tx as the alternative for sender/value/calldata. It also explains the pending/unknown-hash case as a 404 response.

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