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). Live create is gated on the launchpad facet upgrade (pending); until enabled a custodial call returns status "gated" and burns no gas.

Input Schema

TableJSON Schema

Name	Required	Description
`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)

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behaviors: custodial vs non-custodial, gas-free when gated, return object shape, and constraints on name/ticker bytes. The bonding curve and USDG quoting are detailed.

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 single paragraph is dense but well-organized, front-loading the key purpose and default behavior. Every sentence contributes necessary detail, though breaking into sections could improve scannability.

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 tool's complexity (custodial/non-custodial, gating, bonding curve), the description covers all essential behavioral aspects, input constraints, and return values. Output schema existence further reduces need for return format details.

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 baseline 3. The description adds value by explaining the relationship between creator and build, and clarifies that image/links/description are off-chain metadata, exceeding mere schema repetition.

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 it launches a memecoin on the aeX402 launchpad with specific bonding curve parameters (fixed supply, starting price, graduation threshold). It distinguishes from sibling tools like aex402_buildSwap by focusing on token creation.

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?

Explicitly describes custodial (default) and non-custodial (build:true) modes, and notes the gating status pending upgrade. However, it does not explicitly contrast with alternative tools for similar tasks.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation3/5

Several tool pairs overlap in function: aex402_quote vs aex402_buildSwap, search vs search_tokens vs discover_programs, describe_program vs reconstruct_abi, and mcp_linq vs agent_delegate. Descriptions attempt to differentiate, but boundaries are fuzzy and an agent could easily select the wrong one when uncertain.

Naming Consistency2/5

Naming is inconsistent: some tools use camelCase (aex402_buildSwap) while most use snake_case, verbs vary widely (build, get, list, quote, search, describe, discover, launch, delegate, chat), and there is no uniform verb_noun pattern. This makes predicting tool names difficult.

Tool Count2/5

32 tools is excessive for a single MCP server, exceeding the 25+ threshold. While the scope is broad (AMM, bridge, AI, RPC, discovery, launchpad), many tools could be consolidated (e.g., search tools) or are too fine-grained (multiple solana_get* tools).

Completeness4/5

Core workflows are well covered: AMM (quote/build/get/list), bridge (quote/status), AI (chat/delegate/linq), Solana and EVM RPCs, search/discovery plus health check, launchpad, and payment help. Minor gaps include no direct bridge history or AMM execution, but these are intentional in a non-custodial design.

Resources

Need Help?