Loading ToolBench
A non-custodial USDC wallet for AI agents with MCP server support
Stipend has 21 tools with consistent naming (verb_noun pattern: wallet_*, payout_*, config_*, approve_*, affiliate_*, etc.) and descriptions present for all tools. However, critical gaps undermine quality: (1) Input schemas visible but many lack complete type information or constraints (e.g., wallet_create has only boolean params, no validation ranges); (2) Descriptions are functional but brief (avg ~60 chars, below 194-char baseline), lacking WHEN/WHY context for LLM selection; (3) No output schemas documented anywhere, LLMs cannot predict response structure; (4) Error handling absent, no recovery guidance, no categorization of retryable vs fatal errors; (5) Sensitive operations (payout_send, wallet_import) lack dry-run/confirmation patterns despite irreversible consequences. Tool composition is sound (each does one thing), but descriptions need expansion and output contracts must be formalized.
Register for the referral program and get a referral code
Get the referral link to share
Get referral earnings and status
List all active, unused approvals
Create a one-time payment approval for a specific recipient and amount
Find an unused, unexpired approval for an exact payment
Get a specific approval by token if still usable
Cancel one approval or all approvals
No output schemas documented. LLMs cannot predict response structure for any tool. Responses must be formally specified (e.g., wallet_balance returns {usdc: number, eth: number, daily_spent: number, limits: {...}}).
Irreversible operations lack confirmation/dry-run patterns. payout_send has 'confirm' and 'dry_run' params but no guidance on when/how to use them. wallet_import and approve_revoke also modify state without explicit safety gates.
Descriptions too brief and lack WHEN/WHY context. Average ~50 chars vs 194-char baseline. Examples: 'Display current configuration settings' (40 chars) does not explain when to call config_show vs config_set. 'Get the history of all outgoing payments' (45 chars) does not clarify pagination or result limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Add an address to the allowlist of payment destinations
Set a configuration value
Display current configuration settings
Find money that arrived while the wallet was not running
Get the history of all outgoing payments
Send USDC to a recipient address with optional confirmation and dry-run
What is outstanding and whose job each item is
Generate a report of earnings vs costs
Run self-tests to verify wallet and configuration integrity
Get the current wallet address
Get the current USDC and ETH balance, daily spending, and limits
Create a new non-custodial USDC wallet with encrypted private key storage
Import an existing private key into the wallet
Generic tool names reduce clarity. 'report' and 'recover' are vague, do they generate earnings reports, payment reports, or system diagnostics? 'recover' could mean wallet recovery, transaction recovery, or state recovery. Rename to report_earnings, recover_wallet, or recover_transactions.
No error handling guidance. Tools do not document what errors are retryable, user-fixable, or fatal. Example: if payout_send fails due to insufficient balance, the LLM has no guidance to suggest checking wallet_balance first or asking the user to fund the wallet.