Loading ToolBench
MCP stdio bridge that lets Claude Desktop / OpenClaw / other MCP hosts make x402 payments on HPP — autoTopup from a Safe via AllowanceModule, signs EIP-3009 with a delegate EOA.
Strong foundation with 15 well-defined tools covering discovery, payment, and wallet management. All tools have descriptions (avg 180 chars, within 10-1024 baseline) and explicit JSON schemas with typed parameters. Naming follows verb_noun convention (hpp_discover, seller_verify, wallet_balance). Key strengths: clear parameter descriptions, enum constraints on type/scheme fields, actionable error guidance in descriptions. Gaps: output schemas not documented in source; seller_receipt lacks visible input schema; some tools (pay_a2a_agent, x402_http_call) have minimal descriptions; no explicit idempotency or retry guidance; file reference syntax (@file:/path) documented but not validated in visible code.
Call a service found via hpp_discover. Pass its `resourceId` and a `body` (the service's input args — check hpp_describe first if unsure). Payment (USDC.e) is handled automatically with your wallet, subject to the daily spend cap — you do not sign anything. HTTP, MCP and A2A typed services are all invoked directly; the price advertised by discovery is enforced as a ceiling.
Describe one service found via hpp_discover: its input arguments (JSON Schema plus a concrete example body), output example, price, network and endpoint. Read-only — no payment. Call this before hpp_call when you are not certain what the service expects: hpp_call pays first and the seller validates after, so a wrong body costs a real payment.
Discover paid x402 services on the HPP chain from the curated discovery directory. Returns services with their resourceId, name, description, price (USDC.e atomic units), network, type and trust signals (how many times the service has actually been paid). Pass `query` for a semantic search (e.g. 'image generation'), or omit it to browse. Results are limited to the network this wallet can pay on unless you pass `network` explicitly (use "all" to see every network). Then call hpp_describe({ resourceId }) to learn the input arguments, and hpp_call({ resourceId, body }) to run it.
Pay an external A2A (Agent-to-Agent) agent. Handles x402 payment signing and settlement for agent-to-agent interactions.
seller_receipt, pay_a2a_agent, x402_http_call lack visible input schemas and detailed descriptions in source. seller_receipt has only a name and risk label; pay_a2a_agent and x402_http_call have minimal descriptions (<50 chars).
Output schemas not documented in source code. Tools return structured data (e.g., hpp_discover returns resourceId, name, price, network, trust signals) but no explicit schema definitions visible. LLMs cannot plan downstream calls without knowing return field names and types.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Build an x402 PaymentRequirements object for a resource you sell. Returns the requirements to advertise in a 402 (see seller_generate_402). Scheme defaults to 'exact'; use 'upto' or 'batch-settlement' with scheme-specific fields in `extra`.
Decode a buyer's base64 X-PAYMENT / Payment-Signature header locally (no facilitator call) to inspect the payload and extract the payer address. Supports exact / upto / batch-settlement.
Build the HTTP 402 Payment Required response body from one or more PaymentRequirements (from seller_create_requirements). Return this when a request arrives with no payment header.
Bind the settled transaction to the delivered result. Creates a receipt linking the on-chain settlement to the service output.
Settle a verified payment on-chain AFTER the work succeeded (serve-then-settle). Pass the same X-PAYMENT header + PaymentRequirements. Returns { success, transaction }.
Verify a buyer's payment against the facilitator BEFORE doing the work. Pass the X-PAYMENT header + the PaymentRequirements you advertised. Returns { isValid, payer, invalidReason }.
Return this agent's own wallet address (to receive/fund USDC.e) and its network. Use when the user asks 'what's my address' or where to send funds.
Show the wallet's current USDC.e balance — what it can spend right now. In Safe mode this is the delegate's immediately-spendable balance (the Safe tops up more on demand).
Show the wallet's spend limits (per-call + per-day in atomic USDC.e units) and how much has been spent today. Empty limits = uncapped.
Set the wallet's spend guard: a per-call cap and/or a per-day cap in atomic USDC.e units (e.g. '10000' = 0.01 USDC.e). These bind across ALL payment tools and are enforced locally before signing (complements the Safe's on-chain cap). Omit a field to leave it unchanged.
Call an x402-protected HTTP endpoint. Auth headers + spend limits come from local policy; payment is signed with the bridge's delegate wallet.
No explicit error handling guidance in tool definitions. Descriptions mention 'wrong body costs real payment' (hpp_call) but lack structured error classification (retryable vs user-fixable vs fatal) or recovery paths. Agents cannot determine next steps on failure.
File reference syntax (@file:/absolute/path) documented in hpp_call description but no validation or error handling visible. If agent passes invalid path or non-existent file, error message unclear. Should document expected behavior and error cases.
No idempotency or retry guidance. Payment tools (hpp_call, seller_settle, pay_a2a_agent) are write operations that agents may retry on ambiguous failures. Lack of idempotency guarantees risks duplicate charges. Should document idempotent behavior or provide deduplication keys.