Loading ToolBench
MCP server for x402 crypto market structure data — camelCase tools, zero config, works everywhere
This server registers 7 crypto market tools with camelCase names and clear read-only semantics. All tools have descriptions (194 - 322 chars, within production baseline of 34 - 392). Input schemas are fully specified with zod validation and typed parameters. However, naming lacks action verbs (marketLight, marketSnapshot are noun-heavy; 'get_market_light' or 'fetch_market_snapshot' would be clearer), output schemas are undocumented (responses are text-wrapped, no structured field definitions), and error handling provides no recovery guidance. The upstream API appears to be abstracted cleanly, but the wrapper does not expose field-level documentation or pagination patterns. Design is single-purpose per tool (good composition), but parameter naming could be more explicit (symbol vs token inconsistency across tools).
Risk score for an Ethereum or Solana wallet address.
x402 API pricing, quick start guide, and migration details for the pay-per-call REST endpoint.
Macro regime plus directional signal and confidence for a token.
Full market data bundle: snapshot, orderflow, and LLM-generated verdict.
Any-token CoinGecko-backed market coverage via /data/light: price, momentum, rank, liquidity and exchange context, and risk flags. Defaults to brief=off for low latency; set brief=full for a Kimi brief. Supports listed CoinGecko symbols beyond the fixed Pillar token list, e.g. WCT.
Cross-exchange orderflow: CVD, whale activity, liquidations, and exchange breakdown.
Tool names lack action verbs. 'marketLight', 'marketSnapshot', 'marketAnalyze' are noun-heavy and do not clearly signal to LLMs what action is performed. Baseline production tools start with get_, list_, search_, create_, etc. in 90% of cases.
Parameter naming inconsistency: marketLight uses 'symbol' while marketSnapshot, marketAnalyze, marketOrderflow, marketFull use 'token'. LLMs conflate similar parameters across tools, risking wrong argument binding.
Output schemas are entirely undocumented. Tools return text-wrapped JSON with no field-level documentation. LLMs cannot plan downstream tool calls or extract structured data without knowing response field names, types, and semantics.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
Free 16-field MCP subset of the live crypto market snapshot: price, funding, OI, buy/sell ratio, fear/greed. Paid REST /data returns the full production snapshot. Supports BTC ETH SOL XRP BNB DOGE ADA AVAX LINK ATOM DOT ARB SUI OP LTC AMP ZEC.
No error handling or recovery guidance. If upstream x402 API returns 400/404, the wrapper re-initializes and retries, but no error messages guide LLMs on what went wrong or what to do next (e.g. 'Invalid token symbol. Supported: BTC, ETH, SOL, ...').
No pagination or result limits documented. Tools like marketFull returning 'full market data bundle' could return large responses, risking context window exhaustion. No total count, next_cursor, or limit parameter present.
Parameter 'brief' enum in marketLight mixes implementation detail (on/off) with LLM-facing affordance (full). Description says 'Use off for fast, full for Kimi brief' but Kimi is not defined in parameters or responses, LLM cannot infer what output format 'full' produces.
addressRisk accepts 'Ethereum or Solana wallet address' but no parameter constraint or format hint given. LLM must guess whether to pass full 42-char Ethereum address, 34-char Solana address, or something else. No validation examples provided.