zerodust

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

Annotations already declare readOnlyHint=true (non-destructive) and openWorldHint=true (external state dependent). The description adds behavioral context beyond annotations by explaining the inherent limitation of gas token transfers (consuming the token to transfer it) and clarifying that it reports both what is stuck and what could be moved out. No contradictions.

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 concise yet informative: first sentence states the main purpose, then explains the problem, then states what the tool reports, and finally provides use cases. Every sentence adds value with no redundancy or fluff.

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 has one parameter and no output schema, but the description conceptually explains the output (reports what is stuck and what could be moved). For a tool of this complexity (scanning many chains for stranded gas), the description provides sufficient context for an agent to understand its function and expected results. A small deduction for not explicitly mentioning the output format (e.g., list of chains with balances).

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 has one parameter 'address' with a description 'Ethereum address (0x...)', and schema coverage is 100%. The description does not add parameter-specific details beyond the schema, but it does contextualize the parameter within the tool's overall purpose. Baseline 3 is appropriate as the description adds no extra semantics for the parameter itself.

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 it finds leftover native gas tokens stranded across EVM chains and reports recoverable amounts. It uses a specific verb ('find') and resource ('stranded gas'), and distinguishes from sibling tools like zerodust_get_chains or zerodust_get_quote by its unique function.

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 explicit use cases: 'when a wallet has small amounts scattered over many chains, when someone cannot send their full balance, or before closing out, winding down or decommissioning a wallet.' It also explains why these balances are normally unrecoverable, giving clear context for when to invoke. However, it does not explicitly list alternatives or when not to use, slightly reducing the score.

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?

Description adds return fields (chain IDs, names, native tokens) beyond annotations. Annotations already indicate readOnlyHint and openWorldHint. No contradictions.

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, front-loaded with purpose. Efficient and no wasted words.

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?

Complete for a parameterless listing tool. Describes what is returned and how to use it. No output schema needed.

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?

No parameters exist, so no need for parameter details. Baseline set to 4 for zero parameters.

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?

Clear verb 'List' and specific resource 'EVM chains a native gas balance can be emptied to exactly zero on'. Differentiates from sibling tools like zerodust_get_balances and zerodust_get_quote.

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 states when to call: 'Call this to check whether a specific chain is supported before quoting.' Provides clear context for use. No explicit when-not, but purpose is clear.

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?

Discloses quote expiration (not in annotations) and that execution requires a signing key. Annotations already indicate readOnlyHint=true and openWorldHint=true; description adds valuable behavioral context without contradiction.

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?

Three sentences with no waste. Front-loaded with the core purpose and immediately useful details (expiration, security). 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?

Covers what the quote provides (arrival amount, fee breakdown, balance check) and expiration. No output schema exists, but description gives sufficient context for agent decision. Could be more explicit about return format.

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 has 100% coverage; description does not add meaning beyond schema. It contextualizes parameters within the overall purpose but doesn't explain format or constraints.

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 purpose: 'Price out emptying a chain's native gas balance to exactly zero,' specifying the action (price out), resource (native gas balance), and outcome (quote ID). It distinguishes from siblings like zerodust_get_balances by focusing on sweep quoting.

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 tells when to use this tool (to get a quote) and when to use something else (the SDK for execution). Also mentions quote expiration (60 seconds) and security constraint (hosted server doesn't hold signing key).

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 mark it as read-only; the description adds context by listing possible statuses (pending, simulating, etc.) and mentioning return fields (tx hash, error), complementing annotations without contradiction.

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 with a list of return values, concise and front-loaded, though it could be more structured with bullet points for readability.

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 simple tool with one parameter and no output schema, the description fully covers what the tool does, what it returns (status, tx hash, error), and is sufficient for correct invocation.

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 coverage is 100% for the single parameter sweepId, which is already well-described in the schema. The description adds no extra semantic detail beyond its purpose.

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 checks sweep status, with a specific verb ('check') and resource ('sweep'), and distinguishes from siblings like list_sweeps by focusing on a single sweep's progression.

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 use after submitting a sweep, but does not explicitly state when to use or not use this tool versus alternatives like list_sweeps, nor does it mention prerequisites.

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, so the agent knows it's safe. The description adds that it explains costs and integration, which is beneficial context beyond the annotation.

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, front-loaded with purpose and usage. Every word earns its place; no redundancy or unnecessary detail.

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 input parameters and no output schema, the description fully covers what the tool does and when to use it. It is complete for an informational 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?

No parameters exist, and schema coverage is 100%. The description does not need to add parameter details, so baseline 4 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 it explains how to empty a native gas balance to zero, including costs and integration. It distinguishes itself from sibling tools that perform specific actions (e.g., get balances, get quotes) by being purely informational.

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 specifies when to call: when asked how ZeroDust works, why a full balance cannot be sent, or what sweeping will cost. Provides clear context for use without ambiguity.

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 indicate readOnlyHint and openWorldHint, so safety and read-only nature are covered. The description adds that it returns status and amounts, and the purpose of confirming emptiness. This provides helpful context beyond the 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 two sentences: first explains what the tool does and returns, second gives a usage scenario. No extraneous words; every sentence adds value.

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 simple list operation with 2 parameters and no output schema, the description is mostly complete. It explains what is returned (status and amounts) and when to use it. Minor omission: default limit behavior (10) could be noted, but not critical.

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?

Both parameters have full descriptions in the schema (100% coverage). The description reiterates the address parameter but adds no new semantic detail beyond what the schema provides. 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 clearly states it lists past sweeps for a wallet address, returning status and amounts. This directly conveys the action and result. It distinguishes from siblings like get_sweep_status (focused on a single sweep) and get_balances by specifying the resource (sweeps) and the filtering scope (by address).

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 a specific use case: confirming a chain was already emptied before trying again. This helps decide when to use the tool. However, it does not explicitly compare with siblings or state when not to use, though the context is clear enough.

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?

The description warns 'The key is returned once and cannot be retrieved later - report it to the operator.', which is a critical behavioral trait not captured by annotations (readOnlyHint=false, destructiveHint=false). This adds significant value beyond 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?

Three sentences: first states purpose, second gives usage context, third warns about key non-retrievability. Extremely efficient with no redundant words.

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 simplicity (3 params, 1 required, no output schema), the description covers purpose, when to use, behavioral warning, and return behavior. It is fully complete for an agent to select and invoke correctly.

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 baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides. The parameters (name, agentId, contactEmail) are adequately described in the schema.

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 'Issue this agent its own ZeroDust API key for higher rate limits, with no human signup step.', which clearly identifies the action (Issue) and resource (API key). It distinguishes itself from sibling tools that use the API without needing a key.

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 says when to use: 'only call this when rate limits are being hit, or when setting up an unattended agent that will run repeatedly.' Also clarifies that other tools work without a key, providing clear when-not-to-use guidance.

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