Skip to main content
Glama
nirholas

@three-ws/metaplex-agent-mcp

by nirholas

Prepare an agent mint for a Phantom/Solflare wallet to sign

prepare_agent_mint
Read-only

Prepare unsigned transactions for minting an on-chain AI agent. An external Solana wallet signs, pays the deploy fee, and broadcasts the signed transaction array.

Instructions

Build the exact Genesis-style mint+register flow (Metaplex Core asset + Agent Identity) for an EXTERNAL Solana wallet: Phantom, Solflare, Backpack, Ledger, anything. Needs no secret key. Returns unsigned transactions base64 in txs_base64 (already co-signed by the new asset keypair) with wallet as the fee payer: one atomic tx when it fits Solana's size limit, else create + register to sign together via signAllTransactions. The wallet signs and broadcasts, or hands the signed array to send_signed_transaction. Includes the same mainnet deploy fee as mint_onchain_agent, priced against the wallet's live $THREE balance and returned as deploy_fee_sol/deploy_fee_to before anything is signed. Broadcasts nothing itself. The blockhash expires after roughly a minute, so sign promptly and re-prepare if a wallet reports an expired transaction.

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.
walletYesThe base58 address of the wallet that will sign, pay, and own the agent.
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?

The description reveals key externally observable behaviors: no broadcast is performed, the result is co-signed by a new asset keypair, the wallet is the fee payer, blockhash expiry imposes a signing-time constraint, and fee pricing uses the wallet's live balance. This substantially enriches the tool annotations, and there is no contradiction.

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 packed with useful operational details, including transaction splitting, fee quoting, no broadcast, and expiry caveats, and yet remains easily readable. It is longer than a single sentence, but every clause serves to guide correct use and proper next steps.

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?

Given the high complexity, lack of an output schema, and a large input schema, the description covers a lot of the needed context: output fields, fee payer, fee response fields, signing limitations, and atomicity boundary. It leaves minor ambiguity around the exact type and structure of txs_base64, but takes the tool reasonably close to being self-explanatory.

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?

The schema has 100% per-parameter description coverage across all 27 parameters, so the tool description does not need to explain every field. It adds a little meaningful context by describing how wallet is used as signer and fee payer, but this is only a small supplement to the already-complete 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 description clearly states a specific verb and bounded purpose: building unsigned Genesis-style mint and registration transactions for an external Solana wallet, with no secret key required. It names the output fields and distinguishes itself from the sibling tools like mint_onchain_agent and send_signed_transaction.

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?

It explicitly declares the intended context: external wallets (Phantom, Solflare, etc.), no secret key needed, and a defined handoff to send_signed_transaction after signing. It does not explicitly contrast conditions like 'use mint_onchain_agent when you have a secret key', so the alternative recommendation remains partially implied.

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