estimate_hook_fee

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

No annotations exist, so description carries full burden. It discloses that results are estimates (not exact on-ledger fees), that the static instruction count is an upper-bound proxy, and that the tool operates offline. It does not mention destructive effects (none assumed) or auth requirements, but overall is transparent about its behavioral limitations.

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?

Extremely concise: two sentences covering purpose, what it outputs, and a key caveat. No wasted words, front-loaded with the verb 'Estimate'. Every sentence earns its place.

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 no output schema, the description adequately describes output (byte size and static instruction count) and notes it is an estimate and offline. It covers the main purpose and limitations. Could be improved by mentioning that it returns numeric values or typical error cases, but overall is complete for a simple estimation tool.

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 description must compensate. It mentions 'from its WASM' but does not explain the two parameters (wasmHex, wasmBase64) beyond their names. It fails to clarify that only one should be provided, or describe acceptable formats/constraints. Adds minimal value over parameter names.

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?

Clearly states it estimates cost signals (byte size and static instruction count) from a Hook's WASM. It distinguishes itself as an ESTIMATE and offline, differentiating from on-ledger fee tools. However, it does not explicitly name sibling tools like 'estimate_hook_state_cost' or 'simulate_hook_trigger' as alternatives, which would strengthen clarity.

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?

Provides clear context: it is an estimate and offline, and notes that the on-ledger execution fee depends on the actual executed path. This implies it should not be used for exact fees. However, it does not explicitly list when to use this tool versus specific sibling tools or state when-not-to-use scenarios.

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