Skip to main content
Glama

Swap plan with every fee (no trade is made)

plan_swap
Read-onlyIdempotent

Plan a swap the way Realtap's own router places it: one order, or the amount split over several pools of Minswap V2, SundaeSwap V3 and WingRiders V2, with the expected and the minimum amount received at the given slippage, every fee in ADA (DEX batcher fees, interface fee, network fee), the refundable deposit, the price impact (percent) and the result net of fees. More exact than get_swap_quote (integer pool maths, fees included) but limited to those three DEXes. Nothing is built or signed: a person executes the plan at swapUrl; an agent that signs with its own key calls build_swap_transaction.

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": {
      "tokenIn": "<tokenIn>",
      "tokenOut": "<tokenOut>",
      "amount": "<amount>"
    },
    "name": "plan_swap"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountYesAmount of tokenIn to sell, decimal-adjusted (100 = 100 ADA when tokenIn is ADA).
tokenInYesWhat is sold: a token unit, or "lovelace" / "ADA" for ADA.
tokenOutYesWhat is bought: a token unit, or "lovelace" / "ADA" for ADA.
maxOrdersNoMost orders the amount may be split over (1 = a single order).
slippagePctNoHow far the price may move against the trade before an order must not execute, in percent (1 = 1 %).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description corroborates and extends them: 'Nothing is built or signed', the refundable deposit, the full fee breakdown in ADA, and the price impact. Because there is no output schema, spelling out exactly what the plan reports (expected and minimum received, fees, deposit, impact, net result) is genuinely additive.

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 verb and scope, and every clause carries information (DEX set, fee items, deposit, impact, next-step routing). The first sentence is a long run-on packing many facts, which costs a little readability but contains no filler.

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?

For a 5-parameter planning tool with no output schema, the description covers what is computed, what is returned, that nothing is signed, and which sibling to use for each downstream path. Nothing an agent needs to call it correctly or route afterward is missing.

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 the baseline is 3; the description still adds meaning beyond it by explaining that the amount can be placed as one order or split across pools (clarifying what maxOrders controls in practice) and that slippage sets the minimum received. It does not add anything about amount units or the token-unit format, which the schema already handles.

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?

Names a specific verb (plan a swap), the exact resource/route model (one order or split across Minswap V2, SundaeSwap V3, WingRiders V2), and what the plan contains. It explicitly distinguishes itself from get_swap_quote (more exact but narrower DEX coverage) and from build_swap_transaction, so an agent can tell the three apart without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the conditions clearly: use this when a human will execute at swapUrl, use build_swap_transaction when the agent signs with its own key, and use get_swap_quote when the three-DEX restriction is a problem. It also declares the exclusion (limited to those three DEXes) rather than leaving it to inference.

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.

Resources