cryptoapis-address-latest
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_AUTH_TOKEN | No | Bearer token callers must send when exposing the server beyond localhost (HTTP transport with --host 0.0.0.0). Optional. | |
| CRYPTOAPIS_API_KEY | Yes | Your Crypto APIs API key. Required to run the server. |
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 |
|---|---|
| evm_address_latestA | Query latest EVM address data (last 14 days). Cursor pagination: use 'nextStartingAfter' from response as 'startingAfter'. Actions & supported blockchains: • get-balance: ethereum, ethereum-classic, binance-smart-chain, tron, polygon, avalanche (C-Chain), arbitrum, base, optimism • get-next-nonce: ethereum, ethereum-classic, binance-smart-chain (mainnet, mordor, testnet, sepolia) • list-transactions: ethereum, ethereum-classic, binance-smart-chain, arbitrum, polygon, avalanche (C-Chain), base, optimism, tron • list-token-transfers: ethereum, ethereum-classic, binance-smart-chain, tron, polygon, avalanche (C-Chain), arbitrum, base, optimism • list-internal-transactions: ethereum, ethereum-classic, binance-smart-chain, polygon, avalanche (C-Chain), arbitrum, base, optimism, tron Blockchain → Networks: • ethereum: mainnet, sepolia • ethereum-classic: mainnet, mordor • binance-smart-chain: mainnet, testnet • polygon: mainnet, amoy • tron: mainnet, nile • avalanche (C-Chain): mainnet, fuji • arbitrum: mainnet, sepolia • base: mainnet, sepolia • optimism: mainnet, sepolia Credits by action (source: OpenAPI): • get-balance: arbitrum 48, avalanche 54, base 36, binance-smart-chain 75, ethereum 30, ethereum-classic 39, optimism 42, polygon 60, tron 45 • get-next-nonce: arbitrum 32, avalanche 36, base 24, binance-smart-chain 50, ethereum 20, ethereum-classic 26, optimism 28, polygon 40, tron 30 • list-internal-transactions: arbitrum 512, avalanche 576, base 384, binance-smart-chain 800, ethereum 320, ethereum-classic 416, optimism 448, polygon 640, tron 480 • list-token-transfers: arbitrum 352, avalanche 396, base 264, binance-smart-chain 550, ethereum 220, ethereum-classic 286, optimism 308, polygon 440, tron 330 • list-transactions: arbitrum 192, avalanche 216, base 144, binance-smart-chain 300, ethereum 120, ethereum-classic 156, optimism 168, polygon 240, tron 180 Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers. |
| utxo_address_latestA | Query latest UTXO address data (last 14 days). • get-balance: no pagination • list-transactions: cursor pagination - use 'nextStartingAfter' from response as 'startingAfter' • list-unconfirmed-transactions: offset pagination - use 'limit' and 'offset' (lists unconfirmed/mempool transactions) Actions & supported blockchains: • get-balance: bitcoin, bitcoin-cash, litecoin, dash, dogecoin, zcash • list-transactions: bitcoin, bitcoin-cash, dash, dogecoin, litecoin, zcash • list-unconfirmed-transactions: bitcoin, bitcoin-cash, litecoin, dogecoin, dash, zcash Blockchain → Networks: • bitcoin: mainnet, testnet • bitcoin-cash: mainnet, testnet • litecoin: mainnet, testnet • dogecoin: mainnet, testnet • dash: mainnet, testnet • zcash: mainnet, testnet Credits by action (source: OpenAPI): • get-balance: bitcoin 510, bitcoin-cash 612, dash 561, dogecoin 561, litecoin 561, zcash 663 • list-transactions: bitcoin 110, bitcoin-cash 132, dash 121, dogecoin 121, litecoin 121, zcash 143 • list-unconfirmed-transactions: bitcoin 110, bitcoin-cash 132, dash 121, dogecoin 121, litecoin 121, zcash 143 Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers. |
| solana_address_latestA | Query latest Solana address data (last 14 days). Cursor pagination: use 'nextStartingAfter' from response as 'startingAfter'. Actions: • get-balance: Get address SOL balance • list-transactions: Get address transactions • list-tokens: Get SPL tokens held by address Networks: mainnet, devnet Credits by action (source: OpenAPI): • get-balance: solana 75 • list-tokens: solana 120 • list-transactions: solana 90 Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers. |
| xrp_address_latestA | Query latest XRP (Ripple) address data. Cursor pagination: use 'nextStartingAfter' from response as 'startingAfter'. Actions: • get-balance: Get address XRP balance • list-transactions: Get address transactions • get-next-sequence: Get next available sequence number for transactions Networks: mainnet, testnet Credits by action (source: OpenAPI): • get-balance: xrp 20 • get-next-sequence: xrp 20 • list-transactions: xrp 110 Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers. |
| kaspa_address_latestA | Query latest Kaspa address data. Cursor pagination: use 'nextStartingAfter' from response as 'startingAfter'. Actions: • get-balance: Get address KAS balance • list-transactions: Get address transactions Networks: mainnet (only) Credits by action (source: OpenAPI): • get-balance: kaspa 918 • list-transactions: kaspa 918 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-balances | Check address balances across one or more blockchains |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| supported-chains | Supported blockchains, networks, and actions for address-latest queries |
TDQS
Scored across 6 tools
Each tool maps cleanly to a distinct blockchain family (EVM, UTXO, Solana, XRP, Kaspa) plus a reference tool, and the descriptions explicitly enumerate supported chains so overlaps are avoided. The only friction is that an agent must know which family a given chain belongs to before picking a tool (e.g. tron lives under the EVM tool), which is a mild mapping burden rather than true ambiguity.
Five tools follow an identical <family>_address_latest pattern, which is highly predictable and readable. system_info is the sole deviation, though it is a genuinely different kind of tool (static reference) so the break is defensible.
Six tools is well-scoped for an 'address latest data' server, with one tool per chain family plus a docs tool. Each tool earns its place, and consolidating the per-action operations (get-balance, list-transactions, etc.) into action parameters keeps the surface compact rather than exploding into dozens of near-duplicate tools.
Coverage is solid and reasonably symmetric: every family offers balance plus transaction listing, with family-specific extras (next-nonce, internal transactions, token transfers, unconfirmed txs, next-sequence). Gaps are minor — Kaspa is thin (balance + transactions only), there is no address validation/metadata tool, and webhook/callback management is described in system_info but has no corresponding tool.