MCP server for traql — AML risk scoring for crypto addresses and transactions on Ethereum, BSC, TRON, TON and Bitcoin.
The traql MCP server demonstrates solid tool definition quality with comprehensive input schemas, detailed descriptions, and proper error handling. Both tools (check_address and screen_transaction) are well-named with action verbs, include full JSON Schema definitions with type constraints and enums, and carry explicit tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). Descriptions are substantive (200-300 chars) and explain use cases clearly. However, output schemas are documented only in the code comment (checkOutput type reference) rather than inline in the registration, which slightly reduces discoverability. Parameter descriptions are comprehensive and specific. Error messages are actionable (the buildScreenRequest function validates mutual exclusivity and provides guidance). The main limitation is that the output schema is not fully visible in the source excerpt provided, only a reference to checkOutput type exists, which prevents full validation of response structure clarity.
Score a single crypto address for AML and compliance risk. Returns a risk score from 0 (clean) to 100 (critical), the band it falls into, and the risk categories that drove it — sanctions, mixer, scam, darknet, stolen_funds, ransomware, high_risk_exchange and others. With an API key configured, the response also itemizes every contributing signal with its data source, severity and confidence, so the verdict can be explained rather than just asserted. Use it before sending funds to an unfamiliar address, to triage an address a user pasted, to check a counterparty in an investigation, or to vet a deposit address. Covers Ethereum, BSC, TRON, TON and Bitcoin. Each call consumes one check from the configured traql account.
Screen a transaction for AML and compliance risk by scoring both sides of the transfer. Two modes, chosen by which arguments are given: - Pre-flight — pass `from` and `to` (optionally `amount` and `asset`) to screen a transfer before it is broadcast. Works on every supported chain. - By hash — pass only `tx_hash` to look up a transaction that is already on-chain. Supported on ethereum, bsc, tron and ton. Returns the same score, band, flags and itemized signals as an address check, with each signal marked as applying to the sending or receiving side. Use it as a pre-send safety gate, or to review a payment that already went out. Each call consumes one check from the configured traql account.
Output schema (checkOutput) is referenced but not fully visible in source; only a type reference exists. LLMs cannot verify the exact shape of returned fields (risk score format, band values, signal item structure) from the tool definition alone.
screen_transaction uses a complex conditional parameter pattern (mutually exclusive tx_hash vs from/to). While well-documented in the description and validated in buildScreenRequest, the input schema does not enforce the mutual exclusivity at the JSON Schema level (no oneOf constraint), relying instead on runtime validation.
Parameters 'amount' and 'asset' in screen_transaction are marked optional but their eligibility depends on the mode (pre-flight vs by-hash). The description clarifies this, but the schema does not encode the conditional dependency, forcing LLMs to rely on text hints rather than machine-parseable constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 77 | 2025-06-18+ | v2 |