Skip to main content
Glama

OpenFinance — Easy Trading: Crypto, Stocks, Perps & Prediction Markets

openfinance-launchpad

OpenFinance Launchpad — Solana token launchpad on a dynamic bonding curve. Launch a new SPL token in a single tx, trade it on a bonding curve, and graduate to a DAMM v2 AMM once the curve fills. Single-tool dispatch on action.

ROUTING: • To LAUNCH a new token: use action='launch_token'. • To TRADE a DBC token PRE-graduation (still on the bonding curve): use action='buy' / 'sell' here. • To TRADE a DBC token POST-graduation: it's a DAMM v2 pool now — route through Jupiter (onchain_jupiter_order + onchain_jupiter_execute). Calling 'buy'/'sell' here on a graduated pool returns alreadyGraduated: true. • The PoolConfig PDA (env METEORA_DBC_CONFIG) controls total supply, decimals, fee tier, curve shape, and graduation threshold — these are NOT per-launch params.

ACTIONS: launch_token — { name, symbol, image (base64), description?, website?, twitter?, telegram?, configAddress?, initialBuySol? }: pins image + Metaplex JSON metadata to IPFS via Pinata, generates a fresh mint keypair, calls DBC createPool. Set initialBuySol to also buy the new token in the SAME tx (creator "dev buy" — atomic, no snipe risk; creator needs ~0.035 SOL launch cost + the buy amount). Returns { mintAddress, poolAddress, metadataUri, imageUri, signature, initialBuySol?, initialBuyTokens? }. DESTRUCTIVE — creates a permanent SPL mint on mainnet. Always confirm with the user before calling. WEBSITE NUDGE — website is optional but recommended: tokens that ship with a website tend to bond/graduate at a higher rate (more credible to traders). Before launching, if the user hasn't given a website, suggest adding one — e.g. "Want to add a website? Tokens with one tend to graduate more often. It's optional — I can launch without it." Launch fine without it if they decline; never block the launch on it.

list_tokens — { limit?, offset?, sort?, creator? } (PUBLIC — no auth): paginated explore feed of every token launched under the partner config. sort 'newest' (default, by on-chain activation time) or 'mcap' (market cap desc). limit ≤100 (default 30). Pass creator (a Solana wallet) to filter to one launcher's tokens — use this for "show me my launched tokens" / "what has wallet X launched". Returns { tokens: [{ pool, mint, name, symbol, image, description, website, twitter, telegram, externalUrl, metadataUri, creator, createdAt, curveProgress (0-1 bonding fill), graduated, priceSol, marketCapSol, marketCapUsd }], total, limit, offset, solUsd }. website/twitter/telegram fall back to Codex's own indexed data when our own launch record doesn't have them (e.g. older launches) — our stored value always wins when present.

get_pool_state — { poolAddress }: returns { baseMint, quoteMint, graduated, quoteTokenCurveProgress (0-1), baseTokenCurveProgress (0-1), migrationQuoteThreshold }. Call before any buy/sell to check graduation status and mcap progress.

quote_buy — { poolAddress, quoteAmount, slippageBps? }: returns { amountIn, amountOut, minimumAmountOut, priceImpactBps, alreadyGraduated }. quoteAmount is in the quote token's smallest unit (lamports for wSOL, atomic for USDC). quote_sell — { poolAddress, baseAmount, slippageBps? }: mirror. baseAmount is in the new token's smallest unit.

buy — { poolAddress, quoteAmount, slippageBps? }: signs + broadcasts a buy. Returns { signature, amountIn, minimumAmountOut, amountOutQuoted }. sell — { poolAddress, baseAmount, slippageBps? }: mirror.

migrate — { poolAddress }: anyone can call once quoteTokenCurveProgress >= 1. Migrates remaining reserves into a DAMM v2 pool, mints two LP-position NFTs. Returns { signature, firstPositionNft, secondPositionNft }.

get_pool_fees — { poolAddress }: read-only claimed/unclaimed/total fee breakdown for a pool, split into creator and partner. Use to show a launcher how much they can withdraw. get_creator_fees — {}: the caller's accumulated creator fees across EVERY token they launched. Returns { creator, pools: [{ pool, creatorBaseFee, creatorQuoteFee, hasUnclaimedCreatorFees }] }. claim_creator_fees — { poolAddress }: withdraw the caller's creator trading-fee share from one of their pools to their own Privy wallet. Returns { pool, signature, receiver }. Show the unclaimed amount (from get_creator_fees / get_pool_fees) and confirm before calling.

⚠️ SAFETY — launch_token is irreversible. Before calling, show the user: name, symbol, image preview link (the IPFS gateway URL after upload), the PoolConfig PDA being used, total cost in SOL (~0.035 SOL), and require explicit confirmation. Solana wallet must be delegated to the app (412 on first call otherwise).

⚠️ SAFETY — buy/sell are real swaps. Always show the quote (input/output, slippage, price impact) before submitting and require user confirmation, same shape as Jupiter execute.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "openfinance-launchpad"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoToken name (≤32 chars).
sortNolist_tokens order: newest (default) or mcap.
imageNoBase64-encoded PNG/JPG/SVG image (with or without data: prefix). Required for launch_token.
limitNolist_tokens page size (≤100, default 30).
actionYesWhich launchpad action to perform — see tool description.
offsetNolist_tokens page offset (default 0).
symbolNoToken ticker (≤10 chars).
creatorNolist_tokens: filter to one creator wallet (Solana address).
twitterNo
websiteNoOptional but recommended — tokens with a website tend to bond/graduate at a higher rate. If the user omits it, suggest adding one before launching; don't block the launch if they decline.
telegramNo
baseAmountNoBase-token amount in smallest unit (for sell / quote_sell).
descriptionNo
poolAddressNoDBC pool address. Required for every action except launch_token / list_tokens.
quoteAmountNoQuote-token amount in smallest unit (for buy / quote_buy).
slippageBpsNoDefault 100 (1%).
configAddressNoOverride default METEORA_DBC_CONFIG.
initialBuySolNoOptional creator "dev buy" — SOL to spend buying the new token atomically in the launch tx. Creator needs launch cost (~0.035 SOL) + this amount. Omit for no buy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discharges it: it flags launch_token as destructive/permanent and irreversible, buy/sell as real swaps requiring confirmation, the ~0.035 SOL cost, atomic dev-buy behavior, the alreadyGraduated failure mode, the 412 wallet-delegation requirement, and every action's return shape.

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?

Front-loaded routing followed by per-action contracts is an effective structure for an 11-action dispatcher, and nearly every line is actionable. It loses a point for redundancy — the website nudge and the confirmation requirement are each repeated across sections and the schema, adding length without new information.

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 an 18-param, 11-action tool with no annotations and no output schema, the description supplies per-action parameters, per-action return values, routing rules, auth and cost constraints, and safety gates. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 83%, so the baseline is 3, but the description adds value beyond it: it binds params to actions ('Required for every action except launch_token / list_tokens' for poolAddress), explains that quoteAmount/baseAmount are in smallest units, and clarifies creator-filter intent. Some param prose (website nudge, initialBuySol) duplicates the schema, capping this below a 5.

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?

States a specific product (Solana token launchpad on a dynamic bonding curve) and enumerates the concrete verbs it performs: launch, buy/sell, graduate/migrate, fee ops. It explicitly distinguishes itself from siblings by naming Jupiter for post-graduation trades, so an agent can tell which tool to pick without opening a schema.

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?

The ROUTING block gives explicit when-to-use per action, and critically an exclusion rule: 'To TRADE a DBC token POST-graduation: route through Jupiter... Calling buy/sell here on a graduated pool returns alreadyGraduated: true.' It also names the config PDA as a shared, non-per-launch input, removing the main ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.