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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering state safety. The description adds the critical cost behavior (paid $0.01 USDC on Base or Solana) and specifies the two outputs (exact 4-byte selector and full keccak256 hash), both of which go beyond the annotations. However, it does not mention failure modes, return format, or payment mechanics.

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 short sentence, so it is concise in length, but it is poorly structured: it front-loads payment details ('Paid $0.01 USDC on Base or Solana') before stating the core purpose. It is also a grammatical fragment without a main verb, which hurts readability and clarity.

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?

This is a paid tool with no output schema and an underspecified input. The description fails to explain how the signature should be formatted (essential for a Solidity selector), what the output looks like (e.g., hex string, single value vs. combined object), and how the payment works (does the caller need USDC, will it fail without, are there hidden costs?). An agent cannot confidently invoke this tool correctly from the description alone.

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% for the single 'signature' parameter. The description only references 'signature hash' as an output, never explicitly stating that the input should be a Solidity function signature string or its required canonical format. The agent must infer from the tool name and output description what to pass, which is insufficient compensation for the schema gap.

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 is a verbless noun phrase: 'Paid $0.01 USDC on Base or Solana exact 4-byte Solidity selector and full keccak256 signature hash.' It names the resource (Solidity selector, keccak hash) and implies the output, but lacks an explicit verb like 'computes' or 'returns', leaving the action ambiguous. It does distinguish from sibling keccak256 by mentioning the 4-byte selector, but the fragment is still vague about whether it computes, verifies, or retrieves.

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?

There is no guidance on when to use this tool versus alternatives like keccak256, hash_encode, or others in the sibling list. The description does not state use cases, prerequisites (e.g., canonical Solidity signature format), or conditions under which a different tool should be chosen instead.

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