Skip to main content
Glama
Radiant-Core

Radiant MCP Server

Official
by Radiant-Core

radiant_create_nft

Mint a Glyph NFT on Radiant using a two-transaction commit-reveal pattern. Provide NFT details and a WIF private key to receive transaction IDs and token reference.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wifNoWIF-encoded private key of the minter (transient). Provide this OR key_alias.
nameYesNFT name
imageNoImage URL or IPFS CID
key_aliasNoAlias of a key previously registered with radiant_register_key. Preferred.
attributesNoArbitrary NFT attributes as a JSON object
descriptionNoNFT description
fee_per_byteNoFee rate in photons/byte (default: 10000, the mainnet V2 min-relay floor)
change_addressNoChange address (defaults to minter address)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses the 2-transaction commit+reveal pattern, that two transaction IDs and a tokenRef are returned, and that a private key is required. The phrase 'Requires a WIF private key' is slightly more prescriptive than the schema's wif-OR-key_alias contract, so this is not perfect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, each earning its place: the operation, the transaction pattern, the return values, and the prerequisite. Information is front-loaded with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with a rich schema but no output schema or annotations, the description covers the key non-schema facts: the commit+reveal flow and the returned tokenRef. It could additionally state fee/funding implications or post-mint visibility, but the core invocation contract is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no param-level detail beyond repeating the WIF requirement; it does not clarify when to provide wif versus key_alias or how attributes/image map to the NFT, leaving that to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence is a specific verb+resource statement: 'Mint a new Glyph Non-Fungible Token (NFT) on Radiant.' This unambiguously distinguishes it from sibling operations such as radiant_create_ft, radiant_transfer_token, and radiant_burn_token.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context—use when minting a new NFT on Radiant—and states a key prerequisite ('Requires a WIF private key'). It does not explicitly name alternatives or when-not-to-use conditions, which prevents a 5, but the intended use is not left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.