Loading ToolBench
Multi-chain blockchain AML risk scoring for AI agents. Provides 7 AML analysis tools supporting 12 chains (BTC, ETH, POL, BNB, BASE, ARB, OP, AVAX, SOL, KAIA, TRX, XRP) with x402 USDC payments on Base and Solana.
ChainAnalyzer MCP defines 7 blockchain compliance tools with reasonable schemas and descriptions, but falls short of production-grade definition quality. Naming is action-verb consistent (check_, sanctions_, trace_, detect_, cluster_, batch_, bridge_). Descriptions average ~200 chars and address WHAT each tool does and supported chains. However, critical gaps exist: (1) Most tools lack documented output schemas, the rubric requires 100% of A+ tools document return types, and this server provides none. (2) Parameter descriptions lack constraint guidance, e.g., 'depth' params have no unit or range explanation in the description text (though JSON schema min/max exist). (3) Error handling is not documented, no guidance on retryability, recovery paths, or what failures look like. (4) The batch_screening tool advertises '50 items' but the schema declares maxItems=50 without describing what happens at the boundary or on partial failures. (5) bridge_flow_trace has an exceptionally verbose description (500+ chars) that buries key details. Most tools are READ_ONLY and safe, but this safety posture is not explicitly declared in descriptions (pattern:permission-gate and pattern:scope-declaration absent). Baseline comparison: average tool description is 194 chars (p10=34, p90=392), these descriptions fit the range but lack the LLM-optimized clarity of top-tier tools. Per-tool scoring reveals consistent moderate quality: strong naming and basic schemas, but thin descriptions lacking constraint callouts and error context.
Batch AML screening for multiple addresses at once (up to 50). Returns risk level and score per address.
Multi-hop cross-chain forensic trace for a wallet address. Auto-detects bridge solvers (NEAR Intents, Wormhole, deBridge, Stargate, Across, Synapse, Hop), follows relay chains across chains, and emits forensic insights including solver_detected, relay_chain, and same_intent_correlation (with cross-chain settlement timing). Returns a graph of nodes (with role classifications: solver / relay / user / exchange / scanned / bridge) and edges (transfer / bridge_in / bridge_out, with on-chain TX signatures). Ideal for compliance teams investigating cross-chain laundering and AI agents that need provable cross-chain fund-flow evidence.
Get AML risk score for any blockchain address. Returns risk level, score (0-100), detections, and ML anomaly score. 12 chains live for self-serve (BTC, ETH, POL, BNB, BASE, ARB, OP, AVAX, SOL, KAIA, TRX, XRP).
Identify related addresses through Neo4j graph clustering. Returns cluster size and related addresses.
Detect CoinJoin, mixing, and tumbling patterns in a Bitcoin transaction.
No documented output schemas. Rubric requires 100% of A+ tools document return types. This server provides no structured documentation of what check_address_risk, trace_transaction, cluster_wallet, or bridge_flow_trace return. LLMs cannot plan downstream tool calls or extract fields from responses without documented output structure.
Parameter descriptions lack actionable constraints. 'depth' parameters in trace_transaction, cluster_wallet, and bridge_flow_trace have JSON Schema min/max but descriptions do not explain the units, performance implications, or guidance on selecting values. LLMs rely on description text to understand constraints, they do not reliably parse JSON Schema numeric bounds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Screen address against OFAC, FATF, JFSA, and ChainAnalyzer ScamDB sanctions lists.
Trace fund flows for a transaction with ML anomaly detection. Returns graph of addresses and transfers.
No error handling documentation. Rubric pattern:recovery-guide requires error responses tell the LLM what to do next. No description explains what failures look like, which are retryable, or recovery paths. E.g., sanctions_check does not document what happens if a chain is not supported, or how to retry intelligently.
bridge_flow_trace description is verbose (500+ chars) and buries key details. Rubric baseline for tool description is 10 - 1024 chars with p90 at 392 chars. While technically within range, the excessive length mixes implementation details (solver_detected, relay_chain, same_intent_correlation) with use cases in a way that risks confusing LLM tool selection. Should be split into concise summary (~150 chars) with detailed behavior in a separate 'Advanced' or 'Notes' section if the SDK supports it.
No scope or permission declarations. Rubric pattern:scope-declaration and pattern:permission-gate require each tool declare what permissions it requires. All 7 tools are READ_ONLY, which should be explicitly documented so agents know they are safe to call freely without audit friction.
batch_screening lacks per-item error handling documentation. When screening 50 addresses, if 3 fail, does the tool return partial results or total failure? Rubric requires 'When processing multiple items, return per-item success/failure.' No description clarifies this.
Parameter naming inconsistency: 'tx_hash' vs 'address' vs 'addresses'. While not severe, best practice is consistent suffixes. 'tx_hash' should be 'transaction_hash' or consistently shortened to 'tx_id' across tools. Similarly, some tools use 'address' while batch_screening pluralizes to 'addresses', this is correct, but naming convention should be documented.