@cryptoapis-io/mcp-aml
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CRYPTOAPIS_API_KEY | No | Your Crypto APIs API key. Required if not provided via --api-key. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| amlA | 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. Note: the credit cost of these endpoints is significant — see credits below. Credits by action (source: OpenAPI): • 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. |
| system_infoA | 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 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| check-aml-risk | Check the AML risk of a blockchain address or transaction |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| supported-capabilities | Available AML tools, actions, and the blockchains screen-transaction supports |
TDQS
Scored across 2 tools
The two tools are completely distinct: one performs AML checks on addresses/transactions, the other provides system documentation. There is no overlap or ambiguity between them.
Tool names 'aml' and 'system_info' follow no consistent pattern, mixing an acronym with snake_case. The action names inside 'aml' use hyphenation, further breaking any unified naming convention.
With only two tools, the server feels thin, especially since one tool is documentation-only. However, the core AML operations are bundled into a single tool, making it a borderline case.
The AML tool covers the essential functions for its purpose: verifying addresses and screening transactions. Minor gaps like batch processing or detailed report retrieval exist, but they are not critical for the primary use case.