banking-intelligence

FX Rate History

fx_rate_history

Read-only

Get the historical reference exchange-rate series for a currency pair.

Returns series (the daily rates) plus the metadata needed to describe it honestly. READ series_coverage BEFORE CHARACTERISING THE PERIOD. days is the window we look back over, NOT a promise of how much history exists: our series start at different dates per currency, so a 365-day request routinely returns five months. series_coverage.first_date/last_date are what the numbers actually span, and series_coverage.truncated is true when that is shorter than you asked for. Say "the ~N months we hold", never "over the past year", and never fill the gap from your own knowledge.

CHECK source BEFORE ATTRIBUTING PROVENANCE. "ecb" = official ECB euro reference fixings, weekdays only. "market" = an indicative market data feed for a currency the ECB does not publish (AED, QAR, SAR, KWD, NGN, PKR, VND, KZT, RUB, UAH and ~20 more). A market series is NOT an ECB series and must never be described as one. Where a pair mixes the two, series_coverage reports the dates lost to aligning them.

peg_context appears when either currency is pegged, including when the peg is against some third currency: it names the anchor and the pair whose movement you are really looking at. Take the peg date from there rather than from memory.

An uncovered pair returns an error naming the missing leg instead of an empty series. Report that we hold no history rather than describing the rate as stable or range-bound.

BOTH currencies are required. Always pass the exact pair you intend. There is no implicit EUR/USD default: an omitted or mis-named currency errors rather than returning the wrong pair's history.

Examples: fx_rate_history("EUR", "USD", 30) fx_rate_history("GBP", "CHF", 365)

Input Schema

TableJSON Schema

Name	Required	Description
`base`	Yes	Base currency, ISO 4217 (e.g. "EUR"). Rates are quoted as units of target per 1 base.
`days`	No	Lookback window in calendar days, 1-365 (default 90). Values outside the range are clamped. A ceiling on the window, not a promise of that many data points.
`target`	Yes	Target currency, ISO 4217 (e.g. "USD").

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 7, 2026

addedInput schema / properties / base / description

Added value: +"Base currency, ISO 4217 (e.g. \"EUR\"). Rates are quoted as units of target per 1 base."

addedInput schema / properties / days / description

Added value: +"Lookback window in calendar days, 1-365 (default 90). Values outside the range are clamped. A ceiling on the window, not a promise of that many data points."

addedInput schema / properties / target / description

Added value: +"Target currency, ISO 4217 (e.g. \"USD\")."

Changed4 schema fields changedAug 17, 2026

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```
removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

Changed3 schema fields changedJun 16, 2026
- removedInput schema / properties / base / default
```
Removed value: -"EUR"
```
- removedInput schema / properties / target / default
```
Removed value: -"USD"
```
- addedInput schema / required
```
Added value: +[
+  "base",
+  "target"
+]
```
First observedJun 12, 2026

TDQS

A4.6/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 carries substantial extra behaviour: the source field's 'ecb' vs 'market' semantics and which currencies fall under each, series_coverage.truncated logic, peg_context and third-currency anchors, and error-on-uncovered-pair instead of an empty series. This is exactly the kind of context annotations cannot supply.

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 description is long but front-loads purpose then outputs, and nearly every sentence conveys a distinct constraint (provenance, truncation, pegs, errors, required params, examples). The shouting-capital directives are slightly verbose, but the density is justified by the tool's complexity.

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?

Despite an output schema existing, the description supplies the interpretive layer the schema cannot: how to report coverage honestly, how to attribute each source, and how to handle pegged or uncovered pairs. Nothing an agent needs to call and correctly describe the result is 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: it reinforces that days is a ceiling rather than a promise with a concrete illustration ('a 365-day request routinely returns five months'), and stresses that both currencies must be passed exactly with no implicit EUR/USD default. That is genuine added value over the 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?

The opening sentence names a specific verb and resource — retrieve the historical reference exchange-rate series for a currency pair — which cleanly separates it from the sibling fx_rate (current rate). An agent can identify the tool's function 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 description gives strong in-scope guidance (how to characterise the period, how to attribute provenance, how to report uncovered pairs) but never routes the agent to or away from siblings such as fx_rate or fx_volatility, and states no explicit 'when not to use this tool' condition. Clear context, missing the alternative comparison.

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

All banking-intelligence tools Inspect

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

Need Help?