AllRatesToday MCP Server

Get live exchange rate

get_exchange_rate

Read-only

Convert one fiat currency to another by retrieving the current mid-market exchange rate, returning a JSON rate and source for single currency-pair questions.

Instructions

Use this when the user asks 'what is X in Y?', 'convert X to Y', 'current rate of EUR/USD', or any single fiat-to-fiat live exchange rate question. Returns the latest mid-market rate as a JSON object like { rate: 0.9234, source } meaning 1 source = 0.9234 target. Without an API key it answers from an official central-bank table instead (ECB first, else the bank that issues one of the two currencies) and says so in note — relay the rate_date; pairs no single bank publishes (or inverts) need a key. Does NOT support cryptocurrencies, commodities, or arithmetic on amounts. For multiple targets in one call use get_rates_authenticated; for a past date or fixed lookback (7d/30d/1y) use get_historical_rates.

Input Schema

Name	Required	Description	Default
`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
`bank`	No
`note`	No
`rate`	Yes	How much 1 unit of source is worth in target
`source`	Yes	Upstream data provider the rate came from
`derived`	No
`rate_date`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 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 / 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": {
+    "bank": {
+      "type": "string"
+    },
+    "derived": {
+      "type": "boolean"
+    },
+    "note": {
+      "type": "string"
+    },
+    "rate": {
+      "description": "How much 1 unit of source is worth in target",
+      "type": "number"
+    },
+    "rate_date": {
+      "type": "string"
+    },
+    "source": {
+      "description": "Upstream data provider the rate came from",
+      "type": "string"
+    }
+  },
+  "required": [
+    "rate",
+    "source"
+  ],
+  "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?

With only readOnlyHint/openWorldHint provided, the description carries real behavioral weight: it explains the no-API-key fallback (ECB first, else the issuing central bank), that this is surfaced in a `note` field, that `rate_date` should be relayed, that some pairs or inverted pairs require a key, and that the returned rate is a mid-market rate. That is well beyond what the annotations convey.

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 the when-to-use triggers, then return shape, then fallback behavior, then exclusions and alternatives. Every sentence carries distinct information; nothing is 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?

Covers invocation conditions, output shape, degraded-mode behavior, limitations, and sibling routing. With an output schema present it need not explain return values, yet the extra detail it does give (note, rate_date) is directly actionable.

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% and both parameters already document the ISO 4217 format, case-insensitivity, fiat-only restriction, pair direction, and the list_currencies fallback. The description restates the same direction semantics ('1 source = 0.9234 target') rather than adding new parameter-level detail, so the baseline 3 for schema-driven params is correct.

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 ('live exchange rate') and explicitly scopes it to single fiat-to-fiat pair conversion. It distinguishes itself from siblings in the same breath ('For multiple targets in one call use get_rates_authenticated; for a past date ... use get_historical_rates'), so an agent can route without opening any schema.

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 concrete trigger phrases ('what is X in Y?', 'convert X to Y', 'current rate of EUR/USD'), states the exclusions (no crypto, no commodities, no arithmetic on amounts), and names both the multi-target alternative and the historical alternative with the condition that selects each.

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

Deploy Server