Loading ToolBench
Zero-dependency HTTP 402 fetch replacement for autonomous agents and edge/local runtimes with native EIP-3009 gasless transfers. Lets an AI agent buy things by handling x402 payment protocol.
Three well-named tools with clear, detailed descriptions (194 - 250 chars each). Input schemas present with proper types and descriptions. check_price and pay_and_fetch have excellent descriptions explaining WHEN to use each and the financial implications. wallet_status is minimal but appropriate for a read-only status query. All parameters are typed and described. Output schemas are not explicitly documented in the source, which is the primary gap. Error handling is mentioned in descriptions but not formalized in the schema. Tool composition is sound, each has one responsibility, and the naming verb_noun pattern is consistent.
Look at what a paid resource costs WITHOUT paying for it. Fetches the URL, and if it answers 402 Payment Required, reports the price, recipient, chain and whether it falls within the configured spending limits. Use this before pay_and_fetch when the cost matters, or to check whether a URL is paywalled at all.
Fetch a resource, paying automatically if it answers 402 Payment Required. THIS SPENDS REAL MONEY from the configured wallet. The payment is refused unless it is within the per-request cap, the remaining lifetime budget, the allowed hosts and the allowed chains - those limits are set by the operator and cannot be raised from here. If a resource is not paywalled it is simply fetched, costing nothing.
Report the paying wallet: its address, its on-chain USDC balance, how much has been spent so far and how much of the budget remains. Reads only - never moves money and never reveals the private key.
Output schemas not documented. LLMs cannot plan downstream operations or extract fields without knowing what check_price, pay_and_fetch, and wallet_status return.
Error handling is described in tool descriptions but not formalized as structured error responses. LLMs need explicit error categories (retryable, user-fixable, fatal) and recovery guidance.
pay_and_fetch description mentions 'per-request cap' and 'remaining lifetime budget' but these are not exposed as tool parameters or return values. LLMs cannot reason about budget constraints without visibility.
wallet_status has empty required array in schema but no description of what fields it returns (address, balance, spent, remaining). Output structure is opaque to LLMs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
pay_and_fetch accepts max_response_chars but does not document what happens if response is truncated (is it an error, a warning, or silent truncation?). Ambiguous behavior invites misuse.