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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does an excellent job: it reveals the operation is non-mutating ('Never sends — simulation only'), explains the underlying mechanics (eth_call + eth_estimateGas), mentions the cost ($0.01 per call), and describes revert reason decoding. This goes far beyond a minimal description and fully informs the agent about side effects and behavior.

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 well organized. The first line front-loads the core purpose and safety guarantee, followed by cost, then mechanics, and then a clear parameter list. Every sentence contributes useful information; there is no fluff or redundancy. The structure makes it easy for an agent to quickly parse the essential facts.

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?

Given the tool has no output schema, the description does not explicitly state the exact shape or fields of the return value, which is a minor gap. However, it does convey that the tool returns simulation outcomes and decoded revert reasons, which is the key information an agent needs to interpret results. The parameter documentation and behavioral notes are complete, so overall it is nearly comprehensive.

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 0%, so the description must compensate, and it does. Each parameter is individually documented with data format expectations ('hex string starting with 0x', 'default empty call', 'ETH to send along, hex wei string', 'address to simulate as sender') and mentions defaults. This adds significant meaning beyond the bare schema property names and titles.

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 tool's purpose: 'Preview a Base call before sending' with a strong disclaimer 'Never sends — simulation only.' It specifies the mechanism ('Runs eth_call + eth_estimateGas') and differentiates itself from any sending or read-only sibling by emphasizing simulation-only behavior. There is no ambiguity about what the tool does or where it fits among the 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 clearly establishes when to use it: before sending a transaction, to preview the result. It also explicitly states what it does not do ('Never sends'), which serves as a strong exclusion. While it does not explicitly name alternative sibling tools, none of the listed siblings perform simulation or anything similar, so the usage context is sufficiently clear without naming alternatives.

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