Skip to main content
Glama
CryptoAPIs-io

@cryptoapis-io/mcp-aml

Official
by CryptoAPIs-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

aml

AML (Anti-Money Laundering) risk checks for addresses and transactions.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of exposure paths to return per page (1-50, defaults to 10) - applies to list-address-exposure-paths only
actionYesAction to perform
addressNoBlockchain address - required for verify-address, get-address-exposure, and list-address-exposure-paths
contextNoOptional context for the request - echoed back in response
blockchainNoBlockchain 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
rootAddressNoOnly 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
startingAfterNoPagination cursor - pass the nextStartingAfter value from the previous response to fetch the next page; applies to list-address-exposure-paths only
transactionHashNoTransaction hash to screen against AML data - required for screen-transaction

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.3.0
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "verify-address",
-  "screen-transaction"
-]New value: +[
+  "verify-address",
+  "screen-transaction",
+  "get-address-exposure",
+  "list-address-exposure-paths"
+]
    • changedInput schema / properties / address / description
      Previous 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"
    • changedInput schema / properties / blockchain / description
      Previous 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"
    • addedInput schema / properties / limit
      Added 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"
+}
    • addedInput schema / properties / rootAddress
      Added 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"
+}
    • addedInput schema / properties / startingAfter
      Added 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"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools