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 pump.fun-style bonding curve (1B supply, starts 0.0001 USDG, graduates at 10,000 USDG raised, quoted in USDG). 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

TableJSON 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

TableJSON 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)

Schema Changelog

Changes observed during successful MCP inspections.

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.6/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the behavioral burden. It discloses that the backend signs and submits the transaction in the default mode, simulates first to avoid gas waste, and explains both failure statuses ('gated' and 'unreachable'). It also notes that the launchpad is not chain-gated, adding a crucial detail about permission-less execution. These disclosures go well beyond typical descriptions.

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?

The description is long but information-dense. It front-loads the core purpose and then efficiently explains both modes and failure handling. While some sentences could be trimmed, every sentence earns its place by covering essential operational details. The structure is logical and easy to follow.

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?

Given the complexity of two execution paths with different requirements, the description covers all critical aspects: the return object fields ({ok, status, txHash, vpId}), the meaning of statuses, gas-safety via simulation, and the non-custodial alternative. The output schema likely specifies the exact return types, so nothing essential is missing for correct invocation.

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?

The input schema already provides detailed descriptions for all parameters (100% coverage), so the baseline is 3. The description adds meaningful context: it clarifies that `creator` becomes required only in build:true mode, and that `pad` affects the vpId prefix. It also explains the interplay between parameters and the two execution modes, which is not apparent from the schema alone.

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 clearly states the tool launches a memecoin on the aeX402 launchpad with a specific fixed bonding curve, and explicitly distinguishes between custodial and non-custodial execution paths. This is a distinct purpose from sibling tools like aex402_buildSwap or aex402_getPool, which serve different operations. The verb-resource pair is specific and unambiguous.

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?

The description provides clear context on when to use the default custodial path (no wallet needed) versus build:true (non-custodial, requires creator). It explains the simulation behavior and the meaning of statuses, which helps an agent decide if the launch is safe to retry. It doesn't explicitly name alternative tools, but no other sibling directly competes with this launch function.

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?