Skip to main content
Glama

banking-intelligence

by ai.ohmyfin
OverviewDiscussionsAdmin

FX Volatility and Exposure Band

fx_volatility
Read-only

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.

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
baseYesBase currency, ISO 4217 (e.g. "EUR").
targetYesTarget currency, ISO 4217 (e.g. "TRY").
horizon_daysNoOptional. Calendar days from today to the end of the exposure, 1-1825. A value outside that range returns an error instead of a band. Omit it for spot / settlement risk only.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / base / description
      Added value: +"Base currency, ISO 4217 (e.g. \"EUR\")."
    • addedInput schema / properties / horizon_days / description
      Added value: +"Optional. Calendar days from today to the end of the exposure, 1-1825. A value outside that range returns an error instead of a band. Omit it for spot / settlement risk only."
    • addedInput schema / properties / target / description
      Added value: +"Target currency, ISO 4217 (e.g. \"TRY\")."
  2. Changed1 schema field changed
    • addedInput schema / properties / horizon_days
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld, so the description carries the behavioral burden and does it well: it discloses that figures are REALISED from a short history (not implied), warns about horizon.beyond_sample, states the band is future spot rather than a transactable rate, and forbids inventing forward rates in favor of relaying horizon.hedge_cost_note.

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?

Front-loaded with the core purpose, then usage, then guardrails, and examples land at the end. It is long, and the hedge-cost warning is somewhat repetitive, but the length is largely justified by the number of correctness rails the model must observe.

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?

With an output schema present the return values need not be spelled out, and the description still covers the qualitative buckets, the horizon block contents, and the interpretation caveats. An agent has everything needed to call it correctly and report results safely.

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?

Schema coverage is already 100%, so the baseline is 3. The description goes beyond the schema by explaining horizon_days semantics — count calendar days from today to exposure end, rough estimates are fine because the band scales with sqrt(time) — which meaningfully adds to the 'accepts 1-1825' schema text.

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 (get realized FX volatility for a currency pair) plus the secondary action (size FX risk on an exposure to a future date). It clearly separates this from siblings like fx_rate, fx_rate_history and fx_timing_advisor by being the realized-volatility/bucketing tool.

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?

Gives explicit when-to-use triggers for horizon_days ('whenever the user's exposure runs past settlement'), a bulleted list of question shapes that select this path, and the negative case (omit it for spot/settlement risk only). This is about as routed as a definition gets.

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