Skip to main content
Glama
Sign In

SwapEazi

by io.github.MsingathiM
OverviewDiscussionsAdmin

Assess a cross-border payment route before paying

assess_route
Read-only

Prices a cross-border payment before the business commits to it: every known route for the pair, assessed on SwapEazi's independent data. Returns deterministic JSON: the routes known for the pair, each cost and FX figure with its source, read time, freshness (fresh, aging, stale, unknown) and evidence type (observed, executable, indicative, published; the official rate as reference), settlement facts, the requirements on record with sources, what changed since the last assessment of the corridor, data-quality flags (stale, contradictory, missing, indicative only), unknowns, and the evidence behind each finding, under an assessment_id whose record is kept and retrievable (GET /api/v1/route-assessments/{id}; a content hash, not a signature). Never ranks a route as advice, never executes, never claims a figure is executable unless a provider's firm quote is on record. Free; same as GET /api/v1/route-assessments.

Input Schema

NameRequiredDescriptionDefault
toNoDestination currency, ISO code, e.g. ZMW.
fromNoSource currency, ISO code, e.g. EUR.
sortNoYour chosen order for the routes: landed cost against the official rate, stated days to land, or the measured 7-day answer rate. It is your order, stated as yours; SwapEazi does not rank routes.
as_ofNoAssessment time, ISO 8601, within 15 minutes of now (default now). A past assessment is retrieved by assessment_id, never recomputed.
amountNoAmount leaving, in the source currency. Optional: without it the corridor is assessed at about USD 10,000, labelled.
corridorNoInstead of from and to: e.g. EUR-ZMW.
assessment_idNoRetrieve a kept assessment record instead of making a new one.
charge_optionNoWho pays the banks' charges on a wire: OUR (payer pays all), SHA (shared), BEN (beneficiary).
exclude_typesNoLeave out routes of these rail types. Each route left out is listed with the reason.
include_typesNoKeep only routes of these rail types. Each route left out is listed with the reason.
payer_countryNoTwo-letter country the money leaves from. Needed when from and to are the same currency (e.g. USD from LR to a USD account in CN): the payment is then assessed as a cross-border transfer, banks' charges and rules, no conversion.
min_answer_rateNoPercent, 0 to 100: leave out routes whose measured 7-day answer rate is lower, or not measured (not enough reads). Each is listed with the reason.
beneficiary_countryNoTwo-letter country of the beneficiary's account; with payer_country for a same-currency payment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / beneficiary_country
      Added value: +{
+  "description": "Two-letter country of the beneficiary's account; with payer_country for a same-currency payment.",
+  "type": "string"
+}
    • addedInput schema / properties / charge_option
      Added value: +{
+  "description": "Who pays the banks' charges on a wire: OUR (payer pays all), SHA (shared), BEN (beneficiary).",
+  "enum": [
+    "OUR",
+    "SHA",
+    "BEN"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / payer_country
      Added value: +{
+  "description": "Two-letter country the money leaves from. Needed when from and to are the same currency (e.g. USD from LR to a USD account in CN): the payment is then assessed as a cross-border transfer, banks' charges and rules, no conversion.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavior beyond them. It discloses that output is deterministic JSON with a retained record retrievable at GET /api/v1/route-assessments/{id}, that the record carries a content hash rather than a signature, that the call is free, and that the tool will not rank, will not execute, and will not label a figure executable without a provider's firm quote on record.

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?

The purpose and the key guarantee (prices it before commitment, never advises, never executes) are front-loaded, and almost every clause carries information. The middle is a dense, comma-chained enumeration of return fields and evidence categories that is harder to parse than it needs to be, but nothing is truly redundant.

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?

With no output schema, the description takes on the burden of describing returns and does so thoroughly: routes, costs and FX with sources, freshness states, evidence types, settlement facts, requirements, corridor changes, data-quality flags, unknowns, and the assessment_id. Smaller gaps remain — no note on result limits, auth requirements, or what the response looks like when no routes are known for a pair.

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 parameters like as_of, amount, corridor, and the include/exclude rail filters are already documented in the schema, largely with the same wording the description uses. The description adds little parameter-level meaning of its own beyond referring to "the pair" and the retained assessment record, so the baseline of 3 applies.

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?

The description states a specific verb and resource: it prices a cross-border payment by assessing every known route for a currency pair, returning an assessment record. It explicitly separates itself from advisory tools ("Never ranks a route as advice") and from execution tools ("never executes"), but it never names the close siblings price_routes or compare_payment_providers, so an agent must still infer the boundary with those.

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?

Usage context is clear and stated up front ("before the business commits to it") and the retrieval path is spelled out: a past assessment is fetched by assessment_id and never recomputed. What is missing is explicit guidance naming alternatives for the adjacent jobs — ranking or recommending a rail, or actually paying — which the agent must derive from the negative clauses.

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

All SwapEazi 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