Skip to main content
Glama
Radiant-Core

Radiant MCP Server

Official
by Radiant-Core

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
HOSTNoBind address for the REST and SSE servers (loopback by default)127.0.0.1
PORTNoREST API port (also the SSE fallback port)3080
SSE_PORTNoSSE server port3090
RXDC_PATHNoPath to the rxdc RadiantScript compiler binary, used by radiant_compile_script(auto-detected)
CORS_ORIGINNoCORS allowed origin (REST)*
ELECTRUMX_SSLNoUse TLS for a raw socket (ignored when ELECTRUMX_WSS=true)true
ELECTRUMX_WSSNoConnect 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_HOSTNoElectrumX server hostnameelectrumx.radiantcore.org
ELECTRUMX_PORTNoElectrumX server port443 (wss) / 50012 (raw)
RADIANT_NETWORKNoNetwork: mainnet or testnetmainnet
RADIANT_API_TOKENNoBearer token required for key-handling REST endpoints. When unset, those endpoints are loopback-only(unset)
RADIANT_TEST_MODENoWhen set (and not 0/false), blocks real transaction broadcasts(unset)
RADIANT_KEYRING_FILENoPath to the server-side keyring (must be 0600 on POSIX)~/.radiant-mcp/keyring.json
RADIANT_RESPONSE_FORMATNoValue 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

CapabilityDetails
tools
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 limit tokens, the cut-off is non-deterministic. Set limit high enough to cover the holdings, or fetch in a single call when count is bounded.

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 limit matches in a single response (no offset/cursor support upstream — set limit to cover the result set you care about).

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 key_alias instead of resending the WIF on every call — keeps the WIF out of the MCP transport, agent transcripts, and client logs. The keyring lives at RADIANT_KEYRING_FILE (default ~/.radiant-mcp/keyring.json) and is required to be 0600 mode on POSIX.

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 removed field to tell.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
chain-overviewRadiant blockchain overview: parameters, features, and ecosystem tools
opcode-referenceComplete Radiant opcode reference table including V2 opcodes (BLAKE3, K12, shifts)
protocol-referenceGlyph protocol IDs, dMint algorithm IDs, and DAA mode reference
network-paramsRadiant network parameters (mainnet and testnet)
sdk-quickstartQuick start guide for building on Radiant with radiantjs
knowledge-baseComprehensive Radiant blockchain AI knowledge base — opcodes, token protocols, APIs, SDK patterns, and network parameters in a single document
chain-statusLive chain status: current height, tip hash, sync state
dmint-activeCurrently active dMint (decentralized mining) contracts
network-feesCurrent fee estimates for various confirmation targets
tokens-popularPopular Glyph tokens: well-known fungible tokens and NFT collections on the Radiant network

TDQS

B3.3/5.0

Scored across 59 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count1/5

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.

Completeness3/5

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.

Maintenance

ActivityInactive
ResponsivenessUnresponsive