verify_agent

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds rich behavioral context: how trades are fetched and matched, that prices derive from swaps (no oracle), that results are deflated, and that it returns a signed receipt digest and ERC-8004 shape. It also discloses the dependency on an Etherscan key and the error behavior without one.

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, dense run-on sentence. While it packs valuable information, the 'THE WIRED PATH:' prefix and the stream-of-consciousness structure make it less concise and harder to parse than necessary. It could be broken into clearer, shorter sentences without loss of content.

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's complexity and lack of an output schema, the description adequately covers inputs, process, outputs (verdict, receipt digest, ERC-8004 shape), prerequisites (Etherscan key), and error behavior. It is complete enough for an agent to invoke the tool correctly without additional 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 schema already provides 100% coverage with detailed parameter descriptions. The tool description goes further by explaining the algorithm (FIFO matching, deflation for arena size), which clarifies how parameters like arena_size and address are used semantically. This adds value beyond the schema, though it does not map each parameter individually.

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 specific verb and resource: it fetches an on-chain agent's public trades, pairs them into swaps, applies FIFO matching to compute round-trip returns, re-derives Sharpe, deflates for arena field, and returns a verdict plus receipt digest and ERC-8004 shape. This distinguishes it from sibling verification tools by emphasizing a one-call, operator-independent fetch-and-compute pipeline.

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 gives clear usage context: it's a one-call verification leveraging public data, and it explicitly notes the prerequisite of a free Etherscan key. It does not explicitly name alternative tools for exclusion, but the context implies it is the integrated on-chain verification path.

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