backend

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context beyond these by specifying that it performs a 'honeypot / contract safety check', which is behavioral information not captured in the annotations. It adds value without contradicting any annotations, and the safety profile is already disclosed by annotations.

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 sentence that front-loads the core purpose. It is concise with no filler or unnecessary details, efficiently communicating the tool's role.

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?

The tool is simple (one parameter) and has both an output schema and annotations that cover safety traits. The description, while brief, is sufficient for an agent to understand the tool's basic function. It could mention expected output format, but that is already covered by the output schema, so the description is reasonably complete for this 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?

Schema description coverage is 100% and the parameter is well-described in the schema ('Token contract address (0x...).'). The description does not add any additional semantics or details about the parameter beyond what the schema already provides, so baseline 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 uses a specific verb ('check') and clearly identifies the resource ('contract safety for any ERC-20 token'). It also mentions 'honeypot' which is a specific type of check, effectively distinguishing it from sibling tools like evaluate_trade or simulate_balance, which have different purposes.

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 usage when a token safety check is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. There is no reference to sibling tools or guidance on when not to use it, leaving the agent to infer from purpose alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the fixed Tier 1 ceiling and the hard-stop semantics, which are not in annotations. It doesn't contradict annotations and provides extra behavioral context without over-explaining.

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 two short paragraphs with no filler. The critical instruction to call before executing and the hard-stop treatment are front-loaded. The tier ceiling and alternative are concisely stated in the second paragraph. 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 the output schema exists and annotations cover safety, the description is complete. It covers when to call, the decision semantics, the tier limitation, and the alternative for higher tiers. Nothing essential for correct invocation is missing.

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 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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 states a specific verb and resource: 'Pre-trade risk check for a proposed trade.' It clearly differentiates from siblings like check_token_safety and simulate_balance by focusing on evaluating a trade's risk before execution. The 'deny' decision as a hard stop adds specificity.

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?

Explicitly instructs to call this BEFORE executing any trade and to treat a 'deny' decision as a hard stop. It also provides an exclusion: for higher tiers, use the REST API with wallet-signature authentication. This leaves no ambiguity about when and when not to use the tool.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds useful context about the official registry and canonical addresses, but it does not go further into behavior such as ordering, pagination, or any response characteristics beyond what the output schema likely provides.

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?

A single, front-loaded sentence with no filler. It immediately states the action and the object, and every phrase adds value. This is an example of appropriately concise description.

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 parameterless listing tool with rich annotations and an output schema, the description fully covers what the agent needs to invoke it correctly. It states what is returned (assets and their canonical addresses) and the source scope (official Robinhood Chain registry). No additional caveats or details are necessary given the low complexity.

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 tool has zero parameters and schema description coverage is 100%, so there is nothing the description must compensate for. The description focuses on output content instead, which is appropriate for a parameterless operation. Baseline 4 is suitable given that no parameters exist.

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 uses a specific verb ('List') and a clear resource ('every asset in the guardrail's official Robinhood Chain registry'), and even specifies the included field ('canonical contract address'). It is easily distinguished from sibling tools like check_token_safety or evaluate_trade, which clearly do different things.

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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or conditions, leaving the agent to infer that this is simply the go-to listing tool. There is no explicit 'use when' or 'use instead' statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds 'Read-only: no transaction is ever sent,' which reinforces but doesn't meaningfully extend the annotations. It also mentions the technical method (eth_call state override), but this is more about implementation than behavior. No contradiction with annotations.

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?

Two sentences with no filler. The primary purpose and the key safety fact (read-only) are front-loaded. Every word earns its place, and the structure is immediately scannable.

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?

The tool is simple, has an output schema, and all parameters are documented. The description conveys the intended use, the method, and the non-destructive nature. Nothing critical for an agent to invoke it correctly is missing. It could mention edge cases (e.g., token decimals), but the schema already handles that.

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 100%, so every parameter already has a description. The tool description adds no additional parameter-specific meaning; it only frames the overall purpose. Per the rubric, when schema coverage is high, a score of 3 is appropriate without further elaboration.

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 a specific verb ('simulate') and resource ('a wallet's ERC-20 balance') with the context of a hypothetical trade and the method (eth_call state override). It is unambiguous and not a tautology, but it does not explicitly distinguish itself from sibling tools like evaluate_trade, so it loses the top point.

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 the use case: simulating a balance after a hypothetical trade. It provides context but gives no explicit guidance on when to use this tool over alternatives or when not to use it. No alternatives are mentioned, so the agent must infer the appropriate context from the wording alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, carrying the safety profile. The description adds useful context by characterizing the trail as tamper-evident and scoping it to past guardrail decisions, which hints at what verification entails. No contradiction with annotations, but little added beyond the annotations' coverage.

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?

A single sentence with zero filler. The verb and core object are front-loaded, and every word earns its place by clarifying the scope (wallet's past guardrail decisions).

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 read-only verification tool with a full output schema, the definition is nearly complete: annotations cover the safety profile, the schema documents the parameters, and the description conveys the tool's purpose and scope. A minor gap is the absence of any guidance on what a failed verification implies, but nothing essential to invoking the tool is missing.

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 100%, so the schema fully documents both parameters (wallet format and limit with its 1-1000 range and default). The description adds no parameter-level meaning beyond the schema, matching the baseline of 3.

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?

States a specific verb (Verify), a specific resource (tamper-evident audit trail), and a precise scope (a wallet's past guardrail decisions). The purpose is unambiguous and easily distinguishable from siblings like check_token_safety and evaluate_trade, which operate on different data entirely.

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 no explicit when-to-use or when-not-to-use guidance and names no alternatives. However, usage is reasonably implied by the domain — an agent needing to confirm the integrity of a wallet's guardrail history can infer this is the right tool, and none of the four siblings overlap with audit verification.

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