Radiant MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | Bind address for the REST and SSE servers (loopback by default) | 127.0.0.1 |
| PORT | No | REST API port (also the SSE fallback port) | 3080 |
| SSE_PORT | No | SSE server port | 3090 |
| RXDC_PATH | No | Path to the rxdc RadiantScript compiler binary, used by radiant_compile_script | (auto-detected) |
| CORS_ORIGIN | No | CORS allowed origin (REST) | * |
| ELECTRUMX_SSL | No | Use TLS for a raw socket (ignored when ELECTRUMX_WSS=true) | true |
| ELECTRUMX_WSS | No | Connect over secure WebSocket (wss://host, port 443). Firewall-proof and works on mobile/corporate networks; requires Node 22+. Set false to use a raw TCP/SSL socket instead. | true |
| ELECTRUMX_HOST | No | ElectrumX server hostname | electrumx.radiantcore.org |
| ELECTRUMX_PORT | No | ElectrumX server port | 443 (wss) / 50012 (raw) |
| RADIANT_NETWORK | No | Network: mainnet or testnet | mainnet |
| RADIANT_API_TOKEN | No | Bearer token required for key-handling REST endpoints. When unset, those endpoints are loopback-only | (unset) |
| RADIANT_TEST_MODE | No | When set (and not 0/false), blocks real transaction broadcasts | (unset) |
| RADIANT_KEYRING_FILE | No | Path to the server-side keyring (must be 0600 on POSIX) | ~/.radiant-mcp/keyring.json |
| RADIANT_RESPONSE_FORMAT | No | Value formatting in responses: satoshis, rxd, or both (satoshis ~halves token cost on balance/UTXO-heavy calls) | both |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| radiant_get_chain_infoA | Get current Radiant blockchain status: latest block height, tip hash, and network parameters |
| radiant_get_balanceA | Get RXD balance for a Radiant address (confirmed and unconfirmed, in both satoshis and RXD) |
| radiant_get_utxosA | List unspent transaction outputs (UTXOs) for a Radiant address |
| radiant_get_historyA | Get transaction history for a Radiant address. Returns ALL entries (no pagination at this layer) — for very active addresses, expect a large response. |
| radiant_get_transactionA | Get detailed information about a transaction by its txid |
| radiant_get_block_headerB | Get block header information by block height |
| radiant_estimate_feeA | Estimate transaction fee for confirmation within N blocks. Returns both the ElectrumX estimate (RXD/kB) and the network's min-relay policy floor (photons/byte) — pay max(estimate, floor). |
| radiant_broadcast_transactionC | Broadcast a signed raw transaction to the Radiant network |
| radiant_get_tokenB | Get Glyph token information by token reference (txid:vout or txid_vout format) |
| radiant_list_tokensA | List Glyph tokens held by a Radiant address. PAGINATION CAVEAT: this uses simple limit-based truncation; if the holder owns more than |
| radiant_get_token_balanceA | Get balance of a specific Glyph token for an address |
| radiant_search_tokensA | Search for Glyph tokens by name or ticker symbol. Returns up to |
| radiant_get_token_metadataB | Get full CBOR metadata for a Glyph token (name, description, image, attributes, etc.) |
| radiant_get_token_historyA | Get transaction history for a specific Glyph token. PAGINATION CAVEAT: offset-based — entries shift if new transactions land between calls, so paging the same series may yield duplicates or gaps. For stable enumeration, fetch in a single call when count is bounded. |
| radiant_get_tokens_by_typeA | Get tokens filtered by type (FT, NFT, etc.). PAGINATION CAVEAT: offset-based — entries shift if new tokens are minted between calls, so consecutive pages may double-count or miss entries. |
| radiant_validate_protocolsA | Validate a Glyph protocol combination (check if protocol IDs can be used together) |
| radiant_parse_glyph_envelopeB | Parse a Glyph envelope from raw script hex (decode token metadata from a transaction output) |
| radiant_get_dmint_contractsB | List active dMint (decentralized mining) contracts — mineable tokens with PoW distribution |
| radiant_get_dmint_contractA | Get details for a specific dMint contract (difficulty, reward, algorithm, supply) |
| radiant_get_dmint_by_algorithmA | Get dMint contracts filtered by mining algorithm |
| radiant_get_most_profitable_dmintA | Get dMint contracts sorted by estimated profitability (reward/difficulty ratio) |
| radiant_resolve_wave_nameA | Resolve a WAVE name to its zone records (address, avatar, description, DNS records, etc.). WAVE is Radiant's on-chain naming system. |
| radiant_check_wave_availableA | Check if a WAVE name is available for registration |
| radiant_wave_reverse_lookupB | Find WAVE names owned by a Radiant address |
| radiant_wave_subdomainsA | List subdomains (child names) of a WAVE name. PAGINATION CAVEAT: offset-based — entries shift if new subdomains are registered between calls. |
| radiant_wave_statsB | Get WAVE naming system statistics (total names, cache size, etc.) |
| radiant_get_swap_ordersA | Get open swap orders for a trading pair (on-chain DEX orderbook). PAGINATION CAVEAT: offset-based — orders move in and out of the book as trades execute, so paging may double-count or miss orders. Re-fetch from offset=0 for a fresh snapshot. |
| radiant_get_protocol_infoA | Get information about all Glyph protocol types (IDs, names, descriptions, valid combinations) |
| radiant_validate_addressA | Validate a Radiant address and show its type (P2PKH or P2SH) |
| radiant_register_keyA | Store a WIF private key in the server-side keyring under an alias. Subsequent signing tools can reference the key by |
| radiant_list_keysA | List aliases registered in the server-side keyring. WIFs are never returned — only the alias, derived address, and the time the entry was added. |
| radiant_remove_keyA | Remove an alias from the server-side keyring. Returns success even if the alias didn't exist; check the |
| radiant_create_walletA | Generate a new Radiant wallet. Supports two modes: (1) random key (fast, no mnemonic) or (2) BIP39 mnemonic with BIP32 HD derivation (12-24 words, recoverable). WARNING: Store the WIF/mnemonic securely. |
| radiant_restore_walletA | Restore a Radiant wallet from a BIP39 mnemonic phrase. Validates the mnemonic checksum and derives the private key via BIP32 HD derivation. |
| radiant_get_swap_historyC | Get trade history for a token on the on-chain DEX |
| radiant_connection_healthB | Check ElectrumX connection health: latency, connection status, and server info |
| radiant_reconnectA | Force a fresh ElectrumX reconnect. Use this when the auto-reconnect logic has given up (after 5 backoff attempts) and the session is wedged. Tears down the existing socket, clears the backoff counter, and re-handshakes. |
| radiant_create_inference_proofA | Create a blake3 inference proof commitment: hash(modelHash || inputHash || output). Used to record AI inference results on-chain via the InferenceProof contract. |
| radiant_verify_inference_proofA | Verify an inference proof commitment off-chain. Checks that blake3(modelHash || inputHash || output) matches the expected commitment. |
| radiant_build_agent_profileA | Build an AI agent identity profile with blake3 commitment, suitable for on-chain registration via the AgentIdentity contract and WAVE naming system. |
| radiant_resolve_agent_identityB | Resolve an AI agent's identity from its WAVE name. Returns parsed capabilities, pricing, and API endpoint. |
| radiant_check_token_accessA | Check if an address holds sufficient Glyph tokens to access a gated service (TokenGatedService contract pattern). |
| radiant_open_channelC | Create initial state for a micropayment channel between two agents (MicropaymentChannel contract pattern). |
| radiant_update_channelC | Update a micropayment channel state: transfer photons from payer (agentA) to payee (agentB). |
| radiant_build_data_assetC | Build Glyph NFT metadata for a data marketplace asset (DataMarketplace contract pattern). Returns CBOR-ready metadata structure. |
| radiant_search_data_assetsA | Search the data marketplace for datasets, models, and other data assets (NFTs with DAT protocol). |
| radiant_decode_scriptA | Decode raw script hex into human-readable opcodes. Works offline — no ElectrumX connection required. Useful for debugging transactions and smart contracts. |
| radiant_compile_scriptA | Compile RadiantScript (.cash/.rxd) source code into a deployment artifact. Returns ABI, ASM bytecode, and hex. Works offline — requires the rxdc compiler binary (set RXDC_PATH env var or ensure RadiantScript repo is a sibling directory). |
| radiant_send_rxdA | Send RXD (photons) to an address. Fetches UTXOs, selects coins, builds, signs, and broadcasts the transaction. Requires a WIF private key for the sender address. |
| radiant_create_ftA | Mint a new Glyph Fungible Token (FT) on Radiant. Uses the 2-transaction commit+reveal pattern. Returns both transaction IDs and the token reference (tokenRef) for future transfers. Requires a WIF private key. |
| radiant_create_nftA | Mint a new Glyph Non-Fungible Token (NFT) on Radiant. Uses the 2-transaction commit+reveal pattern. Returns both transaction IDs and the token reference (tokenRef). Requires a WIF private key. |
| radiant_transfer_tokenA | Transfer a Glyph token (FT or NFT) to another address. The token UTXO must be at the sender's address. For FTs provide the amount in base units; for NFTs use amount=1. Requires a WIF private key. |
| radiant_get_token_utxosA | Discover all Glyph tokens held by an address. Returns each token's UTXO reference (tokenRef), txid, vout, height, and satoshi value. Agents can use this to discover what they hold without prior knowledge of token references, then pass tokenRef directly to radiant_transfer_token or radiant_burn_token. |
| radiant_build_transactionA | Build and sign a transaction in dry-run mode — returns the raw hex, fee, and size WITHOUT broadcasting. Critical for high-value operations: inspect the transaction before committing. Set dry_run=false to also broadcast after building. |
| radiant_estimate_tx_feeA | Estimate transaction fee in satoshis given input/output counts. Pure arithmetic — no network call. Use this to budget before building a transaction. Supports OP_RETURN outputs (e.g., for token minting). |
| radiant_send_batchA | Send RXD to multiple recipients in a single transaction. Much cheaper than N separate transactions — inputs are selected once and change is returned in a single output. Ideal for agent fan-out payments (e.g., paying multiple service providers). |
| radiant_watch_addressA | Subscribe to real-time payment notifications for a Radiant address via ElectrumX scripthash subscription. Returns the current status hash and subscribes to future changes. Notifications arrive as ElectrumX push events (blockchain.scripthash.subscribe). Use this instead of polling for payment detection. |
| radiant_derive_addressA | Derive a Radiant address from a BIP39 mnemonic and BIP32 derivation path. Lets agents manage per-task sub-wallets from a single root key. Returns the address, public key, and WIF for the derived key. Use different account/index values to generate isolated sub-wallets. |
| radiant_burn_tokenA | Permanently burn (destroy) a Glyph token using protocol 6 (explicit burn). Spends the token UTXO into an OP_FALSE OP_RETURN output with a Glyph burn envelope. Use this to retire tokens cleanly — the burn is recorded on-chain and verifiable. Requires a WIF private key. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| chain-overview | Radiant blockchain overview: parameters, features, and ecosystem tools |
| opcode-reference | Complete Radiant opcode reference table including V2 opcodes (BLAKE3, K12, shifts) |
| protocol-reference | Glyph protocol IDs, dMint algorithm IDs, and DAA mode reference |
| network-params | Radiant network parameters (mainnet and testnet) |
| sdk-quickstart | Quick start guide for building on Radiant with radiantjs |
| knowledge-base | Comprehensive Radiant blockchain AI knowledge base — opcodes, token protocols, APIs, SDK patterns, and network parameters in a single document |
| chain-status | Live chain status: current height, tip hash, sync state |
| dmint-active | Currently active dMint (decentralized mining) contracts |
| network-fees | Current fee estimates for various confirmation targets |
| tokens-popular | Popular Glyph tokens: well-known fungible tokens and NFT collections on the Radiant network |
TDQS
Scored across 59 tools
Most tools name both the resource and action (get_balance, transfer_token, resolve_wave_name), so the primary purpose is easy to pick. The main ambiguities are fee estimation (estimate_fee vs estimate_tx_fee) and the build/send/broadcast transaction cluster, but the descriptions draw enough of a boundary that an agent can choose correctly.
The surface consistently uses a radiant_ snake_case prefix with verb_noun names. Minor deviations such as connection_health (no verb), reconnect (bare verb), and a mix of get/list/search/resolve for read operations keep it from being perfectly uniform.
At 59 tools, this server is above the 50+ extreme threshold and far past the 25+ 'too many' boundary. It bundles multiple distinct domains (core chain, Glyph tokens, WAVE, DEX, AI agent contracts, wallet/keyring) into one surface and would be far more navigable split into focused MCP servers.
Core RXD and Glyph token lifecycles are well covered: create, transfer, burn, balance, history, and UTXO discovery all exist. However, several subdomains are half-finished: WAVE has availability/resolution but no registration or renewal, the DEX has orders/history but no create/cancel/trade, and channels have open/update but no close/settle.