Loading ToolBench
curl for x402 and MPP paid APIs with MCP proxy support. Auto-pays HTTP 402 on Base, Monad, Solana, and Tempo.
The x402-proxy server exposes 2 tools with basic descriptions and schemas, but falls short of production-grade quality. Both tools have non-empty descriptions (66-122 chars, within the 10-1024 range), but lack depth and LLM-optimization. The x_wallet tool has an empty input schema (Type.Object({})), which is a critical issue. The x_request tool has a populated schema with 5 parameters (url, method, params, headers, protocol), but parameter descriptions are minimal (11-65 chars) and lack actionable constraints. Neither tool documents output schemas, error handling, or recovery guidance. The naming follows verb_noun convention (acceptable but generic: 'x_wallet', 'x_request'), but the descriptions are too brief to guide LLM selection, they do not explain WHEN to use each tool, what data they return, or dependencies. Parameter 'protocol' on x_request uses an enum (good), but lacks guidance on the 'auto' behavior. Overall, the definitions are skeletal, suitable for internal CLI use, not for agentic reasoning.
Call a paid HTTP endpoint with automatic x402 or MPP settlement. Defaults to the plugin protocol and supports explicit protocol override.
Check wallet readiness, balances, and spend history for x402 and MPP payments before making paid requests.
x_wallet tool has no input parameters but also provides no output schema documentation. Callers cannot infer what data is returned, making it difficult for LLMs to extract results for downstream reasoning.
Parameter descriptions are too terse and lack actionable constraints. E.g., 'params' is described as 'For GET: query params as JSON object. For POST/PUT/PATCH: JSON request body.', but does not specify: required format, field naming conventions, character limits, example structure, or what happens if malformed JSON is passed.
No output schema documented for x_request. LLMs cannot determine what fields the HTTP response contains, how to extract status codes, headers, or body content, or how to pass results to chained tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Error handling is implicit. The code does not show structured error responses, recovery guidance, or categorization (retryable vs. fatal). LLMs receive raw API failures with no hint of what to do next.
Tool descriptions lack WHEN-to-use guidance. 'Check wallet readiness...' and 'Call a paid HTTP endpoint...' are functional but do not explain: prerequisites, LLM decision criteria, or when one tool is preferred over another.
x_request 'protocol' parameter has an enum (good), but 'auto' behavior is undocumented. LLMs cannot predict how protocol selection works and may make wrong assumptions.