Highwire

Build a coin launch (unsigned)

build_launch

Build unsigned transactions to launch a coin on higher.fun: pay the on-chain launch fee, add an optional first buy, and return a sign_url for the user's wallet to approve.

Instructions

Build the unsigned transactions that launch a coin on higher.fun from the user's wallet: create it on the chosen fee mode (classic = Old school, rewards = New school), pay the launch fee (checked against higher.fun's on-chain fee wallet and cap), an optional first buy, and for New school an optional creator lock. Needs metadata_uri: higher.fun's image and metadata upload needs a wallet sign-in Highwire can't do, so without it the tool returns the metadata JSON to host first. Reuse the same idempotency_key on retries: it keeps the same mint, so the coin (and its fee) can only happen once, on any server instance. Set confirm_launch to true only after the user approved the launch, its cost and its fee mode. Returns the transactions and a sign_url for the user's wallet.

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": {
      "wallet": "<wallet>",
      "name": "<name>",
      "ticker": "<ticker>",
      "fee_mode": "<fee_mode>",
      "idempotency_key": "<idempotency_key>",
      "confirm_launch": "<confirm_launch>"
    },
    "name": "build_launch"
  }
}

Input Schema

Name	Required	Description
`x`	No	https://x.com/... link
`name`	Yes	Coin name, up to 32 characters.
`ticker`	Yes	Ticker, 1-10 letters or digits, without the $.
`wallet`	Yes	The creator's wallet, which signs and pays (public key only).
`website`	No
`fee_mode`	Yes	classic: Cheapest. On the curve, no trading fee to the creator or higher.fun, only Raydium's 0.25%. rewards: Creator rewards. The creator earns 0.25% of every trade, plus pool fees after graduation.
`telegram`	No	https://t.me/... link
`image_url`	No	https URL of the coin's image, put in the prepared metadata.
`description`	No
`dev_buy_sol`	No	SOL for the creator's first buy, in the same transaction. At most 10.
`metadata_uri`	No	https URL of the coin's hosted metadata JSON.
`confirm_launch`	Yes	Set to true only after the user approved this launch.
`idempotency_key`	Yes	A unique, unguessable key for this coin (a random UUID). Reuse it on retries: it fixes the coin's mint address.
`creator_lock_pct`	No	rewards only: lock this % of supply for the creator (7-day cliff after graduation, then 30 days linear).
`max_slippage_bps`	No	Slippage for the first buy, in bps.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing that the launch fee is verified against higher.fun's on-chain fee wallet and cap, that the metadata upload needs a wallet sign-in Highwire cannot perform (with a documented fallback), that the idempotency key pins the mint across server instances, and that the response contains transactions plus a sign_url. The key-based dedupe is consistent with idempotentHint=false, since it only holds for identical keys, not for arbitrary repeat calls. Minor gap: nothing about failure/partial states or expiration of the returned unsigned transactions.

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?

Dense but front-loaded: the core action comes first, then prerequisites, then retry safety, then the confirmation gate, then the return value. A couple of sentences are run-ons carrying two ideas at once, but no sentence is filler.

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 15-parameter mutation tool with no output schema, the description covers the critical unknowns: the fee cap check, the metadata prerequisite and fallback, idempotency, the confirmation gate, and a one-line statement of what is returned. What is missing is failure behavior (e.g. what happens if metadata_uri is present but invalid, or if the fee cap is exceeded).

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 already 87%, so baseline is 3; the description adds real meaning on top by mapping the enum values to product language ('classic = Old school, rewards = New school'), explaining the metadata_uri dependency and its fallback, and stating the approval semantics behind confirm_launch and the mint-pinning role of idempotency_key. It does not add anything for dev_buy_sol, creator_lock_pct, or max_slippage_bps beyond what the schema already says.

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?

Opens with a specific verb and resource: 'Build the unsigned transactions that launch a coin on higher.fun from the user's wallet,' and immediately enumerates the sub-actions (create on fee mode, pay launch fee, optional first buy, optional creator lock). This clearly separates it from build_trade and build_claim_creator_fees, which are the other 'build unsigned tx' siblings.

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?

Gives concrete gating conditions: set confirm_launch only after the user approved the launch, its cost and its fee mode; supply metadata_uri or the tool falls back to returning metadata JSON to host; reuse idempotency_key on retries. It stops short of naming alternatives explicitly (e.g. quote_trade or check_ticker as prerequisites), so it is clear context rather than full when/when-not routing.

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