Skip to main content
Glama

settlement_eta

BETA. Estimate when a SWIFT payment will arrive: a corpus-grounded arrival window with an honest tail, computed from real completed payments we have tracked, projected onto the currency's banking calendar.

This estimator is in BETA and still calibrating. Say so when you present a number: call it an estimate or a typical window, never a commitment, and never let a user plan an irreversible decision (a cutoff, a contractual settlement date) on it without that caveat. The payload carries beta=true while this holds.

Two modes:

  • Forward (default): "when will it land" — returns P50/P90/P95 arrival dates, sample size, confidence, competing non-arrival risk, delay-risk factors, and (where validated) the most likely correspondent route.

  • Reverse: pass arrive_by_date (YYYY-MM-DD) — returns the latest send date such that arrival by that day is likely ("send by Thursday to land by month-end").

INPUT DISCIPLINE (important):

  • Mid-flight payment: pass ONLY the uetr (from TrackingContext or track_payment). The server resolves the current status, currency and elapsed time deterministically from the tracking record. NEVER compute elapsed_business_days yourself.

  • Pre-trade question ("how long will a USD wire from X to Y take?"): pass currency + sender_bic/receiver_bic (8 or 11 chars, or bank names). current_status / elapsed_business_days are for this path only.

Reading the answer honestly (relay these to the user):

  • basis.n is the sample size and confidence reflects it; when confidence is "low", present the window as a rough range, never a promise.

  • route.confirmed=false means the route is INFERRED from settlement instructions on file, not confirmed by GPI — say so.

  • basis.route_adjusted=true means we hold no completed payments for this exact pair and the window was lifted to a route-composed estimate: the SSI-implied correspondent chain (route.intermediaries hops) with typical processing time per hop. Present it as a route-based estimate, not as observed statistics, and never quote the faster currency-pool average alongside it as if corridor-specific.

  • mode="outlier" means the payment is already slower than ~90% of similar payments: stop quoting a window, explain the usual manual causes (compliance review, repair/RFI, missing cover) and pivot to the stuck-payment diagnostic flow.

  • non_arrival.p_reject is the share of similar payments that were returned or rejected rather than delivered.

  • "Delivered" (ACCC) means delivered to the beneficiary bank per GPI; funds can become usable in the account slightly later.

Available on every surface to any caller with an active subscription. The estimate itself costs no credits (tracking a payment does cost credits; never describe tracking as free).

Args: uetr: UETR of a tracked payment (preferred for mid-flight questions) currency: 3-letter currency (pre-trade path; ignored when uetr resolves) sender_bic: Sender bank BIC or name (pre-trade path) receiver_bic: Receiver bank BIC or name (pre-trade path) intermediary_bic: Known intermediary BIC (optional) current_status: GPI status like ACSP (pre-trade/no-uetr path only) elapsed_business_days: Business days already in flight (pre-trade path only) amount: Payment amount (improves delay-risk assessment). A plain number is fine — 50000 and "50,000.00" are both accepted. sender_country: ISO2 country of the sender bank (optional) receiver_country: ISO2 country of the receiver bank (optional) arrive_by_date: YYYY-MM-DD — switches to reverse send-by mode. You do not know today's date; a deadline stated as "the 20th" or "by month-end" must be resolved against the today block returned by bank_holidays / value_date / is_business_day_check, not against your own sense of the current date. A date in the past is rejected. api_key: Optional API key (internal calls ride the MCP secret)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uetrNo
amountNo
api_keyNo
currencyNo
sender_bicNo
receiver_bicNo
arrive_by_dateNo
current_statusNo
sender_countryNo
intermediary_bicNo
receiver_countryNo
elapsed_business_daysNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden — and it overdelivers. It discloses the BETA status and instructs the agent to say so, defines response semantics (`route.confirmed=false` means inferred, not GPI-confirmed; `route_adjusted=true` means route-composed, not observed), flags the outlier mode behavior, and even addresses billing transparency ('never describe tracking as free'). This goes far beyond any annotation could have captured.

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?

Exceptionally well-structured with headers, bold labels, and code-format parameter names — easy to scan despite length. The 'Reading the answer honestly' section and forward/reverse mode setup earn their place. Docked one point because some agent-behavior instructions (e.g., 'relay these to the user') could arguably live in the system prompt rather than a tool description, and the description could be tightened by 15-20% without losing meaning.

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 12-parameter, dual-mode tool in BETA with no annotations, this is as complete as it gets. It covers both invocation modes, edge cases (outlier mode, rejected past dates), interpretation guidance for every non-obvious return field (n, route_adjusted, p_reject), and even billing implications. The guidance to present windows as estimates rather than commitments is exactly the kind of nuance an agent needs for a financial tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description had to carry everything — and it documents all 12 parameters in a well-organized Args block. It adds meaningful context per param: `uetr` is 'preferred for mid-flight questions,' `current_status` and `elapsed_business_days` are 'pre-trade path only,' `arrive_by_date` switches to reverse mode and 'a date in the past is rejected,' and `amount` accepts both formats ('50000' and "50,000.00"). Also clarifies the deterministic resolution of parameters from the tracking record.

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?

The first sentence nails it: 'Estimate when a SWIFT payment will arrive: a corpus-grounded arrival window with an honest tail, computed from real completed payments...' — a specific verb (estimate), resource (SWIFT payments), and scope (arrival windows). It clearly differentiates from siblings like `track_payment` (tracking status) and `value_date` (business-day resolution) by framing itself as the arrival estimator with two explicit modes.

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?

Excellent input discipline section: distinguishes 'Mid-flight payment' (pass ONLY the uetr) from 'Pre-trade question' (currency + sender_bic/receiver_bic), and explains reverse mode with arrive_by_date. It even directs the agent to resolve date ambiguities 'against the `today` block returned by bank_holidays / value_date / is_business_day_check.' Slightly docked because it never explicitly names a sibling as a better alternative in plain terms — the guidance is thorough on how to use THIS tool but doesn't say 'for X, use sibling Y instead' as a direct comparison.

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.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools have distinct purposes, but some overlapping areas (goods_classify vs hs_code_lookup vs eccn_lookup; fx_rate vs fx_rate_history vs fx_volatility) require close reading of descriptions to select correctly. The detailed descriptions help, but the shear number of lookup tools creates mild ambiguity.

Naming Consistency3/5

Names mix verb-first (track_payment, mcp_verify) and noun-first patterns (iban_validate, fx_rate, ssi_lookup), with some phrase-like names (banks_using_correspondent, is_business_day_check). While readable, there is no single consistent convention.

Tool Count3/5

33 tools is heavy, but the server's broad scope (payments, FX, sanctions, export controls, company registries, SWIFT) justifies most of them. A few marginal tools (mcp_register, mcp_verify, company_search_result) add bulk without core value.

Completeness5/5

The tool set covers the payment lifecycle end-to-end: tracking, settlement, FX, compliance, sanctions, and company due diligence. There are no obvious dead ends; the tools chain together via next_steps and search_id flows.

Resources