Tanod MCP server

chainpeek: screen a crypto address against the OFAC SDN list

check_sanctions

Read-onlyIdempotent

Screen a single crypto address against the US OFAC SDN digital-currency address list to find sanctions matches; for up to 1,000 addresses, use batch screening.

Instructions

chainpeek: screen one crypto address against the US OFAC SDN list's digital currency addresses. For up to 1,000 addresses use check_sanctions_batch; for lookalikes use check_address_poisoning. EVM and bech32 addresses match case-insensitively; base58 BTC, TRX and other formats must match exactly as listed. Screening against the US OFAC SDN digital-currency-address list only (the Treasury SDN list's published crypto addresses), as of the list_date in the answer; a non-match does not clear an address; not legal advice or a full compliance check (no other sanctions lists, no clustering, ownership or exposure analysis); verify any match at sanctionssearch.ofac.treas.gov. Local lookup, typically under 0.1 s (first call up to 1 s). Price: USD 0.002. Free: 10 chain reads per IP per UTC day. Docs: https://tanod.dev/learn/check-crypto-address-sanctions.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`address`	Yes	Crypto address: EVM 0x address, bech32, or a BTC/TRX/other address exactly as listed.

Output Schema

TableJSON Schema

Name	Required	Description
`list`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`source`	No
`address`	No
`matched`	No
`matches`	No
`list_date`	No
`disclaimer`	No
`address_kind`	No
`list_addresses`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds substantial context beyond that: the exact list and date basis, false-negative caveat, compliance limitations, verification link, latency, price, and free-tier limit. Nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and alternatives, then packs caveats, limits, and pricing into a single dense paragraph. Every sentence carries operational information, though the result is long and could be more scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's screening complexity, single-address schema, existing output schema, and safety annotations, the description covers scope, alternatives, limitations, timing, cost, and verification guidance. It omits nothing material for correct selection or invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the address parameter at 100% with a description and pattern. The description adds matching semantics: EVM/bech32 addresses match case-insensitively while base58 BTC, TRX, and other formats must be provided exactly as listed, useful for correct input formatting. It does not restate the schema's length/pattern constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: screen one crypto address against the US OFAC SDN digital-currency list. It explicitly names the sibling tools check_sanctions_batch and check_address_poisoning and distinguishes single-address vs lookalike use cases, so an agent can select it without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes to alternatives: use check_sanctions_batch for up to 1,000 addresses and check_address_poisoning for lookalikes. It also states scope (OFAC SDN digital-currency addresses only), that a non-match does not clear, and that this is not legal advice or full compliance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server