Estimate gas

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Estimate gas' signals a read-like call, but the description does not clarify whether this performs a node call, whether it mutates state, whether it requires the transaction to be signed, what happens with missing fields, or whether it needs a funded account. As an RPC estimate it likely does not mutate state, but the description leaves that implicit.

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 short sentence that leads with the verb and the object. It earns its place by stating the core purpose, though it could add a brief note about chainId or the transaction object without becoming verbose.

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 2-parameter tool with a nested transaction object and no output schema, the description is minimal but perhaps adequate for a straightforward RPC endpoint. Missing context: what the return value is (estimated gas amount), whether the transaction needs to be signed, and how this differs from rpc_get_fee_data or rpc_call. The schema clarifies the parameters but the description leaves behavioral and selection context thin.

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 documents chainId clearly and covers many transaction sub-fields, but the description itself just says 'transaction request.' The nested transaction object's semantics are mostly in the schema (field names and patterns), though the description adds little about the relationship between fields (e.g., gasPrice vs maxFeePerGas for legacy vs EIP-1559). With 50% schema coverage, the description partially compensates by naming 'transaction request' but does not explain which fields are required for a valid estimate.

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 says 'Estimate gas for a transaction request' — a specific verb (estimate) applied to a resource (gas for a transaction). It distinguishes itself from read-only RPC tools (rpc_get_block, rpc_get_transaction) and from rpc_get_fee_data (which might naively sound similar), though it does not explicitly name siblings.

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 this is the tool to use when an agent has a transaction request and needs a gas estimate. However, it gives no explicit guidance about when to prefer alternatives like rpc_estimate_gas vs rpc_get_fee_data, or prerequisites such as requiring chainId and a fully-formed transaction object. No exclusions or alternatives are mentioned.

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