aeX402 — Cross-Chain DeFi MCP: LINQ, AMM, Bridge, AI

launch_token

Launch a memecoin on the aeX402 launchpad on Robinhood Chain (EVM 4663) for a FIXED rising bonding curve (1B supply, starts 0.000008 USDG and climbs ~3.6x, graduates at 10,000 USDG raised, quoted in USDG; the pool then opens just above the last sale price). You supply only identity — name + ticker (+ optional description/image/links). DEFAULT (custodial): the aeX402 backend SIGNS + SUBMITS the createVPool tx for you, so a claude.ai user with NO WALLET can launch in one call; returns {ok,status,txHash,vpId}. Optionally pass creator (a 0x address) to record as the coin owner. Pass build:true instead to get an UNSIGNED tx {to,value,data} to submit yourself (non-custodial — that requires creator and makes you the on-chain creator). A custodial call SIMULATES first, so a failure burns no gas: status "gated" means createVPool reverts in simulation (cause not determined — likeliest are the ticker still being claimed by a bonding coin or this vpId being taken; see detail/revertData), and status "unreachable" means the chain could not be reached, which is retryable. The launchpad is NOT chain-gated: createVPool simulates clean from an arbitrary sender (measured 2026-09-25).

Input Schema

Name	Required	Description
`pad`	No	OPTIONAL aeX402 launchpad slug the coin is launched on. Its vpId then starts with that pad's tag, so the pad lists it. Applies on BOTH the custodial (default) and build:true paths
`name`	Yes	Token name, 1..32 bytes (e.g. "Fork Meme")
`build`	No	If true, return an UNSIGNED tx to submit yourself (non-custodial) instead of the backend launching for you. Default false.
`image`	No	Image URL (https:// or ipfs:// only) — off-chain metadata
`links`	No	Up to 3 links (https:// or ipfs:// only) — off-chain metadata
`ticker`	Yes	Ticker / symbol, 1..16 bytes (e.g. "FMEME")
`creator`	No	OPTIONAL 0x EVM address recorded as the coin owner (and seeds the vpId). REQUIRED only when build:true (then it is the self-signing on-chain creator).
`description`	No	Short description (<=256 chars) — off-chain metadata

Output Schema

Name	Required	Description
`ok`	No	Custodial mode: whether the launch was submitted
`to`	No	build mode: aeX402 diamond address
`data`	No	build mode: createVPool calldata to submit
`note`	No
`vpId`	No	Deterministic keccak256(creator-or-launcher ++ name ++ ticker)
`status`	No	submitted \| gated \| custodial-disabled \| exists \| rate-limited \| insufficient-gas \| submit-failed
`txHash`	No	Custodial mode: the createVPool tx hash
`metadata`	No	Off-chain metadata (stored server-side in custodial mode)
`signMetadata`	No	build mode: how the creator signs `metadata` so nobody can claim the coin page first (C103)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedOutput schema / properties / signMetadata

Added value: +{
+  "description": "build mode: how the creator signs `metadata` so nobody can claim the coin page first (C103)",
+  "properties": {
+    "how": {
+      "description": "the POST body and the retry rule",
+      "type": "string"
+    },
+    "message": {
+      "description": "the exact text to personal_sign, with {ts} replaced by the current time in ms",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / pad / description

Previous value: -"OPTIONAL aeX402 launchpad slug the coin is launched on. Its vpId then starts with that pad's tag, so the pad lists it. build:true only"New value: +"OPTIONAL aeX402 launchpad slug the coin is launched on. Its vpId then starts with that pad's tag, so the pad lists it. Applies on BOTH the custodial (default) and build:true paths"

Changed1 schema field changedSep 18, 2026

addedInput schema / properties / pad

Added value: +{
+  "description": "OPTIONAL aeX402 launchpad slug the coin is launched on. Its vpId then starts with that pad's tag, so the pad lists it. build:true only",
+  "type": "string"
+}

AddedJul 18, 2026

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 does so: it discloses that the backend signs and submits the transaction, that a custodial call simulates first so failures burn no gas, the meaning of the gated/unreachable statuses, and that the launchpad is not chain-gated. It also names the return shape ({ok,status,txHash,vpId}) despite an output schema existing.

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 with the verb and the economics, then the custodial default, then the build path, then failure modes — a sensible information hierarchy. It is dense and long with several parenthetical asides, but nearly every clause conveys actionable behavior rather than filler.

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 high-stakes mutation tool with no annotations, the description covers custody model, gas/simulation behavior, error semantics, and retryability. Even though an output schema exists, the status-value interpretation it provides is information the schema alone would not convey.

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 100%, so the schema already documents all eight parameters and the baseline is 3. The description adds genuine meaning on top: "you supply only identity" clarifies that name/ticker are the sole required inputs, and it explains that `creator` seeds the vpId and becomes the on-chain creator under build:true.

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 verb and resource ("Launch a memecoin on the aeX402 launchpad on Robinhood Chain") and pins down the exact mechanics: fixed rising bonding curve, 1B supply, graduation at 10,000 USDG. It is unmistakably distinct from the sibling read/quote tools like aex402_getPool, aex402_quote, and aex402_buildSwap.

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?

Explicitly frames the two mutually exclusive paths: default custodial launch (no wallet needed) versus build:true for an unsigned tx, including the added prerequisite that build:true requires `creator`. It also tells the agent what to do with each outcome — "gated" is a simulation revert, "unreachable" is retryable.

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

All aeX402 — Cross-Chain DeFi MCP: LINQ, AMM, Bridge, AI 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?