Moonlauncher

Launch a token on pump.fun

launch_token

Prepare a pump.fun token launch with details the user has confirmed (call start_launch first and ask its questions). Creates a draft that expires in 30 minutes and returns an approveUrl. It touches no wallet and moves no funds: the user reviews the draft and signs it in their own wallet, and nothing is launched or paid until they do. Show the approveUrl to the user exactly as returned.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Token name, as the user chose it. 32 characters max.
`site`	No	Make a free token site (default true). It becomes the website link unless website is set, and goes live when the launch confirms.
`story`	No	Text for the token site: a few plain paragraphs, 2,000 characters max.
`symbol`	Yes	Ticker, e.g. RKT. 10 characters max, usually 3–6 capital letters.
`twitter`	No	The token's X (Twitter) link, https.
`website`	No	The token's own website, https. Leave it out to use the free token site.
`imageSvg`	No	A logo you drew as an SVG document, used when there's no imageUrl: square, flat, bold shapes, under 100 KB, no scripts. It becomes a 1024×1024 PNG; the user sees it on the approval page before signing.
`imageUrl`	No	https URL of a PNG, JPEG, GIF or WebP up to 5 MB. If omitted, the user uploads one on the approval page.
`siteName`	No	The site address the user chose from start_launch, e.g. rocket-coin. If it's been taken since, the next free one is used and the summary says so. Default: the ticker.
`telegram`	No	The token's Telegram link, https.
`siteAccent`	No	Token site accent color, #RRGGBB, bright enough for dark text.
`description`	No	Short description shown on pump.fun. 500 characters max.
`initialBuySol`	No	Optional first buy in SOL, as a decimal string. Max 5.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that the draft expires in 30 minutes, returns an approveUrl, touches no wallet, moves no funds, and requires the user to review and sign in their own wallet. This adds important safety and lifecycle context that the annotations alone do not convey.

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?

The description is compact and front-loaded: purpose, prerequisite, draft expiration, safety model, and final instruction are all stated without filler. Every sentence carries operational value.

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

Completeness5/5

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

For a 13-parameter creation tool with no output schema, the description covers the key behavioral facts an agent needs: prerequisite tool, draft expiration, returned approveUrl, wallet safety, and signing requirement. Parameter details are fully covered by the schema.

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 parameter meaning is already fully documented in the input schema. The description adds the process-level guidance that values should be user-confirmed and sourced from start_launch, but it does not add per-parameter syntax or edge cases beyond 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 description states a specific action and resource: preparing a pump.fun token launch by creating a draft that returns an approveUrl. It clearly differentiates this tool from the sibling start_launch by naming it as a prerequisite and explaining the draft/signing workflow.

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

Usage Guidelines5/5

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

It gives an explicit prerequisite: 'call start_launch first and ask its questions,' and it should be used only with details the user has confirmed. It also explains what must happen before the launch is finalized, so the agent knows when and how to invoke it.

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

All Moonlauncher tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?