AllRatesToday MCP Server

Get multi-target or point-in-time rates

get_rates_authenticated

Read-only

Fetch live multi-target currency rates or a rate at a specific past datetime, optionally bucketed by hour, day, week, or month.

Instructions

Use this for (a) one source against multiple targets in a single call ('USD vs EUR, GBP, JPY'), or (b) the rate at a specific past datetime ('EUR/USD at 2025-03-14T12:00Z'), optionally bucketed by hour/day/week/month. Returns { rates: [{ rate, source, target, time }, ...] } — one row per target × time bucket. Multi-target latest rates work on any key; a past datetime (time) needs a paid plan. For a single live pair use get_exchange_rate. For fixed lookback windows (1d/7d/30d/1y ending now) use get_historical_rates.

Input Schema

Name	Required	Description
`time`	No	Single point-in-time ISO 8601 UTC timestamp (e.g. '2025-03-14T12:00:00Z'). Omit for the latest rate.
`group`	No	Aggregation bucket: 'hour', 'day', 'week', or 'month'. Useful when time is omitted to return rolling averages. Omit for raw single-point output.
`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	One or more ISO 4217 codes, comma-separated, no spaces, case-insensitive. Examples: 'EUR' (single) or 'EUR,GBP,JPY' (multi). Each target becomes a separate row in the response.

Output Schema

Name	Required	Description	Default
`rates`	Yes

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 / group / description

Previous value: -"Optional grouping window."New value: +"Aggregation bucket: 'hour', 'day', 'week', or 'month'. Useful when time is omitted to return rolling averages. Omit for raw single-point output."

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: -"One or more target codes, comma-separated."New value: +"One or more ISO 4217 codes, comma-separated, no spaces, case-insensitive. Examples: 'EUR' (single) or 'EUR,GBP,JPY' (multi). Each target becomes a separate row in the response."

addedInput schema / properties / target / pattern
```
Added value: +"^[A-Za-z]{3}(,[A-Za-z]{3})*$"
```

changedInput schema / properties / time / description

Previous value: -"Optional historical ISO 8601 timestamp."New value: +"Single point-in-time ISO 8601 UTC timestamp (e.g. '2025-03-14T12:00:00Z'). Omit for the latest rate."

addedInput schema / properties / time / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "rates": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "rate": {
+            "type": "number"
+          },
+          "source": {
+            "type": "string"
+          },
+          "target": {
+            "type": "string"
+          },
+          "time": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "rate",
+          "source",
+          "target",
+          "time"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "rates"
+  ],
+  "type": "object"
+}

First observedv0.2.0Apr 21, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds a real access constraint ('a past datetime needs a paid plan') that annotations cannot express, plus the row-per-target x bucket response semantics. It stops short of discussing rate limits, pagination, or the cost/behavior of large multi-target requests, so it is strong but not exhaustive.

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 two primary use cases, the return shape, then the caveat and alternatives - a sensible ordering. It is dense and some inline examples duplicate what the schema already shows, which keeps it just under fully economical.

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 response shape but does briefly clarify the row semantics anyway, and it covers auth/plan gating, all four parameters' intent, and sibling routing. Nothing required to call it correctly 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 already 100%, so the baseline is 3; the description still adds meaning by spelling out the return direction ('1 unit of source is worth in target'), the no-spaces comma-separated target syntax, and the interaction between omitting `time` and using `group` for rolling averages.

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+resource and enumerates the two exact modes it serves: multi-target latest rates in one call, and point-in-time rate at a past datetime. It also names the sibling tools it is NOT (get_exchange_rate, get_historical_rates), so an agent can disambiguate without opening schemas.

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 for both modes ('a' multi-target, 'b' past datetime with optional bucketing) plus exclusions routed to alternatives: single live pair -> get_exchange_rate, fixed lookback windows -> get_historical_rates. It even flags the plan constraint that gates the `time` path.

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

Deploy Server