Skip to main content
Glama

SwapEazi

Payment Discovery

discover_payment
Read-only

Starts a cross-border payment: prices it on every rail (bank, PSP, stablecoin) and lists what is not known, before anything is prepared. Call this before initiating any cross-border or cross-currency payment. One call: a payment requirement in, a signed DiscoveryReport (a Decision Brief) out, across bank, PSP and stablecoin rails side by side — each leg's cost in basis points against an independent reference, settlement time, licence and evidence class. Pass a needed_by date to also get timing_scenarios (fund now, lock a forward, convert and park, or hold unhedged — the router's own due-date scenarios, unordered), fx_exposure (what funding the obligation today would cost at +1/+3/+5% adverse moves, arithmetic on the reference, not a forecast), and hedge_scenarios (no/half/full hedge, indicative cost from covered interest parity, residual exposure — scenario presentation only, never a recommended ratio or automated hedge). historical_context today is band-wide for the pair and size, not yet specific to the caller; current_quote, if passed, is measured against the reference the same way (the Markup Measure). what_we_dont_know is always present, even when empty. Nothing here ranks, picks or recommends. Does not execute, hold or price money. Free within the daily allowance; a key lifts it. The options/cost path is typically under 3 seconds, cached metadata only; with needed_by, timing_scenarios adds one live routing lookup and can take longer. Returns a compact view by default (one short object per option; what_we_dont_know, regulatory_notes and the scenarios in full) that points at the signed Options Map behind it; pass detail: "full" for the whole report.

Input Schema

NameRequiredDescriptionDefault
payerNoOptional. Who is paying: { entity_type, jurisdiction }.
amountYesThe amount, greater than zero.
clientNoOptional. Who is asking: { type: agent | human, agent_id }.
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.
amount_inNoWhich currency amount is stated in. Overrides direction's default, e.g. paying a fixed destination amount while funding from the source currency.
directionNopay (default): amount is what leaves. receive: amount is what must land.
needed_byNoOptional ISO date the money must land by. Adds timing_scenarios, fx_exposure and hedge_scenarios to the report, and each option's settlement.release_by: the latest release that lands by this date at the rail's later and earlier typical settle_days (on bank rails, the provider's cut-off on a banking day; the cut-off is not on record).
release_atNoOptional ISO date-time the payment will be released; default now. Each option's settlement.release_window states whether its rail moves at that moment (bank rails on banking days only, stablecoin rails around the clock), when it starts moving, the landing dates that follow, any sourced time-based markup, and what is not on record (cut-offs, bank holidays).
constraintsNoOptional. The payer's own limits: { max_settlement_hours, exclude_providers, require_licensed_in }.
current_quoteNoOptional: a quote already held, measured as given against the reference.
rails_allowedNoDefault: all. Only bank and stablecoin filter directly today; psp/dex leave every non-excluded rail in.
source_currencyYesISO 4217 code the payment leaves in, e.g. 'EUR'.
target_currencyYesISO 4217 code the payment must land in, e.g. 'ZAR'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / client / description
      Added value: +"Optional. Who is asking: { type: agent | human, agent_id }."
    • addedInput schema / properties / client / properties / type / description
      Added value: +"agent or human."
    • addedInput schema / properties / constraints / description
      Added value: +"Optional. The payer's own limits: { max_settlement_hours, exclude_providers, require_licensed_in }."
    • addedInput schema / properties / constraints / properties / exclude_providers / description
      Added value: +"Provider ids or names to leave out."
    • addedInput schema / properties / constraints / properties / max_settlement_hours / description
      Added value: +"Maximum hours from release to landing; slower options are marked outside."
    • addedInput schema / properties / current_quote / properties / provider / description
      Added value: +"Who gave the quote, e.g. a bank or provider name."
    • addedInput schema / properties / current_quote / properties / quoted_at / description
      Added value: +"ISO 8601 timestamp the quote was given, e.g. '2026-11-04T09:30:00Z'."
    • addedInput schema / properties / payer / description
      Added value: +"Optional. Who is paying: { entity_type, jurisdiction }."
    • addedInput schema / properties / payer / properties / entity_type / description
      Added value: +"corporate, sme, fintech, crypto_native or individual."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint it discloses cost model ('Free within the daily allowance; a key lifts it'), latency profile (options/cost path typically under 3 seconds, cached metadata; needed_by adds a live routing lookup and can take longer), and output volume trade-off (compact default vs detail: "full" exceeding 100 KB). It also states invariants (what_we_dont_know always present, no ranking or automated hedge) that no annotation conveys.

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 capability line is front-loaded and the following clauses on scenarios, latency, cost and default detail each carry decision-relevant information. The second sentence is an extremely long run-on packed with parenthetical caveats, which costs readability, but little is genuinely 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 13-parameter, nested-object tool with no output schema, the description explains the returned report, its compact-vs-full views, the always-present unknown block, latency, and invocation prerequisites. Nothing an agent needs to call this correctly appears to be 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?

With 100% schema coverage the baseline is 3, and the description genuinely adds meaning: needed_by unlocks timing_scenarios, fx_exposure and hedge_scenarios and their specific semantics (fund now / lock forward / convert and park / hold unhedged; +1/+3/+5% adverse moves; covered-interest-parity indicative cost). It also explains current_quote as the Markup Measure against the reference, though it leaves depth of other params to the schema.

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 ('Starts a cross-border payment: prices it on every rail ... before anything is prepared') and immediately bounds scope with 'Does not execute, hold or price money' plus 'Nothing here ranks, picks or recommends', which separates it from prepare_payment, calculate_payment_cost and recommend_payment_route. An agent can tell what it does and does not do without opening the schema.

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 when-to-use is explicit: 'Call this before initiating any cross-border or cross-currency payment', and it delivers a DiscoveryReport before anything is prepared. It never names a specific alternative sibling or states an exclusion case, so a 3-level inference is still required for what to call instead of / after this, keeping 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources