Loading ToolBench
x402 SDK for AI agent payments - Base & Solana USDC micropayments protocol
This server exposes 11 utility functions as tools, but lacks critical definition quality across the board. Tool names are generic and non-verb-based (e.g., 'x402', 'SolanaVerifier', 'verify' instead of 'verify_solana_payment'). Descriptions exist but are often vague or lack actionable context for LLM selection. Most critically, input schemas are either missing entirely or severely incomplete, parameters lack type definitions, enums, and constraints. No output schemas are documented. Error handling guidance is absent. The server appears to be a library wrapper rather than a production-grade MCP tool suite.
Solana USDC Payment Verifier - Verifies Solana USDC transactions by querying the Solana RPC endpoint and validating token transfers to a recipient address
Build a 402 Payment Required response - Constructs an X402PaymentRequirement object with payment options for the client
Detect network from signature format - Analyzes signature format to determine if it's a Solana or EVM transaction
Convert micro units to USDC amount - Divides micro units by 1,000,000 to get USDC amount
Check if a signature looks like an EVM transaction - Validates signature format against EVM's hex encoding rules
Check if a signature looks like a Solana transaction - Validates signature format against Solana's base58 encoding rules
Parse Payment-Signature header - Extracts and decodes payment signature from HTTP header, handling both base64 encoded JSON and raw signature formats
Tool names lack action verbs and are ambiguous. 'x402' is a protocol name, not a verb. 'SolanaVerifier' is a class name. 'verify' is too generic, verify what? Rename to 'verify_solana_transaction', 'verify_evm_transaction', 'check_solana_signature_format', etc.
Input schemas are incomplete or missing type definitions. Parameters like 'outputSchema' and 'verifyPayment' in x402 lack type constraints. No enums for 'network' parameter (should be enum: ['base', 'solana']). Parameters lack minLength, maxLength, pattern constraints.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. E.g., 'verify' returns payment details but structure is undocumented. 'buildPaymentRequirement' returns X402PaymentRequirement but this is not exposed in tool definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2025-06-18+ | v2 |
Convert USDC amount to micro units (6 decimals) - Multiplies amount by 1,000,000 and returns as string
Verify a Solana USDC transaction by signature - Checks if signature is valid Solana format and queries the Solana RPC to validate the transaction and extract payment details
Quick verify function for Solana USDC payments - Convenience function that creates a SolanaVerifier instance and verifies a transaction signature
x402 Payment Middleware for Hono - Enforces payment requirement via 402 HTTP status code and verifies payment signatures before allowing access to protected endpoints
Descriptions are generic and lack context for LLM selection. 'Verify a Solana USDC transaction by signature' does not explain when to use this vs 'verifySolanaPayment'. No dependency hints (e.g., 'Call detectNetworkFromSignature first if network is unknown'). No error recovery guidance.
No error handling guidance. Tools like 'verify' and 'parsePaymentHeader' will fail on invalid input but provide no actionable error messages. No recovery hints (e.g., 'Invalid signature format. Use detectNetworkFromSignature to identify the network first.').