This server provides AML (Anti-Money Laundering) risk checks for blockchain addresses and transactions, plus Crypto APIs reference documentation.
verify-address — Check whether a blockchain address is flagged or associated with fraud, sanctions, ransomware, exploits, darknet markets, or other AML risk categories (returns risk score, risk band, and flagging sources). Costs 200,000 credits per call.
screen-transaction — Screen a transaction and its participants against AML data (returns flagged status, risk score/band, and flagged addresses with roles, scores, severities, and categories) across 19 blockchains including ethereum, bitcoin, solana, xrp, tron, and polygon. Costs 500,000 credits per call.
system_info — Retrieve Crypto APIs reference docs (no credits consumed) on: supported blockchains, error codes, credit charging structure, callback/webhook mechanics, and rate/throughput limits.
Provides AML address verification and transaction screening for Bitcoin, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Dash, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Dogecoin, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Ethereum, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Litecoin, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Optimism, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Polygon, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Solana, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for XRP, checking for fraud, sanctions, and other risk categories.
Provides AML address verification and transaction screening for Zcash, checking for fraud, sanctions, and other risk categories.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@cryptoapis-io/mcp-aml Verify this Bitcoin address for sanctions or fraud"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Crypto APIs AML (Anti-Money Laundering) product. Verify addresses and screen transactions for fraud, sanctions, and other AML risk categories.
API Version: Compatible with Crypto APIs version 2024-12-12
Verify whether an address is flagged or associated with fraud, sanctions, ransomware, exploits, darknet markets, or other AML risk categories
Screen a transaction and its participants against AML data, returning risk score, risk band, and flagged addresses with roles/categories/severity
Get an address's exposure to risky entities/categories via the AML exposure graph
List the paths connecting an address to risky entities in the AML exposure graph, with cursor pagination
Related MCP server: yaml-ai-mcp
Node.js 18+
Crypto APIs account and API key (sign up | get API key)
npm install @cryptoapis-io/mcp-amlOr install all Crypto APIs MCP servers: npm install @cryptoapis-io/mcp
# Run with API key
npx @cryptoapis-io/mcp-aml --api-key YOUR_API_KEY
# Or use environment variable
export CRYPTOAPIS_API_KEY=YOUR_API_KEY
npx @cryptoapis-io/mcp-aml
# HTTP transport (listens on 127.0.0.1; see "Exposing the server beyond localhost")
npx @cryptoapis-io/mcp-aml --transport http --port 3000 --api-key YOUR_API_KEYAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"cryptoapis-aml": {
"command": "npx",
"args": ["-y", "@cryptoapis-io/mcp-aml"],
"env": {
"CRYPTOAPIS_API_KEY": "your_api_key_here"
}
}
}
}Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"cryptoapis-aml": {
"command": "npx",
"args": ["-y", "@cryptoapis-io/mcp-aml"],
"env": {
"CRYPTOAPIS_API_KEY": "your_api_key_here"
}
}
}
}npx @modelcontextprotocol/inspector npx @cryptoapis-io/mcp-aml --api-key YOUR_API_KEYStart the server in HTTP mode:
npx @cryptoapis-io/mcp-aml --transport http --port 3000 --api-key YOUR_API_KEYIn your n8n workflow, add an AI Agent node
Under Tools, add an MCP Client Tool and set the URL to http://localhost:3000/mcp
n8n in Docker:
localhostinside the container is not your machine. Start the server with--host 0.0.0.0andMCP_AUTH_TOKENset (see Exposing the server beyond localhost), usehttp://host.docker.internal:3000/mcpas the URL, and add anAuthorization: Bearer <token>header to the MCP Client Tool credential.
All servers default to port 3000. Use
--portto assign different ports when running multiple servers.
amlAction | Description |
| Check if an address is flagged for fraud, sanctions, or other AML risk categories. Params: |
| Screen a transaction and its participants against AML data. Params: |
| Get an address's exposure to risky entities/categories in the AML exposure graph. Params: |
| List the paths connecting an address to risky entities in the AML exposure graph. Params: |
screen-transaction supports: ethereum, ethereum-classic, binance-smart-chain, bitcoin, bitcoin-cash, dash, dogecoin, litecoin, arbitrum, polygon, avalanche, optimism, base, zcash, xrp, solana, tezos, kaspa, tron.
get-address-exposure and list-address-exposure-paths support a narrower set of 13 chains (no exposure graph for arbitrum, avalanche, base, optimism, tezos, or kaspa): ethereum, binance-smart-chain, ethereum-classic, polygon, tron, bitcoin, bitcoin-cash, litecoin, dogecoin, dash, zcash, xrp, solana.
Note: these are the highest per-call credit cost endpoints in the Crypto APIs suite —
verify-addressis 200,000 credits,screen-transactionis 500,000 credits per call,get-address-exposureis 200,000 credits per request, andlist-address-exposure-pathsis 100,000 credits per page.
Argument | Description | Default |
| Crypto APIs API key |
|
| Transport type: |
|
| HTTP host (use |
|
| Bearer token callers must send ( |
|
| Comma-separated | — |
| HTTP port |
|
| HTTP path |
|
| Enable stateless HTTP mode |
|
When using HTTP transport, the server supports two API key modes:
With --api-key: The key is used for all requests. x-api-key request headers are ignored.
Without --api-key: Each request must include an x-api-key header with a valid Crypto APIs key. This enables hosting a public server where each user provides their own key.
# Per-request key mode (multi-tenant)
npx @cryptoapis-io/mcp-aml --transport http --port 3000
# Clients send x-api-key header with each requestHTTP mode listens on 127.0.0.1 by default, so only processes on the same machine can reach it.
To accept connections from other machines or containers, bind explicitly and protect the port:
# Startup-key mode: callers must present the token (the server refuses to start without one)
export MCP_AUTH_TOKEN=$(openssl rand -hex 32)
npx @cryptoapis-io/mcp-aml --transport http --host 0.0.0.0 --port 3000 --api-key YOUR_API_KEY \
--allowed-hosts mcp.internal.example
# Clients send: Authorization: Bearer $MCP_AUTH_TOKEN
# Per-request key mode: no startup key, every request must carry the caller's own x-api-key
npx @cryptoapis-io/mcp-aml --transport http --host 0.0.0.0 --port 3000--allowed-hosts restricts the Host header (DNS rebinding protection) when not bound to loopback. Prefer MCP_AUTH_TOKEN over --auth-token: command-line arguments are visible in the process list.
Stdio transport always requires an API key at startup.
Warning: Making requests without a valid API key — or with an incorrect one — may result in your IP being banned from the Crypto APIs ecosystem. Always ensure a valid API key is configured before starting any server.
Crypto APIs provides an official remote MCP server with all tools available via HTTP Streamable transport at https://ai.cryptoapis.io/mcp. Pass your API key via the x-api-key header — no installation required.
MIT
AML (Anti-Money Laundering) risk checks for addresses and transactions.
Actions: • verify-address: Check if a blockchain address is flagged or associated with fraud, sanctions, ransomware, exploits, darknet markets, or other AML risk categories. Returns risk score, risk band, and the flagging sources. • screen-transaction: Screen a transaction against AML data. Returns whether the transaction is flagged, its risk score/band, and the flagged participant addresses with their roles, scores, severities and categories. • get-address-exposure: Get an address's exposure to risky entities/categories across the AML exposure graph. Params: blockchain, address. Costs 200,000 credits per request. • list-address-exposure-paths: List the paths connecting an address to risky entities in the AML exposure graph. Params: blockchain, address; optional rootAddress (only return routes originating from this flagged root address), limit (1-50, defaults to 10), startingAfter (pagination cursor). Costs 100,000 credits per page - pass the response's next cursor back as startingAfter to fetch subsequent pages.
get-address-exposure and list-address-exposure-paths only support a subset of chains - see the blockchain parameter description.
Note: the credit cost of these endpoints is significant — see credits below.
Credits by action (source: OpenAPI): • get-address-exposure: 200000 • list-address-exposure-paths: 100000 • screen-transaction: 500000 • verify-address: 200000
Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of exposure paths to return per page (1-50, defaults to 10) - applies to list-address-exposure-paths only | |
| action | Yes | Action to perform | |
| address | No | Blockchain address - required for verify-address, get-address-exposure, and list-address-exposure-paths | |
| context | No | Optional context for the request - echoed back in response | |
| blockchain | No | Blockchain protocol - required for screen-transaction, get-address-exposure and list-address-exposure-paths. screen-transaction accepts: ethereum, ethereum-classic, binance-smart-chain, bitcoin, bitcoin-cash, dash, dogecoin, litecoin, arbitrum, polygon, avalanche, optimism, base, zcash, xrp, solana, tezos, kaspa, tron. get-address-exposure and list-address-exposure-paths accept only: ethereum, binance-smart-chain, ethereum-classic, polygon, tron, bitcoin, bitcoin-cash, litecoin, dogecoin, dash, zcash, xrp, solana | |
| rootAddress | No | Only return routes that originate from this flagged root address (one of the roots[].rootAddress values returned by get-address-exposure) - optional, applies to list-address-exposure-paths only | |
| startingAfter | No | Pagination cursor - pass the nextStartingAfter value from the previous response to fetch the next page; applies to list-address-exposure-paths only | |
| transactionHash | No | Transaction hash to screen against AML data - required for screen-transaction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden well: it discloses credit costs per action, notes that costs are significant and indicative, explains pagination for list-address-exposure-paths, and limits two actions to a subset of chains. It does not explicitly state that all operations are read-only or describe auth/rate-limit behavior, but it provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear overview and uses a well-structured action list, followed by caveats and costs. It is somewhat repetitive because per-action credit costs are repeated in a separate credits section, but the structure remains readable and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool with 8 parameters, no annotations, and no output schema, the description is largely complete: it explains action purposes, return highlights for two actions, chain restrictions, pagination, and costs. It could more fully describe the return shape for exposure and path-listing actions, but the missing pieces are modest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter in detail, including chain subsets, rootAddress semantics, and pagination cursors. The description restates some parameter usage but adds little beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific domain and resource: AML risk checks for addresses and transactions. It then enumerates all four actions with distinct verbs and resources, making each action distinguishable from the others and from the only sibling, system_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Each action is paired with a clear condition: verify an address, screen a transaction, inspect exposure, or list exposure paths. This gives strong action-routing guidance. It does not explicitly state when not to use an action or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CryptoAPIs reference documentation — no API call, no credits consumed.
Actions: • blockchains — Supported blockchains, networks, products per chain, denominations, fiat currencies • errors — Complete error code table (HTTP status, error code, message) • credits — Credit charging structure, cost multipliers per blockchain, monitoring & operations taxes (xPub, synced addresses, blockchain events), pay-as-you-go • callbacks — Webhook mechanics: URL requirements, retry strategy (5 retries, exponential backoff), HMAC security, idempotency • limits — Throughput soft/hard limits per plan, 2.1x penalty multiplier, rate limiting behavior
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Reference topic to retrieve | |
| context | No | Optional context for the request - echoed back in response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explicitly notes 'no API call, no credits consumed,' which is key behavioral information. It also discloses detailed content such as retry strategy, HMAC security, and rate-limit penalty multipliers, going well beyond a generic 'returns info' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the critical 'no API call, no credits consumed' caveat and uses a compact bullet list. Each bullet covers a distinct action without wasted prose, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a reference-documentation tool with no output schema and no annotations, this description is complete enough: it defines all five actions and gives sufficient detail about their content. It also clarifies side effects (none) and cost implications (none), covering the main contextual risks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning by explaining each allowed action enum value in detail (e.g., callbacks covers URL requirements, 5 retries, HMAC). This transforms enum names into actionable context and compensates fully beyond the schema's short parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states this is CryptoAPIs reference documentation with no API call or credits consumed, and enumerates five specific topics (blockchains, errors, credits, callbacks, limits). This clearly identifies it as an informational tool distinct from domain siblings like aml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The bulleted actions give clear contexts for when to use the tool, such as looking up error codes, credit structures, callback mechanics, or rate limits. It does not explicitly name alternatives or exclusion conditions, so it stops short of a full when/when-not specification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0aml6 fields changedInput schema / properties / action / enumPrevious value: -[
- "verify-address",
- "screen-transaction"
-]New value: +[
+ "verify-address",
+ "screen-transaction",
+ "get-address-exposure",
+ "list-address-exposure-paths"
+]Input schema / properties / address / descriptionPrevious value: -"Blockchain address to verify against AML databases - required for verify-address"New value: +"Blockchain address - required for verify-address, get-address-exposure, and list-address-exposure-paths"Input schema / properties / blockchain / descriptionPrevious value: -"Blockchain protocol the transaction belongs to - required for screen-transaction. One of: ethereum, ethereum-classic, binance-smart-chain, bitcoin, bitcoin-cash, dash, dogecoin, litecoin, arbitrum, polygon, avalanche, optimism, base, zcash, xrp, solana, tezos, kaspa, tron"New value: +"Blockchain protocol - required for screen-transaction, get-address-exposure and list-address-exposure-paths. screen-transaction accepts: ethereum, ethereum-classic, binance-smart-chain, bitcoin, bitcoin-cash, dash, dogecoin, litecoin, arbitrum, polygon, avalanche, optimism, base, zcash, xrp, solana, tezos, kaspa, tron. get-address-exposure and list-address-exposure-paths accept only: ethereum, binance-smart-chain, ethereum-classic, polygon, tron, bitcoin, bitcoin-cash, litecoin, dogecoin, dash, zcash, xrp, solana"Input schema / properties / limitAdded value: +{
+ "description": "Number of exposure paths to return per page (1-50, defaults to 10) - applies to list-address-exposure-paths only",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / rootAddressAdded value: +{
+ "description": "Only return routes that originate from this flagged root address (one of the roots[].rootAddress values returned by get-address-exposure) - optional, applies to list-address-exposure-paths only",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / startingAfterAdded value: +{
+ "description": "Pagination cursor - pass the nextStartingAfter value from the previous response to fetch the next page; applies to list-address-exposure-paths only",
+ "type": "string"
+}v0.1.0amlsystem_infoScored across 2 tools
The two tools are clearly distinct: `aml` performs blockchain AML risk checks and `system_info` returns reference documentation without API calls. An agent can easily choose between them. The multiple AML actions are bundled under one tool, but that is an intra-tool concern rather than tool-selection ambiguity.
`system_info` uses a snake_case noun phrase while `aml` is a bare acronym, so the two names do not follow a single predictable pattern. Both remain readable and reasonably descriptive, but the convention is mixed.
Two tools is on the thin side for the stated AML purpose, especially since one is purely reference documentation. The functional surface is effectively a single `aml` tool with four actions, making the overall offering borderline minimal rather than well-scoped.
The AML surface covers address verification, transaction screening, address exposure, and exposure-path discovery, which is solid coverage of the core AML workflow. Minor gaps exist, such as batch screening or broader entity lookup, but agents can work around them.
Crypto transaction firewall and risk tools for MCP agents.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
Crypto market intelligence, token rug-checks, and wallet verification in one MCP server.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
