AllRatesToday MCP Server

Get historical rate time-series

get_historical_rates

Read-only

Fetch historical exchange rate time-series for a currency pair across 1d, 7d, 30d, or 1y windows ending now. Use it to chart or analyze past pair movement.

Instructions

Use this for fixed-window time-series questions like 'how has EUR/USD moved this week', 'show me the last month of GBP/JPY', or 'chart 1-year history of AUD/USD'. Returns { source, target, period, data: [{ date, rate, timestamp }, ...] } — sampling is fixed per period (1d=hourly, 7d/30d=daily, 1y=weekly) and the window always ends NOW. Needs an API key on a paid plan; free and trial keys get a 403. For a specific past datetime use get_rates_authenticated with time. For a single live rate use get_exchange_rate.

Input Schema

Name	Required	Description	Default
`period`	No	Lookback window ending NOW. '1d' returns ~24 hourly points, '7d' returns 7 daily points, '30d' returns 30 daily points, '1y' returns ~52 weekly points. Defaults to '7d' if omitted.	7d
`source`	Yes	ISO 4217 currency code, 3 letters, case-insensitive (e.g. 'USD', 'EUR', 'GBP', 'JPY'). For a source/target pair, the returned rate is how much 1 unit of source is worth in target. Fiat only — no crypto, no commodities. Call list_currencies if unsure whether a code is supported.
`target`	Yes	ISO 4217 currency code, 3 letters, case-insensitive (e.g. 'USD', 'EUR', 'GBP', 'JPY'). For a source/target pair, the returned rate is how much 1 unit of source is worth in target. Fiat only — no crypto, no commodities. Call list_currencies if unsure whether a code is supported.

Output Schema

Name	Required	Description
`data`	Yes
`period`	Yes
`source`	Yes
`target`	Yes
`source_api`	No	Upstream data provider

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv0.7.9Oct 19, 2026

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / period / description

Previous value: -"Time period to fetch history for."New value: +"Lookback window ending NOW. '1d' returns ~24 hourly points, '7d' returns 7 daily points, '30d' returns 30 daily points, '1y' returns ~52 weekly points. Defaults to '7d' if omitted."

changedInput schema / properties / source / description

Previous value: -"ISO 4217 currency code (e.g. USD, EUR, GBP)."New value: +"ISO 4217 currency code, 3 letters, case-insensitive (e.g. 'USD', 'EUR', 'GBP', 'JPY'). For a source/target pair, the returned rate is how much 1 unit of source is worth in target. Fiat only — no crypto, no commodities. Call list_currencies if unsure whether a code is supported."

removedInput schema / properties / source / maxLength
```
Removed value: -3
```
removedInput schema / properties / source / minLength
```
Removed value: -3
```
addedInput schema / properties / source / pattern
```
Added value: +"^[A-Za-z]{3}$"
```

changedInput schema / properties / target / description

Previous value: -"ISO 4217 currency code (e.g. USD, EUR, GBP)."New value: +"ISO 4217 currency code, 3 letters, case-insensitive (e.g. 'USD', 'EUR', 'GBP', 'JPY'). For a source/target pair, the returned rate is how much 1 unit of source is worth in target. Fiat only — no crypto, no commodities. Call list_currencies if unsure whether a code is supported."

removedInput schema / properties / target / maxLength
```
Removed value: -3
```
removedInput schema / properties / target / minLength
```
Removed value: -3
```
addedInput schema / properties / target / pattern
```
Added value: +"^[A-Za-z]{3}$"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "date": {
+            "type": "string"
+          },
+          "rate": {
+            "type": "number"
+          },
+          "timestamp": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "date",
+          "rate",
+          "timestamp"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "period": {
+      "type": "string"
+    },
+    "source": {
+      "type": "string"
+    },
+    "source_api": {
+      "description": "Upstream data provider",
+      "type": "string"
+    },
+    "target": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "source",
+    "target",
+    "period",
+    "data"
+  ],
+  "type": "object"
+}

First observedv0.2.0Apr 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond readOnlyHint/openWorldHint by disclosing the paid-plan API key requirement and the 403 failure mode for free/trial keys, the fixed sampling cadence per period, and the fact the window always ends NOW. These are non-obvious operational constraints an agent cannot derive from annotations or schema.

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?

Front-loaded with example phrasings that map directly to user utterances, then return shape, then sampling, then auth, then alternatives. Every sentence carries a distinct piece of information with no padding.

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 description need not restate the return structure in depth, yet it does summarize it and still covers sampling resolution, window semantics, and auth gating. Nothing needed for a correct call is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the period enum, its point counts and the ISO 4217 pattern are already documented. The description mostly restates the sampling mapping and the source/target direction semantics already present in the schema, adding little beyond the baseline.

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 states a specific verb+resource (fetch a fixed-window historical rate time-series) and anchors it with concrete example queries. It distinguishes itself from siblings by explicitly naming get_rates_authenticated for past datetimes and get_exchange_rate for a single live rate.

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?

Explicit when-to-use ('fixed-window time-series questions') plus two named alternatives with the exact condition that selects each (a specific past datetime, a single live rate). The agent never has to infer routing.

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

Deploy Server