Skip to main content
Glama
nirholas

@three-ws/metaplex-agent-mcp

by nirholas

Mint an on-chain agent into the Metaplex Agent Registry

mint_onchain_agent
Destructive

Deploy an AI agent on Solana by minting a Metaplex Core asset and registering its EIP-8004 identity, visible on metaplex.com/agents with a built-in wallet.

Instructions

Deploy an AI agent on-chain, Genesis-333 style: mints a Metaplex Core asset (data: URI metadata, verified creator, royalties, immutable metadata) AND registers its EIP-8004 Agent Identity, so it appears on metaplex.com/agents with its own built-in wallet. Runs as ONE atomic transaction when it fits Solana's 1232-byte limit, otherwise as create followed by register (how the Genesis 333 landed). Signs with the configured SOLANA_SECRET_KEY (or a per-call secret) and spends ~0.007 SOL in rent + fees, plus a flat SOL deploy fee on mainnet that funds $THREE buybacks (holding $THREE halves it, then waives it; devnet is free; see three_status). The fee rides in the same transaction as the mint, so a failed mint pays nothing. Without confirm:true it returns a full preview (both JSON documents, the paying wallet, every cost line including the fee and its recipient) and broadcasts NOTHING. For Phantom/Solflare users, use prepare_agent_mint.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAgent name. Becomes the Core asset name and the registration name.
imageNoThumbnail/avatar image URL (PNG or similar). Shown on metaplex.com/agents, wallets, and explorers.
ownerNoMint the asset to this owner instead of the signing wallet.
activeNoRegistration active flag. Default true.
secretNoPer-call signing key (base58 secret key or JSON byte array). Overrides SOLANA_SECRET_KEY.
confirmNoMust be true to broadcast. Anything else returns a spend-nothing preview.
networkNoSolana cluster. Defaults to the configured network (mainnet unless overridden).
servicesNoServices the agent offers, listed on its Metaplex agent page ({name, endpoint}).
model_urlNo3D model URL (GLB). Written as the asset metadata animation_url and as model.uri in the registration, Genesis style.
attributesNoOn-chain Attributes plugin entries (real bytes in the asset account).
collectionNoMint into this Metaplex Core collection. The signer must be the collection authority.
add_blockerNoAttach AddBlocker so no further plugins can be added. Default false.
descriptionNoWhat this agent is or does. Stored in the EIP-8004 registration document.
external_urlNoOptional external_url in the asset metadata (e.g. the agent home page).
metadata_uriNoFull override for the asset metadata URI (https or data:). Skips the built-in metadata builder.
x402_supportNoAdvertise x402 payment support in the registration document. Default false.
registrationsNoExternal registry registrations. Defaults to the chain registry entry, or the three.ws entry when threews_agent_id is set.
permanent_burnNoAttach PermanentBurnDelegate. Default false.
supported_trustNoTrust models the agent supports. Default ['reputation'] (Genesis style).
permanent_freezeNoAttach PermanentFreezeDelegate (unfrozen). Default false.
registration_uriNoFull override for the Agent Identity registration URI (https or data:). Skips the built-in registration builder.
royalty_creatorsNoRoyalty split. Percentages must sum to 100. Defaults to the signing wallet at 100%.
threews_agent_idNothree.ws agent UUID. Adds the Genesis-exact registration entry {agentId, agentRegistry: "https://three.ws"}.
verified_creatorNoAttach the VerifiedCreators plugin with the signing wallet verified. Default true (Genesis style).
immutable_metadataNoAttach the ImmutableMetadata plugin so the metadata can never change. Default true (Genesis style).
permanent_transferNoAttach PermanentTransferDelegate. Default false.
metadata_attributesNoOff-chain attributes array inside the asset metadata JSON (trait_type/value pairs).
royalty_basis_pointsNoRoyalty in basis points. Default 500 (5%), the Genesis value. 0 removes the Royalties plugin.
Behavior5/5

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

Despite annotations already marking this as non-read-only and destructive, the description adds substantial behavioral detail: atomic transaction with a create-then-register fallback (Genesis-333), signing via SOLANA_SECRET_KEY or per-call secret, ~0.007 SOL costs plus a fee funding $THREE buybacks, the fee riding in the same transaction so a failed mint pays nothing, and confirm:true gating the broadcast. It also names the wallet-user alternative.

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

Conciseness4/5

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

The description is a single dense paragraph with six sentences, each covering a different aspect (purpose, execution, signing/costs, fee safety, preview behavior, alternative). It is efficient for the tool's complexity, but bullet points or short sections would improve scannability.

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 a tool with 28 parameters and no output schema, the description covers execution strategy, costs, fee behavior, preview contents, and an alternative tool. The main gap is that it does not describe what is returned when confirm:true is set (e.g., transaction signature or mint address), which would significantly improve completeness.

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 reinforces the confirm:true preview/broadcast behavior but does not add meaning beyond the schema's own parameter descriptions, and it does not clarify interactions among the 28 parameters.

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 description clearly states it deploys an AI agent on-chain by minting a Metaplex Core asset and registering its EIP-8004 identity, with specifics like Genesis-333 style and a built-in wallet. It uses a precise verb+resource structure and distinguishes itself from siblings by describing the full mint+register flow and by explicitly sending Phantom/Solflare users to prepare_agent_mint.

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 provides an explicit alternative for Phantom/Solflare users ('use prepare_agent_mint') and implies the primary use case of direct server-side signing via SOLANA_SECRET_KEY. However, it does not explicitly differentiate from register_agent_identity or build_registration for workflows that need only part of the process, so it is not fully exhaustive.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nirholas/metaplex-agent-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server