Loading ToolBench
Agent402 is an Agentic Finance platform providing 500+ pay-per-call web tools (400+ tools via x402/MPP + 70+ skill packs for browser, web search, OCR, PDFs, finance, memory) accessible through multiple adapter frameworks (AI SDK, LangChain, Anthropic, OpenAI, Coinbase AgentKit, elizaOS, Google ADK, LlamaIndex, Strands, etc.). Tools are callable free via proof-of-work or paid in USDC on Base + 11 other chains, or USDG on Robinhood Chain.
Agent402 presents 4 tools with minimal documentation and incomplete schemas. All tools have descriptions but they are terse and lack actionable guidance for LLM selection. Input schemas are present but severely underdeveloped: most parameters lack type definitions beyond basic strings and objects, with no enum constraints, format specifications, or validation rules. Output schemas are completely undocumented. The tools appear to be wrappers around a pay-per-call marketplace API, but the schemas do not expose the underlying marketplace structure or payment mechanics clearly enough for autonomous agent reasoning. The 'call' tool accepts an open-ended object parameter ('input') with no schema constraints, inviting misuse. No error handling documentation, no security scoping, and no composition guidance.
Get detailed information about a specific tool including pricing, input/output schemas, and availability
Execute a tool call with automatic payment handling (free via proof-of-work or over x402/MPP)
Find and discover tools from the Agent402 catalog across 500+ pay-per-call endpoints
Route a task to the optimal tool using the cross-seller x402 + MPP Smart Order Router for payment optimization
All tools lack documented output schemas. No agent can predict return types or chain tools without knowing what fields to extract. The 'about' tool claims to return pricing/schemas/availability but provides no schema. The 'find' tool returns results but type is unknown. The 'call' tool returns something but structure is opaque.
'call' tool accepts an open-ended 'input' parameter typed as object with no constraints. LLMs cannot construct valid inputs without knowing the schema of each tool in the catalog. This violates the constrained-input pattern and invites hallucinated parameters.
No error recovery guidance. All tools marked READ_ONLY or WRITE but no recovery patterns documented. If 'find' returns no results, what should the agent do? If 'call' fails with 'proof-of-work timeout', how does the agent retry? If 'route' selects a tool that fails, can the agent backtrack? No guidance forces agents to guess.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
Descriptions are generic and under-specify use cases. 'find' and 'about' both appear to discover tools, the distinction is unclear. 'route' references internal payment/routing logic ('x402 + MPP Smart Order Router') that means nothing to an agent without domain knowledge. Descriptions should prioritize LLM intent inference, not internal architecture.
Payment mechanics are opaque. The 'call' tool mentions 'free via proof-of-work or over x402/MPP' but does not explain: what is proof-of-work, how long does it take, when is it applied, what is x402, what is MPP, can the agent choose, or is it automatic? The 'route' tool claims 'payment optimization' but does not document what it optimizes for. No security scoping (e.g. 'requires payment:x402 scope').
No parameter constraints. 'query' in find, 'task' in route, and 'toolId' in about/call are all untyped or minimally typed strings with no regex patterns, length limits, or enum values. Baseline from production tools: 100% of A+ tools constrain at least 50% of parameters. This server constrains zero.
Tool composition and chaining is undocumented. Is the typical flow find → route → call? Or find → about → call? Or find → route → about → call? Do toolIds from find match toolIds in call? Do toolIds from route match toolIds in about? No guidance forces agents to guess or hallucinate workflow.
Naming inconsistency: 'find' vs 'search' vs 'about' vs 'route' do not follow a consistent verb_noun pattern. 'find' is ambiguous (find what?). 'route' is not a verb (route implies a noun like 'route a task', but the parameter is 'task', not 'request'). 'about' is informal. Consistent naming would be search_tools, get_tool_info, route_task, call_tool.