@cryptoapis-io/mcp-transactions-data
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_AUTH_TOKEN | No | Bearer token callers must send (Authorization: Bearer <token>). Preferred over the --auth-token CLI argument. Required when binding to a non-loopback address in startup-key mode. | |
| CRYPTOAPIS_API_KEY | Yes | Your Crypto APIs API key. Required for stdio transport and for HTTP transport when using a startup 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 |
|---|---|
| transactions_data_utxoB | Transactions Data UTXO: get transaction details or raw transaction data by hash. Actions: get-transaction-details, get-raw-transaction-data. Blockchains: bitcoin, bitcoin-cash, litecoin, dogecoin, dash, zcash. Networks: mainnet, testnet. Credits by action (source: OpenAPI): • get-raw-transaction-data: bitcoin 110, bitcoin-cash 132, dash 121, dogecoin 121, litecoin 121, zcash 143 • get-transaction-details: 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. |
| transactions_data_evmB | Transactions Data EVM: get transaction details, internal transactions, token transfers, or logs by transaction hash. Actions: get-transaction-details, list-internal-transactions, list-token-transfers, list-logs. Credits by action (source: OpenAPI): • get-transaction-details: arbitrum 192, avalanche 216, base 144, binance-smart-chain 300, ethereum 120, ethereum-classic 156, optimism 168, polygon 240, tron 180 • 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-logs: arbitrum 192, avalanche 216, base 144, binance-smart-chain 300, ethereum 120, ethereum-classic 156, optimism 168, polygon 240, tron 180 • list-token-transfers: arbitrum 352, avalanche 396, base 264, binance-smart-chain 550, ethereum 220, ethereum-classic 286, optimism 308, polygon 440, tron 330 Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers. |
| transactions_data_solanaB | Transactions Data Solana: get transaction details by transaction hash (signature). Networks: mainnet, devnet. Credits per call: 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. |
| transactions_data_xrpB | Transactions Data XRP: get transaction details by transaction hash. Networks: mainnet, testnet. Credits per call: 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. |
| transactions_data_kaspaB | Transactions Data Kaspa: get transaction details by transaction ID. Network: mainnet. Credits per call: 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 |
|---|---|
| lookup-transaction | Look up a transaction by hash and show its full details |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| supported-chains | Supported blockchains, networks, and actions for transactions-data queries |
TDQS
Scored across 6 tools
Tools are partitioned cleanly by blockchain family (UTXO, EVM, Solana, XRP, Kaspa), and the EVM tool's multi-action nature is distinct from the simpler single-action chain tools. Minor residual overlap since Solana/XRP/Kaspa tools all do essentially 'get transaction details by hash', but the chain scoping keeps selections unambiguous.
All five data tools share a strict `transactions_data_<chain>` pattern, which is highly predictable. The lone `system_info` tool deviates from the family prefix but is a clearly distinct meta/reference tool, so the break is minor.
Six tools is well-scoped for a transaction-data retrieval product, with each chain family earning its own tool. No bloat or obvious redundancy, though splitting the low-action chains (Solana/XRP/Kaspa) into separate tools is slightly granular.
The surface covers the read/lifecycle needs of fetching transaction data across major chain families, with EVM richly covered (details, internal txs, token transfers, logs). Coverage is read-only by nature, but there is no address-based transaction listing, which is a plausible gap for transaction workloads.