@cryptoapis-io/mcp-utils
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_AUTH_TOKEN | No | Bearer token that HTTP callers must send in the Authorization header. Used when exposing the server beyond localhost. Preferred over the --auth-token CLI argument. | |
| CRYPTOAPIS_API_KEY | Yes | Crypto APIs API key. Required for stdio transport and recommended for HTTP transport. Can alternatively be passed via the --api-key CLI argument. |
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 |
|---|---|
| utxo_utilsA | UTXO utils (Utils product): validate address, decode raw transaction hex, convert Bitcoin Cash address. Actions: • validate-address: Check if a UTXO address is valid • decode-raw-transaction: Decode a raw transaction hex • convert-bitcoin-cash-address: Convert Bitcoin Cash address (legacy ↔ cash format); Bitcoin Cash only, no blockchain parameter (network + address) 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): • convert-bitcoin-cash-address: bitcoin-cash 12 • decode-raw-transaction: bitcoin 10, bitcoin-cash 12, dash 11, dogecoin 11, litecoin 11, zcash 13 • validate-address: bitcoin 10, bitcoin-cash 12, dash 11, dogecoin 11, litecoin 11, zcash 13 Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers. |
| evm_utilsA | EVM utils (Utils product): validate address, decode raw transaction hex. Actions: • validate-address: Check if an EVM address is valid • decode-raw-transaction: Decode a raw transaction hex Blockchain → Networks: • ethereum: mainnet, sepolia • ethereum-classic: mainnet, mordor • binance-smart-chain: mainnet, testnet • tron: mainnet, nile Credits by action (source: OpenAPI): • decode-raw-transaction: binance-smart-chain 25, ethereum 10, ethereum-classic 13, tron 15 • validate-address: binance-smart-chain 25, ethereum 10, ethereum-classic 13, tron 15 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_utilsA | XRP utils (Utils product): validate address, decode/encode X-Address. Actions: • validate-address: Check if an XRP address is valid • decode-x-address: Decode X-Address to classic address and tag • encode-x-address: Encode classic address and tag to X-Address Networks: mainnet, testnet Credits by action (source: OpenAPI): • decode-x-address: 10 • encode-x-address: 10 • validate-address: 10 Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers. |
| derive_addressesA | Utils: derive HD wallet (xPub, yPub, zPub) change or receiving addresses without syncing. GET /utils/{blockchain}/{network}/xpubs/{extendedPublicKey}/derive-addresses Derives up to 10 addresses. By default creates receiving/deposit address; set isChange=true for change address (UTXO only). Credits by action (source: OpenAPI): • binance-smart-chain: 25 • bitcoin: 10 • bitcoin-cash: 12 • dash: 11 • dogecoin: 11 • ethereum: 10 • ethereum-classic: 13 • litecoin: 11 • tron: 15 • xrp: 10 • zcash: 13 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 |
|---|---|
| derive-addresses | Derive HD wallet addresses from an extended public key |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| supported-chains | Lists every blockchain, network, and action supported by the utils tools |
TDQS
Scored across 5 tools
Tools are mostly separated by blockchain family (utxo, evm, xrp, derive, system docs), which is clear. However, validate-address and decode-raw-transaction appear in both utxo_utils and evm_utils, so the agent must correctly classify the chain; derive_addresses also overlaps conceptually with the chain-specific utils.
utxo_utils, evm_utils, and xrp_utils follow a consistent chain_utils pattern, but system_info is a generic reference tool and derive_addresses uses a verb_noun action style. The mix is readable but not fully consistent.
Five tools is well-scoped for a utility server. Each tool groups related actions by chain family or function, avoiding excessive fragmentation while keeping the surface manageable.
The set covers reference documentation, address validation, raw transaction decoding, X-Address encode/decode, Bitcoin Cash conversion, and HD address derivation. Minor gaps remain, such as raw transaction encoding or broader conversion utilities, but the core Utils domain is well represented.