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

Annotations already establish read-only, non-destructive behavior, but the description adds meaningful operational context: it lists receipt fields, says pending or unknown hashes return 404 and are uncharged, explains pricing and payment methods, and notes that repeated calls are charged. That is substantial 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 front-loaded with purpose, return fields, and the sibling distinction, then follows with usage, input format, example, and pricing. It is longer than typical but most sentences carry useful information; the pricing and payment details are relevant but make it somewhat dense.

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 single-parameter read-only tool with complete schema coverage and no output schema, the description supplies the missing context: what receipt fields are returned, what happens on pending or unknown hashes, pricing behavior, and the alternative tool for transaction details. It is complete enough for an agent to call it correctly and interpret common edge cases.

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 baseline is 3, but the description adds value by restating the required input format, supplying a concrete example hash, and explaining the 404 behavior when the hash is pending or unknown. The schema already carries the core parameter description, so this is an enhancement rather than the sole source of semantics.

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: fetches a Polygon PoS transaction receipt via eth_getTransactionReceipt. It enumerates the returned facts and explicitly distinguishes itself from polygon_tx for sender, value, and calldata, so an agent can choose between the two siblings immediately.

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 a concrete use case—confirming whether a payment or call went through—and names the alternative tool plus the exact condition that selects it: use polygon_tx for sender, value, and calldata. This is explicit when-to-use and when-to-use-another guidance.

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