Skip to main content
Glama

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

bridge_quote

Bridge/swap ANY asset across ANY chain via LI.FI (the engine behind Jumper) — e.g. Arbitrum USDC → Robinhood Chain (4663) USDG, or bridge into ETH for gas. Returns the best route (estimated output, fees, bridge used, duration) PLUS an unsigned transactionRequest (to/data/value/gasLimit) that the CALLER signs and submits on the fromChain — no keys are held here. Chains by id or key (1 Ethereum, 42161 Arbitrum, 8453 Base, 10 Optimism, 137 Polygon, 999 HyperEVM, 4663 Robinhood Chain). Tokens by symbol or 0x address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toChainYesDestination chain id or key, e.g. 4663 (Robinhood Chain)
toTokenYesDestination token symbol or 0x address, e.g. USDG or ETH
fromChainYesSource chain id or key, e.g. 42161 or ARB
fromTokenYesSource token symbol or 0x address, e.g. USDC
toAddressNoRecipient on the destination chain (defaults to fromAddress)
fromAmountYesAmount in the source token's smallest unit (e.g. 1000000 = 1 USDC at 6 decimals)
fromAddressYesSender 0x address on the source chain

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
bridgeYesbridge tool used (e.g. across)
toTokenNo
toAmountYes
fromTokenNo
toAddressNo
toChainIdNo
feeCostUsdNo
fromAmountNo
gasCostUsdNo
fromAddressNo
fromChainIdNo
toAmountMinNo
toTokenAddressNo
fromTokenAddressNo
transactionRequestYesUNSIGNED tx (to, data, value, gasLimit) — caller signs & submits on the fromChain
estimatedDurationSecNo

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses that the tool returns an unsigned transactionRequest for the caller to sign and submit, and that no keys are held. It also explains what the return includes (estimated output, fees, bridge used, duration). This is transparent about not executing transactions, which is critical for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph but is well-structured: core purpose first, then example, then return details, then accepted inputs. Every sentence adds information without redundancy.

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 that an output schema exists and is not provided here, the description sufficiently covers the tool's purpose, input format, and behavioral output. It addresses the parameters indirectly and explains the transaction workflow, making it complete for an agent to select and invoke the tool.

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

Parameters5/5

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

The description supplements the already-complete schema with helpful examples: amount in smallest unit (e.g., 1000000 = 1 USDC at 6 decimals), chain ids/keys, and token symbols/addresses. This adds significant value beyond the schema.

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's function: it bridges/swaps any asset across any chain via LI.FI, returns the best route plus an unsigned transactionRequest. It distinguishes from sibling tools by specifying cross-chain functionality and the unsigned tx output.

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 context on when to use this tool (cross-chain swaps, bridging into ETH for gas) but does not explicitly mention alternatives or when-not-to-use. It implies the use case but lacks explicit exclusions.

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.

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