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

Beyond the annotations, the description discloses pagination size (50 per page), ordering (newest first), the cursor linkage from next_cursor, and the important caveat that a limit-cut page has no next_cursor. It also lists returned fields (type, from, to, value, success, error), so the agent understands the operation and its output shape without an output 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?

The description is dense but front-loaded: purpose and scope come first, then the RPC/trace rationale, then pagination guidance. Every sentence contributes operational information, with no repetition of the tool name or title.

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 parameterized read-only explorer endpoint with no output schema, the definition is complete: it covers scope selection, alternatives, pagination, the no-trace node constraint, and the shape of returned records. An agent has enough to call this correctly without further documentation.

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 already 100%, but the description adds meaningful semantics beyond the schema: transaction and address are presented as alternatives for selecting scope, and cursor/limit are explained in terms of real paging behavior. This is exactly the additional meaning the schema alone does not provide.

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: value transfers and calls made by contracts during transactions (internal transactions), scoped to one transaction or address. It also distinguishes this from normal transaction listings and from trace_transaction, giving an agent enough to identify the tool without opening 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?

It explains when to use this tool: when the public RPC cannot trace and the agent needs internal LAX movements without a debug-enabled node. It also names trace_transaction as the alternative and gives explicit paging behavior for cursor vs limit, so the agent knows how to invoke it correctly across pages.

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