fxapi Exchange Rates MCP Server

Convert a value between currencies

getConvert

Converts a value from the base currency into all (or a filtered set of) currencies, for today or for a given historical date. Requires a plan that includes the convert endpoint. Optional: shape=compact, precision and format=csv.

Send values instead of value to convert up to 100 amounts in one request: data is then a list with one {value, currencies} entry per amount, in the order sent, and meta.values replaces meta.value. datetime converts at a moment within your plan's intraday history, like /v1/rate (the minute, quarter hour or hour it falls in: minutes for the last 7 days, hours for the last 3 months); it needs a plan with intraday updates.

For shop prices, round_step or price_ending (with round_mode) add rounded to every converted value, and locale adds formatted, the amount as text for that locale (e.g. "€ 1.233,99" for de_AT). value itself always stays exact. Rounding and locale are not available with shape=compact.

Input Schema

Name	Required	Description
`date`	No	Optional date to convert against historical rates (format `YYYY-MM-DD`). Must be at least one day in the past. Omit for the latest rates. Not together with `datetime`.
`type`	No	Filter the returned currencies by type.
`shape`	No	`default`: every rate as `{"code": "EUR", "value": 0.918456}`. `compact`: plain values, `"EUR": 0.918456`.
`value`	No	The value to convert. Must be greater than 0 and at most 10^18. Required unless `values` is sent; not together with `values`.
`format`	No	`json` (default), `csv` or `xlsx`. CSV has a header line and one row per currency (and point in time), values without exponent notation. `xlsx` is the same table as an Excel workbook (one sheet, bold frozen header row, numbers as numbers), sent as a download named after the endpoint, e.g. `latest.xlsx`.
`locale`	No	Adds `formatted`: every converted value as text in this ICU locale (e.g. `de_AT`, `en-US`), with the currency's symbol and decimal places (at most 8; none with a whole-number `round_step`). With rounding, the rounded price is formatted. An unknown locale returns a `422`. Not with `shape=compact`.
`values`	No	Up to 100 values to convert (each greater than 0 and at most 10^18), comma-separated or as `values[]=`. `data` becomes a list with one entry per value, in the order sent. The request costs one request.
`datetime`	No	Convert at this moment within your plan's intraday history (ISO 8601): the rate of the minute, quarter hour or hour it falls in, as `/v1/rate` finds it. `meta.last_updated_at` is that point. Needs a plan with intraday updates (`403` on daily plans); moments beyond the plan's history return a `422`.
`precision`	No	Round every value to this many decimals (0 to 10). By default values carry up to 10 decimals (10 significant digits below 0.1).
`currencies`	No	Comma-separated list of currency codes to include (e.g. `EUR,USD,CAD`). The array form `currencies[]=EUR&currencies[]=USD` is also accepted. By default all supported currencies are returned.
`round_mode`	No	How `round_step` and `price_ending` round: to the `nearest` candidate (default), always `up` or always `down`.
`round_step`	No	Adds `rounded`: every converted value rounded to a multiple of this step (greater than 0, at most 10^18), e.g. `0.05`, `1` or `10`. Not together with `price_ending`; not with `shape=compact`.
`price_ending`	No	Adds `rounded`: every converted value rounded to a price with this ending (at least 0, below 1), e.g. `0.99` turns 10.97 into 10.99. Not together with `round_step`; not with `shape=compact`.
`base_currency`	No	The base currency that all returned values are relative to. Defaults to `USD`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 19, 2026

changedInput schema / properties / precision / description

Previous value: -"Round every value to this many decimals (0 to 10). By default values carry up to 10 decimals."New value: +"Round every value to this many decimals (0 to 10). By default values carry up to 10 decimals (10 significant digits below 0.1)."

changedInput schema / properties / round_step / description

Previous value: -"Adds `rounded`: every converted value rounded to a multiple of this step (greater than 0), e.g. `0.05`, `1` or `10`. Not together with `price_ending`; not with `shape=compact`."New value: +"Adds `rounded`: every converted value rounded to a multiple of this step (greater than 0, at most 10^18), e.g. `0.05`, `1` or `10`. Not together with `price_ending`; not with `shape=compact`."

changedInput schema / properties / value / description

Previous value: -"The value to convert. Must be greater than 0. Required unless `values` is sent; not together with `values`."New value: +"The value to convert. Must be greater than 0 and at most 10^18. Required unless `values` is sent; not together with `values`."

changedInput schema / properties / values / description

Previous value: -"Up to 100 values to convert (each greater than 0), comma-separated or as `values[]=`. `data` becomes a list with one entry per value, in the order sent. The request costs one request."New value: +"Up to 100 values to convert (each greater than 0 and at most 10^18), comma-separated or as `values[]=`. `data` becomes a list with one entry per value, in the order sent. The request costs one request."

Changed2 schema fields changedOct 15, 2026

changedInput schema / properties / format / description

Previous value: -"`json` (default) or `csv`. CSV has a header line and one row per currency (and point in time), values without exponent notation."New value: +"`json` (default), `csv` or `xlsx`. CSV has a header line and one row per currency (and point in time), values without exponent notation. `xlsx` is the same table as an Excel workbook (one sheet, bold frozen header row, numbers as numbers), sent as a download named after the endpoint, e.g. `latest.xlsx`."

changedInput schema / properties / format / enum

Previous value: -[
-  "json",
-  "csv"
-]New value: +[
+  "json",
+  "csv",
+  "xlsx"
+]

Changed9 schema fields changedOct 15, 2026

changedInput schema / properties / date / description

Previous value: -"Optional date to convert against historical rates (format `YYYY-MM-DD`). Must be at least one day in the past. Omit for the latest rates."New value: +"Optional date to convert against historical rates (format `YYYY-MM-DD`). Must be at least one day in the past. Omit for the latest rates. Not together with `datetime`."

addedInput schema / properties / datetime

Added value: +{
+  "description": "Convert at this moment within your plan's intraday history (ISO 8601): the rate of the minute, quarter hour or hour it falls in, as `/v1/rate` finds it. `meta.last_updated_at` is that point. Needs a plan with intraday updates (`403` on daily plans); moments beyond the plan's history return a `422`.",
+  "type": "string"
+}

addedInput schema / properties / locale

Added value: +{
+  "description": "Adds `formatted`: every converted value as text in this ICU locale (e.g. `de_AT`, `en-US`), with the currency's symbol and decimal places (at most 8; none with a whole-number `round_step`). With rounding, the rounded price is formatted. An unknown locale returns a `422`. Not with `shape=compact`.",
+  "type": "string"
+}

addedInput schema / properties / price_ending

Added value: +{
+  "description": "Adds `rounded`: every converted value rounded to a price with this ending (at least 0, below 1), e.g. `0.99` turns 10.97 into 10.99. Not together with `round_step`; not with `shape=compact`.",
+  "type": "number"
+}

addedInput schema / properties / round_mode

Added value: +{
+  "description": "How `round_step` and `price_ending` round: to the `nearest` candidate (default), always `up` or always `down`.",
+  "enum": [
+    "nearest",
+    "up",
+    "down"
+  ],
+  "type": "string"
+}

addedInput schema / properties / round_step

Added value: +{
+  "description": "Adds `rounded`: every converted value rounded to a multiple of this step (greater than 0), e.g. `0.05`, `1` or `10`. Not together with `price_ending`; not with `shape=compact`.",
+  "type": "number"
+}

changedInput schema / properties / value / description

Previous value: -"The value to convert. Must be greater than 0."New value: +"The value to convert. Must be greater than 0. Required unless `values` is sent; not together with `values`."

addedInput schema / properties / values

Added value: +{
+  "description": "Up to 100 values to convert (each greater than 0), comma-separated or as `values[]=`. `data` becomes a list with one entry per value, in the order sent. The request costs one request.",
+  "items": {
+    "type": "number"
+  },
+  "maxItems": 100,
+  "minItems": 1,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "value"
-]
```

Changed3 schema fields changedOct 15, 2026

addedInput schema / properties / format

Added value: +{
+  "description": "`json` (default) or `csv`. CSV has a header line and one row per currency (and point in time), values without exponent notation.",
+  "enum": [
+    "json",
+    "csv"
+  ],
+  "type": "string"
+}

addedInput schema / properties / precision

Added value: +{
+  "description": "Round every value to this many decimals (0 to 10). By default values carry up to 10 decimals.",
+  "type": "integer"
+}

addedInput schema / properties / shape

Added value: +{
+  "description": "`default`: every rate as `{\"code\": \"EUR\", \"value\": 0.918456}`. `compact`: plain values, `\"EUR\": 0.918456`.",
+  "enum": [
+    "default",
+    "compact"
+  ],
+  "type": "string"
+}

First observedOct 15, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With only a title annotation, the description carries the burden well: it states the plan prerequisite ('Requires a plan that includes the convert endpoint'), the intraday-plan requirement and resulting 403/422 behavior, the request cost of batch mode, and the incompatibility of rounding/locale with `shape=compact`. It does not explicitly confirm the operation is side-effect free, but for a conversion tool this is largely self-evident.

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 and the plan requirement, then organized into one paragraph per concern (batch, intraday, shop-price rounding/formatting). Dense but every sentence carries information; minor redundancy since some details also appear in the schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool with no output schema and no annotations, the description covers the important interactions: value/values exclusivity, date vs datetime, shape=compact exclusions, and the extra response fields produced by rounding and locale. It stops short of a full response-shape description, but the added-field conventions (`rounded`, `formatted`, `meta.values`) go a long way.

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 genuine value beyond the schema: the mutual exclusion of `value` and `values`, the one-request cost of batch conversion, the response reshaping (`data` as a list, `meta.values` replacing `meta.value`), and the fact that `rounded`/`formatted` are added fields while `value` stays exact. These are cross-parameter interactions the schema does not express.

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 ('Converts a value from the base currency into all (or a filtered set of) currencies') plus the time dimension (today or historical date). An agent can immediately tell this is a value-conversion tool, distinct from rate-lookup siblings like getLatest or getRate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear conditions for parameter choices ('Send `values` instead of `value` to convert up to 100 amounts') and notes `datetime` behaves 'like /v1/rate', which hints at the sibling relationship. However, it never explicitly says when to use getConvert versus getRate, getLatest, or getHistorical, so routing between siblings is left to inference.

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

All fxapi Exchange Rates MCP Server 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?