Crypto APIs MCP Broadcast
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 using HTTP transport exposed beyond localhost. Preferred over the --auth-token CLI argument. | |
| CRYPTOAPIS_API_KEY | Yes | Your Crypto APIs API key. Required to run the server (stdio transport always requires an API key at startup). |
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 |
|---|---|
| broadcast_signed_transactionA | Broadcast locally signed transaction (Broadcast product). Submit a signed transaction hex to the network. Supported blockchains and networks vary; see credits for per-chain cost. Note: 'broadcast-signed-transaction' actions require confirmation. They return a preview with a one-time token instead of executing immediately. Credits by action (source: OpenAPI): • broadcast-signed-transaction: arbitrum 80, avalanche 90, base 60, binance-smart-chain 125, bitcoin 50, bitcoin-cash 60, dash 55, dogecoin 55, ethereum 50, ethereum-classic 65, litecoin 55, optimism 70, polygon 100, solana 150, tezos 65, tron 75, xrp 50, zcash 65 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 |
|---|---|
| broadcast-transaction | Broadcast a signed transaction to the network |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| supported-chains | Supported blockchains, networks, and actions for broadcasting signed transactions |
TDQS
Scored across 2 tools
The two tools serve completely distinct purposes: one performs an action (broadcast_signed_transaction) and the other returns static reference documentation (system_info). There is no realistic way to confuse them, so misselection is essentially impossible.
Both names use snake_case, which is consistent. However, the conventions differ semantically: one is a verb_noun action name while the other is a noun_phrase reference name, a minor deviation.
Two tools is thin for a server branded as 'Crypto APIs,' even though it is scoped to the Broadcast product. system_info is a generic helper rather than a broadcast operation, so the effective actionable surface is only a single tool.
The domain is transaction broadcasting, but there is no way to check broadcast status, query a transaction, or estimate fees—all common follow-ups after submitting a signed hex. Coverage of the core send operation is present but leaves agents at a dead end for verification.