Loading ToolBench
x402 auto-payment exposed as MCP Tools for Claude Code, Cursor, OpenClaw and any MCP-compatible AI tool
The Ag402 MCP Client exposes 3 tools for HTTP payment automation. Tool definitions are present with descriptions and input schemas, but several quality gaps reduce the score. Tool names follow action-verb conventions (fetch_with_autopay, wallet_status, transaction_history), which is good. Descriptions are present and detailed, ranging from 145 - 328 chars, above the 10-char minimum. However, parameter schemas lack full type information for some fields, and descriptions contain implementation details that should be hidden. The fetch_with_autopay tool is particularly complex and could benefit from better parameter documentation around budget guards and error recovery. Error handling guidance is sparse, the server does not clearly signal to the LLM how to recover from payment failures or insufficient balance scenarios. Output schemas are not documented, forcing the LLM to guess the structure of responses. Transport is STDIO only, which is a hard cap at 50 for protocol readiness, but definition quality can still reach 62 on its own merits.
Make an HTTP request with automatic x402 payment. When the target API returns HTTP 402 (Payment Required), this tool automatically negotiates and completes payment using USDC, then retries the request with payment proof to get the actual response. The entire payment process is protected by 6-layer budget guards: single transaction limit, per-minute rate limit, daily spending cap, circuit breaker, balance check, and automatic rollback on failure.
View recent payment transaction history. Shows a list of recent transactions including deposits, deductions, and rollbacks, ordered by most recent first.
Check your Ag402 wallet balance and spending summary. Returns the current wallet status including balance, today_spend, total_spend, transaction_count, minute_spend, and minute_transaction_count. Use this to check if you have sufficient funds before making expensive API calls, or to monitor your spending patterns.
No documented output schemas. LLMs cannot predict response structure or plan downstream composition. The fetch_with_autopay tool returns an HTTP response, but fields like status_code, body, headers, payment_proof are not formally declared.
Parameter 'headers' and 'body' are documented as JSON strings, not objects. This forces the LLM to manually serialize JSON, increasing error likelihood. Should accept native objects with JSON Schema type 'object'.
fetch_with_autopay description mentions internal implementation details ('6-layer budget guards', 'single transaction limit', 'circuit breaker', 'automatic rollback') that the LLM does not need to understand. Description should focus on user-level behavior: what happens when 402 is returned, what the LLM should expect.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 60 | - | v1 |
No error guidance. If the wallet is insufficient or payment negotiation fails, the tool error response does not tell the LLM to call wallet_status first or what to do next. Errors should be actionable.
Parameter 'max_amount' is float with default 5. Description says 'Maximum amount (in USD)' but does not specify minimum, maximum bounds, or currency precision rules. Should clarify: 0.01 - 1000 USD, in 0.01 increments.
Parameter 'method' has enum constraint (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) in description, but schema does not formally declare it as an enum type. Schema should use 'enum' JSON Schema keyword.
fetch_with_autopay is a complex operation (HTTP request + payment negotiation + retry) with multiple failure modes (invalid URL, network error, payment failure, insufficient balance). Tool does not document idempotency guarantees or what happens if the LLM retries a failed call.