Skip to main content
Glama
Sign In
hypernatt-terminal

hypernatt-terminal

by DIALLOUBE-RESEARCH
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

swap_via_nattswap

Execute cross-chain token swaps via Li.Fi across 70+ chains, including Hyperliquid, for bridging, gas funding, treasury routing, or wallet rebalancing.

Instructions

Cross-chain token swap powered by Li.Fi across 70+ chains incl. Hyperliquid. USE WHEN: bridge, fund gas, treasury routing, or rebalance. RETURNS: Li.Fi route + execution_readiness + swap_actions_v1. Prefer signing swap_actions_v1 in order. MCP free; on-chain swap costs gas + HyperNatt 0.25% integrator fee (Li.Fi may add its own cut — read quote.estimate.feeCosts). Side effects: MCP read-only until wallet signs.

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": {
      "fromChain": "<fromChain>",
      "toChain": "<toChain>",
      "fromToken": "<fromToken>",
      "toToken": "<toToken>",
      "fromAmount": "<fromAmount>",
      "fromAddress": "<fromAddress>",
      "toAddress": "<toAddress>"
    },
    "name": "swap_via_nattswap"
  }
}

Input Schema

NameRequiredDescriptionDefault
toChainYesDestination Li.Fi chain id
toTokenYesDestination token contract address on toChain
slippageNoMax slippage percent (e.g. 0.5 for 0.5%)
fromChainYesSource Li.Fi chain id (e.g. 1 Ethereum, 8453 Base, 42161 Arbitrum)
fromTokenYesSource token contract address on fromChain
toAddressYesRecipient wallet 0x + 40 hex chars
fromAmountYesAmount in token smallest units (wei for 18-decimal tokens)
fromAddressYesSender wallet 0x + 40 hex chars

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.11
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed8 schema fields changedv1.0.2
    • changedInput schema / properties / fromAddress / description
      Previous value: -"Sender wallet"New value: +"Sender wallet 0x + 40 hex chars"
    • changedInput schema / properties / fromAmount / description
      Previous value: -"Amount in token smallest units"New value: +"Amount in token smallest units (wei for 18-decimal tokens)"
    • changedInput schema / properties / fromChain / description
      Previous value: -"Source chain id"New value: +"Source Li.Fi chain id (e.g. 1 Ethereum, 8453 Base, 42161 Arbitrum)"
    • changedInput schema / properties / fromToken / description
      Previous value: -"Source token address"New value: +"Source token contract address on fromChain"
    • changedInput schema / properties / slippage / description
      Previous value: -"Slippage percent"New value: +"Max slippage percent (e.g. 0.5 for 0.5%)"
    • changedInput schema / properties / toAddress / description
      Previous value: -"Recipient wallet"New value: +"Recipient wallet 0x + 40 hex chars"
    • changedInput schema / properties / toChain / description
      Previous value: -"Destination chain id"New value: +"Destination Li.Fi chain id"
    • changedInput schema / properties / toToken / description
      Previous value: -"Destination token address"New value: +"Destination token contract address on toChain"
  3. First observedv1.0.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so well: it discloses the return shape (route + execution_readiness + swap_actions_v1), the cost model (gas plus a 0.25% HyperNatt integrator fee, possible Li.Fi fee found in quote.estimate.feeCosts), and the side-effect boundary ('MCP read-only until wallet signs'). The signing-order instruction is real operational guidance an agent would otherwise get wrong.

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 core purpose, then organized by USE WHEN / RETURNS / fees / side effects, with no filler sentences. Dense em-dash clauses and a parenthetical make it slightly harder to scan than it needs to be.

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 an 8-parameter swap tool with 7 required fields and no output schema, the description supplies the return contract, cost expectations, and safety boundary that the structured data omits. It stops short of explaining what execution_readiness signals or how failures and quote expiry are surfaced.

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

Parameters3/5

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

Schema description coverage is 100%, so chain ids, token addresses, amount units, and slippage are already documented in the schema. The description adds nothing parameter-specific beyond pointing at quote.estimate.feeCosts, which is a response field, not an input; baseline 3 applies.

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 ('Cross-chain token swap'), the routing provider (Li.Fi), and scope (70+ chains incl. Hyperliquid). None of the sibling tools are swap operations, so the read-only catalog tools are implicitly ruled out without ambiguity.

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 'USE WHEN' list gives four concrete triggers (bridge, fund gas, treasury routing, rebalance), which is far more than most definitions offer. It lacks an explicit 'do not use when' case or a named alternative, which keeps it below a 5.

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

Deploy Server

Other Tools