Loading ToolBench
MCP server that lets an AI agent sweep its own wallet to exactly zero on 25+ EVM chains, with no gas left stranded.
The ZeroDust MCP server demonstrates solid tool definitions with clear, domain-specific descriptions and structured schemas. All 6 tools have meaningful descriptions (90-300 chars, well within the 10-1024 baseline). Tool names follow verb_noun convention consistently (get_*, list_*, submit_*). However, there are notable gaps: (1) The eip7702Authorization parameter in zerodust_submit_sweep lacks a detailed type schema, it is declared as 'object' with minimal description, forcing LLMs to guess its structure. (2) callData parameter similarly lacks type constraints. (3) Parameter descriptions could be more prescriptive about formats and dependencies (e.g., quoteId expiration, signature format expectations). (4) No explicit error handling guidance is visible in the tool definitions, LLMs have no recovery hints if a quote expires or a signature validation fails. (5) Output schemas are not documented in the definitions provided, so LLMs cannot anticipate response shapes for planning. (6) The submission tool (zerodust_submit_sweep) is the only WRITE operation and carries high risk, no dry-run, confirmation, or idempotency hints are documented. Tools are well-composed (single responsibility) and naming is clear and action-oriented. Parameter constraints (regex for addresses, UUID format for sweepId, min/max for limit) are present but under-documented in descriptions.
Find leftover native gas token (ETH, BNB, POL, ...) stranded across every supported EVM chain for one address, and report which of it can be recovered. Normally these balances are unrecoverable: you cannot transfer 100% of a gas token, because paying for the transfer consumes the thing you are transferring, so a remainder is always left behind. This reports what is stuck and what could be moved out. Useful 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.
List the EVM chains a native gas balance can be emptied to exactly zero on. Returns chain IDs, names, and native tokens. Call this to check whether a specific chain is supported before quoting or sweeping.
Price out emptying a chain's native gas balance to exactly zero: how much actually arrives, the full fee breakdown, and whether the balance is even large enough to be worth recovering. Call this before sweeping so the user sees the numbers first. Returns a quote ID; quotes expire after about 60 seconds.
Check how a previously submitted sweep is progressing. Returns the current status (pending, simulating, executing, bridging, completed, failed), the transaction hash once there is one, and the error message if it failed.
zerodust_submit_sweep's eip7702Authorization parameter is typed as 'object' with only a brief description ('EIP-7702 authorization object'). LLMs cannot infer the required nested structure (fields, types, constraints). This forces trial-and-error invocations.
callData parameter in zerodust_submit_sweep lacks schema detail. It is a string but the description does not specify encoding (hex? base64?), length limits, or format constraints. LLMs will guess.
No output schemas documented for any tool. Tool definitions do not specify what fields responses contain (e.g., what does zerodust_get_chains return? Field names, types, examples?). LLMs cannot plan downstream operations or extract needed data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
List past sweeps for a wallet address. Shows sweep history with status and amounts.
Submit a signed sweep request to execute a native gas token sweep. Requires the user to have signed the EIP-712 typed data and EIP-7702 authorization first. Returns a sweep ID to track status.
zerodust_submit_sweep is a destructive write operation with no documented error handling, recovery guidance, or confirmation workflow. LLMs have no guidance on what to do if signature validation fails, quote expires, or the blockchain transaction reverts. No idempotency hints.
Parameter descriptions lack prescriptive format details. Examples: 'signature' should specify 'EIP-712 signature (0x-prefixed hex string, 130-132 characters)'; 'quoteId' should warn 'Expires ~60 seconds after creation'; 'userAddress' and 'destination' could clarify if contract addresses are accepted.
zerodust_get_quote and zerodust_submit_sweep have implicit dependencies (quote must be obtained before submit, and quote expires ~60s) but these are not documented as parameter relationships or recovery hints.
zerodust_list_sweeps accepts 'limit' parameter with min 1, max 100, but no guidance on pagination strategy. What happens if there are >100 sweeps? Is there a cursor/offset mechanism? LLMs cannot iterate safely.