Skip to main content
Glama

hypernatt-terminal

by com.hypernatt
OverviewDiscussionsAdmin

swap_via_nattswap

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.

Input Schema

TableJSON 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. Changed8 schema fields changed
    • 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"
  2. First observed

TDQS

A4.3/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 well: it discloses cost structure (gas + HyperNatt 0.25% integrator fee, possible Li.Fi cut, plus where to read it), the guidance to sign swap_actions_v1 in order, and the crucial safety fact that the MCP is read-only until the wallet signs.

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 purpose, then labeled USE WHEN / RETURNS / cost / side-effect blocks, so an agent can scan it quickly. The fee sentence is dense with nested parentheticals but still earns its place.

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 a 7-required-param swap tool with no output schema, it covers the return shape (Li.Fi route, execution_readiness, swap_actions_v1), the signing order, and the cost model. Minor gaps remain around error/quote failure handling and slippage defaults.

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 every parameter is already documented in the schema. The description adds no syntax, format, or default detail beyond that (e.g. slippage defaults, chain-id discovery), so the baseline of 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 (swap) and resource (cross-chain tokens) plus provider (Li.Fi) and scope (70+ chains incl. Hyperliquid). Given the siblings are manifest/liquidity-depth readers, no further differentiation is needed for an agent to select this one.

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?

"USE WHEN: bridge, fund gas, treasury routing, or rebalance" gives explicit trigger scenarios. It stops short of naming when NOT to use it or pointing to an alternative, so it falls just under a 5.

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

All hypernatt-terminal toolsInspect
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