Create, launch and rug-check Solana SPL tokens over x402. Non-custodial, no keys handed over.
Scored across 4 tools
Each tool targets a clearly distinct stage: validation/planning, transaction construction, network/reference data, and post-launch audit. Descriptions make the boundaries explicit, and the free plan-first workflow naturally separates sol_launch_plan from sol_build_launch_tx.
All tools share the sol_ prefix, which is good, but the suffix conventions are mixed: build_launch_tx is verb-led, while launch_plan, networks, and token_audit are noun-led. The names are still readable and domain-specific, but the pattern is not uniform.
Four tools is well-scoped for a focused Solana token launch service. Each tool covers a necessary lifecycle step without redundant or filler operations.
The surface covers pre-launch validation, transaction construction, network/rent reference data, and post-launch authority auditing. Since the service is explicitly non-custodial, the lack of a signing/submission tool is appropriate rather than a gap.
$0.02 per call. Returns a complete, unsigned Solana transaction that creates an SPL mint, writes Metaplex metadata on-chain, mints the supply to the payer and revokes the mint authority in the same transaction. NON-CUSTODIAL: the service never sees a private key — the caller signs with their own wallet. Requires a payer public key. Test on devnet first.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | No | https:// or ipfs:// URL of the metadata JSON | |
| name | Yes | Token name, 1-32 characters | |
| payer | Yes | Base58 PUBLIC key of the wallet that pays rent and signs. A private key is never accepted. | |
| supply | Yes | Total supply in UI units as an exact integer string | |
| symbol | Yes | Token symbol, 1-10 characters, uppercase letters and digits | |
| network | No | mainnet-beta (default) or devnet — devnet costs nothing, try it first | |
| decimals | No | 0-9, default 9 | |
| mint_pubkey | No | Supply your own mint public key if you would rather hold that keypair yourself | |
| freeze_authority | No | default none | |
| revoke_mint_authority | No | default true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it discloses a lot: per-call price ($0.02), the exact set of instructions executed atomically (mint, metadata, mint supply, revoke authority), and the non-custodial key handling. It still omits failure modes, idempotency, and rate/throughput limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the price and the returned artifact, then the transaction contents, then the non-custodial constraint and the devnet recommendation. Every sentence earns its place, though the single long compound sentence listing the four instructions is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter transaction-builder with no annotations and no output schema, the description covers what is returned (unsigned tx), what it contains, and the security model. Gaps remain around mainnet consequences and error behaviour, but the caller has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter including payer, network, decimals and revoke_mint_authority. The description only restates the payer requirement ('Requires a payer public key'), adding no syntax or format detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and artifact: returns an unsigned Solana transaction that creates an SPL mint, writes Metaplex metadata, mints supply and revokes mint authority. This is clearly distinguishable from sibling sol_launch_plan (planning) and sol_token_audit (inspection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives useful conditions: requires a payer public key and 'Test on devnet first', and the non-custodial framing tells the caller they must sign. It does not, however, explicitly route the agent between this and sol_launch_plan, nor state when not to call it (e.g. mainnet without a prior plan).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Validate a Solana token launch before building it: normalises name/symbol/supply/decimals, applies a typed allow/review/deny gate, states the authority policy (mint revoked, no freeze authority by default) and returns the exact on-chain cost in SOL and USD. Use this first — it costs nothing and catches the mistakes that would otherwise be signed.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | No | https:// or ipfs:// URL of the off-chain metadata JSON (logo and description) | |
| name | Yes | Token name, 1-32 characters | |
| supply | Yes | Total supply in UI units as an exact integer string, e.g. "1000000000" | |
| symbol | Yes | Token symbol, 1-10 characters, uppercase letters and digits | |
| network | No | mainnet-beta (default) or devnet | |
| decimals | No | 0-9, default 9 | |
| freeze_authority | No | default none — we never set a freeze authority unless asked | |
| revoke_mint_authority | No | default true — fixed supply, the trust signal buyers screen for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses normalisation, a typed allow/review/deny gate, authority defaults, and that the response includes exact on-chain cost in SOL and USD. It stops short of explicitly stating side effects, rate limits, or how review/deny outcomes are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the text is compact. There is minor redundancy between 'Free.' and 'it costs nothing', but otherwise every sentence contributes useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an eight-parameter planning tool with no output schema, the description gives enough to select and invoke it correctly: purpose, sequencing, validation gate, authority defaults, and cost output. More detail on the exact response shape and gate outcomes would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all eight parameters thoroughly, including defaults and enums. The description reinforces a few defaults such as mint revocation and freeze authority, but adds little semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: validate a Solana token launch. It distinguishes itself from the build step with 'before building it', so an agent can separate planning from transaction construction without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this first' and explains why: it is free and catches mistakes before signing. It implies the build tool should come later, but does not explicitly name the alternative sibling tool or state when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Solana networks this API builds for (mainnet-beta, devnet), the on-chain programs used, and the exact rent + fee table for a token launch in lamports. Free — no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool is free, lists what it returns, and specifies that fees are in lamports, but it does not explicitly state that the operation is read-only, whether authentication is needed, or what rate limits may apply. For a zero-parameter informational tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the primary resource and expands into the specific data returned. The 'Free — no payment required' clause is short and adds useful context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, zero parameters, absence of annotations, and lack of an output schema, the description provides enough detail about what is returned: supported networks, on-chain programs, and exact rent + fee figures in lamports. Nothing essential for an agent to call this informational tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. Per the baseline for parameterless tools, a 4 is appropriate; the description does not need additional parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'List,' and names the exact resource: Solana networks supported by the API, on-chain programs, and the rent + fee table in lamports. It clearly distinguishes itself from generic chain tools by focusing on Solana and launch costs, though it does not explicitly contrast itself with siblings such as chain_networks or sol_launch_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: an agent can infer this is the tool for discovering supported Solana networks and launch cost details. The description adds that it is free with no payment required, which is helpful context, but it does not explicitly state when to use this tool versus alternatives like chain_networks or sol_launch_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$0.003 per call. Read a Solana SPL mint's real authority state: who can mint more supply, who can freeze holders, whether the metadata is immutable, plus on-chain name/symbol/logo and a verdict with machine-readable flags. Reads the chain directly — no opinion, no blacklist.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Base58 SPL token mint address | |
| network | No | mainnet-beta (default) or devnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does meaningful work: it makes the read-only nature explicit ('Read', 'Reads the chain directly'), discloses per-call cost ($0.003), and sets expectations about determinism ('no opinion, no blacklist'). It stops short of covering failure behavior (invalid/non-existent mint addresses) or latency, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler, and the authoritative scope statement comes right after the price. Leading with the price is arguably a detour ahead of the purpose, but it's a legitimate decision factor for a paid tool and costs only a few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return value, and it does: authority holders, metadata immutability, token identity fields, and a machine-readable verdict with flags. For a 2-parameter read tool this covers what an agent needs, with only error/edge-case behavior left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the mint address and the mainnet-beta/devnet enum both documented in the schema, so the baseline is 3. The description adds no parameter-level detail beyond the schema (e.g., no guidance on address validation or devnet caveats), so it doesn't exceed that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It gives a specific verb and resource ('Read a Solana SPL mint's real authority state') and enumerates the exact facts returned: mint authority, freeze authority, metadata immutability, name/symbol/logo, and a flagged verdict. This is clearly distinguishable from siblings like chain_token and sol_launch_plan without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Reads the chain directly — no opinion, no blacklist' signals what kind of audit this is versus opinionated rug-check services, and the price hints it's a pay-per-call utility. However, it never says when to prefer this over sibling chain_token, nor any prerequisites or exclusions, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
sol_build_launch_txsol_launch_plansol_networkssol_token_auditBatch send SOL or any SPL token to 1000+ wallets via x402. AI agent payments on Solana.
Pay-per-call Solana token risk intelligence: 8 tools via x402. From $0.005 USDC, no API key.
Solana token rug check before you buy: SAFE/CAUTION/DANGER from chain state, paid per call via x402.
Solana token rug/honeypot checks: free quick check; full score paid via x402 (USDC Solana/Base).
Add one secure layer between your agents and this server.
