Loading ToolBench
A FastAPI-based HTTP gateway that implements x402 payment verification for Solana SPL token transfers. Verifies payment proofs before granting access to protected endpoints.
This server has significant definition quality gaps. Tool names lack clear action verbs (e.g., '_verify_onchain_receipt' starts with underscore, '_check_and_burn_tx' is internal-style). Descriptions exist but are overly technical and lack LLM-friendly guidance on WHEN to use each tool. Input schemas are present but parameters lack proper type definitions in several cases (e.g., 'request' parameter in verify_x402_proof is typed as 'object' with no schema detail). Output schemas are completely undocumented. Error handling is minimal, no recovery guidance or actionable error messages. The server exposes internal implementation details (Redis, local cache fallback) in descriptions rather than abstracting them. No parameter validation constraints (enums, ranges, patterns) are declared.
Atomic check & burn using Redis SETNX with 24h TTL to prevent replay attacks. Returns True if transaction is fresh and burned, False if replayed.
Circuit breaker wrapper with strict timeout for on-chain receipt verification. Currently supports Solana network only.
Protected endpoint that returns premium data after verifying x402 payment proof. Returns 402 Payment Required with challenge if proof is invalid or missing.
Queries the Solana RPC to cryptographically verify an SPL Token transfer. Checks: 1. Tx success, 2. Correct Mint (USDC), 3. Correct Recipient (Merchant ATA), 4. Sufficient Amount, 5. Memo match (if provided).
FastAPI Dependency to verify x402 payment headers. Validates payment proof from X-Payment-Proof header, checks for replay attacks using Redis or local cache, rate-limits invalid proofs per client IP, and verifies on-chain receipt.
Tool names violate verb_noun convention. '_verify_onchain_receipt' and '_check_and_burn_tx' use underscore prefix (internal style) and lack clarity. LLMs cannot infer intent from names alone.
Input schemas lack proper type definitions. 'request' parameter in verify_x402_proof is typed as 'object' with no nested schema. Parameters should declare types (string, number, boolean, array, object with properties).
No output schemas documented. LLMs cannot plan downstream calls or extract fields without knowing return structure. All tools should declare what they return.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Descriptions expose implementation details (Redis, local cache, Upstash) instead of abstracting them. Descriptions should focus on WHAT the tool does and WHEN to use it, not HOW it's implemented.
No parameter constraints (enums, ranges, patterns) declared. 'network' parameter accepts free-form strings; should be enum ['solana']. 'required_memo' has no length/format constraints.