Skip to main content
Glama

SwapEazi

Route an intent

route_intent

Route one cross-border payment, given as fields or as one sentence ("USD 25,000 to a supplier in Lagos by 30 November"). From a sentence the guide reads what matters without being told: urgency or the due date sets the deadline and puts speed first, words such as cheapest put cost first, regulated or licensed keeps only providers with a licence on record, and paying drivers, staff or a supplier is noted; intent.understood says what was read, and explicit policy fields override it. Returns every route that can carry it, ordered by the payer's own policy, the route the policy selects on the strongest evidence (payments measured when they landed, then published prices; estimates only if the policy allows), the saving against the payer's own quote, and where to pay. With a due date it also routes across time: pay now, lock a forward while holding tokenised T-bills, convert and park, or hold unhedged, as what each needs today. With remember: true SwapEazi keeps the intent, reprices it daily until due and returns its intent_id. A sentence about idle money ("park $5m USDC, back within 24 hours, non-US, qualified, we have Ondo") returns treasury parking instead: tokenised T-bill funds that fit the amount, eligibility, chain and redemption need, by net yield, with what the accounts already held can do and what a new account is worth. The free verification returns the verdict with names masked; a router key (Bearer rk_...) unlocks them. SwapEazi executes nothing and takes no fee from any provider. Returns a compact view by default (each route with its release window cut to the summary and landing dates); pass detail: "full" for everything.

Input Schema

NameRequiredDescriptionDefault
toNoISO 4217 code of the destination currency (what lands), e.g. 'USD'.
fromNoISO 4217 code of the source currency (what leaves), e.g. 'ZAR'.
haveNoProviders or issuers the payer already has accounts with; the result shows what they can do and what a new account adds.
textNoThe payment in one sentence; used instead of from/to/amount.
amountNoAmount leaving, in the source currency.
detailNocompact (default): a short summary that points at the signed full document, sized for a tool result. full: the whole document, which can exceed 100 KB.
policyNoOptional. The payer's own routing policy; overrides what is read from text.
repeatNoWith remember and due_date: the payment repeats; due_date is the first cycle. Monthly cycles keep the day of month (31st: last day of shorter months). One reminder per cycle, before the last day to release through the selected route.
deliverNoAmount to deliver on the due date, destination currency.
lock_atNoWith remember: mark the day locking the rate needs this much or less, source currency.
due_dateNoYYYY-MM-DD the money must land; adds routing across time: pay now, forward, convert and park, hold unhedged.
rememberNoKeep the intent and reprice it daily until it lands; returns remembered.intent_id.
repeat_countNoWith repeat: number of cycles, the first included.
repeat_untilNoWith repeat: YYYY-MM-DD, last date a cycle may fall on.
nudge_lead_daysNoWith repeat: banking days before the release-by date to send the reminder (default 2).
your_quote_landedNoWhat the payer's current quote would land, in the destination currency.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / from / description
      Added value: +"ISO 4217 code of the source currency (what leaves), e.g. 'ZAR'."
    • addedInput schema / properties / policy / description
      Added value: +"Optional. The payer's own routing policy; overrides what is read from text."
    • addedInput schema / properties / policy / properties / deadline_days / description
      Added value: +"Days from today by which the money must land; routes that cannot are left out."
    • addedInput schema / properties / policy / properties / exclude / description
      Added value: +"Provider ids or names to leave out, e.g. ['provider-a']."
    • addedInput schema / properties / policy / properties / include_estimates / description
      Added value: +"true also selects among routes priced by estimate. Default false: measured payments or published prices only."
    • addedInput schema / properties / policy / properties / max_all_in_bps / description
      Added value: +"Maximum all-in cost against the official rate, in basis points (e.g. 150 = 1.5%)."
    • addedInput schema / properties / policy / properties / objective / description
      Added value: +"What decides the selected route: lowest_cost (total cost) or fastest (time to land)."
    • addedInput schema / properties / policy / properties / require_licence / description
      Added value: +"true: only routes with a licence on record. Default false."
    • addedInput schema / properties / policy / properties / risk / description
      Added value: +"certain (default): fixed outcomes only. allow_unhedged: also considers holding the currency unhedged until the due date."
    • addedInput schema / properties / to / description
      Added value: +"ISO 4217 code of the destination currency (what lands), e.g. 'USD'."
  2. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Adds real behavioural context beyond the annotations: the free verification returns a verdict with names masked, a router key (Bearer rk_...) is needed to unmask, SwapEazi executes nothing and takes no fee, and detail: "full" can exceed 100 KB. However the annotations declare destructiveHint=false, so the explicit 'executes nothing' line largely restates the structured safety signal rather than extending it. That overlap plus the dense, hard-to-parse packing keeps this at a 3.

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

Conciseness3/5

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

The purpose is front-loaded in the first clause, but the body is one sprawling paragraph of roughly 300 words that chains sentence-mode rules, temporal routing, recurring reminders, treasury parking and verification disclosure without breaks. Several clauses are load-bearing, yet the treasury-parking and masking details could be tightened and the whole would read far better segmented.

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 16-parameter, nested-object tool with no output schema, the description covers the main return shapes: intent.understood, ordered routes, the selected route and its evidence basis, the saving against the payer's quote, where to pay, and remembered.intent_id. It even explains the compact-versus-full view. What is missing is any indication of failure or no-route outcomes.

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 coverage is 100%, so every one of the 16 parameters is already documented, which sets the baseline at 3. The description does add interaction meaning beyond the schema – explicit policy fields override what is read from text, and intent.understood reports what was read – but most other parameters (repeat, lock_at, nudge_lead_days, your_quote_landed) are only echoed rather than explained further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Route one cross-border payment, given as fields or as one sentence', and enumerates what comes back (every viable route, the policy-selected route, the saving against the payer's quote, where to pay). It does not name or distinguish itself from near-neighbours such as recommend_payment_route, price_routes, assess_route or swapeazi_route_compare, so an agent must infer which routing tool to pick.

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?

Gives clear situational triggers: use the text form for a sentence, set due_date to also route across time, set remember: true to persist and reprice, and send a sentence about idle money to get treasury parking instead. It also states that explicit policy fields override what is read from text. It stops short of exclusions or naming an alternative for the plain price/deal-review cases.

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