get_gas_history

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose and 'recent blocks' scope but does not mention that this is a read-only operation, what the return format is, how the network parameter behaves, or any implications of the blocks parameter. This is insufficient for a tool with no output schema and no safety hints.

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 a single, clear, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and scope. There is no clutter or redundant information, making it concise and well-structured for its simplicity.

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 absence of an output schema and annotations, the description must explain the tool's behavior and return values, but it does not. It fails to mention that the tool defaults to BSC mainnet, supports multiple networks, or what the output looks like (e.g., a list of gas prices per block). The description is too sparse to fully prepare an agent to use this tool correctly, especially with no other context.

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 input schema provides 100% coverage with thorough descriptions for both parameters (blocks and network), including defaults and examples. The description adds little beyond the schema, merely reinforcing the 'recent blocks' concept, which already aligns with the blocks parameter. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

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 function: 'Get historical gas prices from recent blocks.' It uses a specific verb ('get'), identifies the resource ('gas prices'), and scopes the operation ('from recent blocks'). This distinguishes it from related siblings like get_gas_price (current price) and get_gas_prices_all_chains (all chains not historical).

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 provides no usage guidance, such as when to use this tool versus get_gas_price or get_gas_prices_all_chains. It does not mention that the network defaults to BSC or that blocks is an optional parameter. There is no explicit when-to-use or when-not-to-use guidance, making it difficult for an agent to select this tool appropriately in context.

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