Skip to main content
Glama

banking-intelligence

by ai.ohmyfin

fx_volatility

Get realized FX volatility for a currency pair, and size the FX risk on an exposure held to a future date.

Computes 30-day and 90-day annualized volatility from historical ECB reference rates (standard deviation of daily log returns, annualized by sqrt(252)). Returns a qualitative bucket: LOW (<5%), MEDIUM (5-15%), HIGH (15-25%), VERY_HIGH (>25%), PEGGED (currency peg — near-zero volatility, e.g., USD/AED, USD/HKD).

Also returns practical daily/weekly movement estimates and a settlement_risk_note explaining what the volatility means over a typical T+2 settlement period — use these to advise users on FX risk for their specific payment.

PASS horizon_days WHENEVER THE USER'S EXPOSURE RUNS PAST SETTLEMENT. It returns a horizon block: the volatility scaled to that horizon as an actual rate band at 1 and 2 sigma, which end of the band hurts a payer versus a receiver, and what the band does and does not tell them about hedging. Use it for questions shaped like:

  • "should I hedge / lock in / take a forward for ?"

  • "how far could move by ?"

  • "what rate should I budget for next year?"

  • "I have invoices in through 2027 — what is my risk?"

  • any exposure not settling within a few days. Count the calendar days from today to the date the exposure ends and pass that. Rough is fine — the band moves with the square root of time, so a month either way barely changes it.

Read sample_depth before quoting any figure: this is REALISED volatility from a short history, not implied volatility, and the sample may be shorter than the horizon asked about (horizon.beyond_sample). Say so.

IMPORTANT — the band is the range of FUTURE SPOT. It is not a rate anyone can transact at, and the width of the band is NOT the cost of a hedge. A forward is priced off the interest-rate differential between the two currencies, which we do not hold and must not guess or recall from memory. Relay horizon.hedge_cost_note rather than inventing forward points, a carry figure, or a "typical" hedging cost. Never state a forward rate.

Args: base: Base currency (ISO 4217, e.g., "EUR") target: Target currency (ISO 4217, e.g., "TRY") horizon_days: Optional. Calendar days from today to the end of the exposure (1-1825). Omit for spot/settlement risk only.

Examples: fx_volatility("EUR", "USD") fx_volatility("USD", "TRY") fx_volatility("GBP", "JPY", 506) # exposure running to end-2027 fx_volatility("EUR", "PLN", 90) # invoice settling in a quarter

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseYes
targetYes
horizon_daysNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and does so thoroughly: it specifies the methodology (30/90-day annualized, standard deviation of log returns, sqrt(252)), explains qualitative buckets, and discloses critical caveats such as realized vs implied volatility, sample depth limitations, and the meaning of the future-spot band. It also explicitly warns that the band is not a transactable rate and not a hedge cost.

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

Conciseness5/5

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

The description is long but appropriately so for a complex tool; it is front-loaded with the core purpose, followed by structured guidance and a clear Args section. Each sentence adds actionable value, and the examples make scanning easy without redundancy.

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?

Given the sparse schema but complex behavior, the description fully covers the tool's inputs, outputs, assumptions, limitations, and typical use cases. It references output fields like sample_depth and horizon.hedge_cost_note, which is sufficient even though an output schema exists.

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 description coverage is 0%, so the description must fully compensate for the parameters. It defines base and target as ISO 4217 currency codes and explains horizon_days in detail: optional, calendar days, range 1-1825, omit for spot-only, and practical examples that show usage patterns.

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 description opens with a specific verb and resource: 'Get realized FX volatility for a currency pair, and size the FX risk on an exposure held to a future date.' It clearly distinguishes itself from sibling tools like fx_rate and fx_rate_history by emphasizing realized volatility, risk sizing, and horizon scaling.

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?

It gives explicit when-to-use guidance: pass horizon_days whenever exposure runs past settlement, omit for spot/settlement risk only, and provides concrete question examples. It also explains what not to do — never state a forward rate or invent hedging costs — which clearly separates it from alternatives.

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

All banking-intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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