Skip to main content
Glama

fxapi Exchange Rates MCP Server

Exchange rate of one currency pair

getRate

Returns the rate of one pair as a single number: how many units of to one unit of from buys, and the inverse. Latest at your plan's update interval by default, the close of a past date, or the rate at a datetime within your plan's intraday history (the minute, quarter hour or hour it falls in, as /v1/range reports it: minutes for the last 7 days, hours for the last 3 months). datetime needs a plan with intraday updates.

format=text answers with the bare number, so spreadsheets can read it directly, e.g. Google Sheets =IMPORTDATA("https://api.fxapi.com/v1/rate?from=EUR&to=USD&format=text&apikey=YOUR-API-KEY") or Excel =WEBSERVICE(...).

Input Schema

NameRequiredDescriptionDefault
toYesThe currency to convert to.
dateNoThe close of this past day (format `YYYY-MM-DD`). Not together with `datetime`.
fromYesThe currency to convert from.
formatNo`json` (default), `csv` (`from,to,rate,inverse,last_updated_at`), `xlsx` (the same table as an Excel workbook, `rate.xlsx`) or `text` (only the rate, as plain text without exponent notation).
datetimeNoA moment within your plan's intraday history (ISO 8601). A moment not stored yet gets the newest rate.
precisionNoRound every value to this many decimals (0 to 10). By default values carry up to 10 decimals (10 significant digits below 0.1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"`json` (default), `csv` (`from,to,rate,inverse,last_updated_at`) or `text` (only the rate, as plain text without exponent notation)."New value: +"`json` (default), `csv` (`from,to,rate,inverse,last_updated_at`), `xlsx` (the same table as an Excel workbook, `rate.xlsx`) or `text` (only the rate, as plain text without exponent notation)."
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "json",
      -  "csv",
      -  "text"
      -]New value: +[
      +  "json",
      +  "csv",
      +  "text",
      +  "xlsx"
      +]
  3. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations carry only a title, so the description does the heavy lifting and succeeds on several points: freshness is tied to the plan's update interval, intraday resolution is quantified (minutes for 7 days, hours for 3 months), and `format=text` is disclosed as emitting a bare number. It omits error behavior and any indication of what the rate's own timestamp looks like beyond the csv column list.

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-loads the core contract (one pair, one number, both directions) before the temporal modes. The spreadsheet formula example is longer than strictly necessary and repeats the endpoint URL a second time, but it is genuinely practical and clearly delimited.

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?

With six parameters, no output schema and only a title annotation, the description covers the essentials: return shape, freshness semantics, and temporal resolution limits. It could be stronger by stating what happens for unavailable pairs or historical dates outside plan coverage.

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 baseline is 3. The description adds real value for `datetime` by naming the interval it resolves to and the retention windows, but leaves `precision`, `format` details and the date/datetime exclusivity to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Returns the rate of one pair as a single number') and clarifies directionality ('how many units of `to` one unit of `from` buys, and the inverse'). It does not explicitly distinguish itself from look-alike siblings such as getLatest, getConvert or getHistorical, which matters given that this tool subsumes latest/date/datetime modes.

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?

Gives clear selection logic among its own modes: latest by default, the close of a past `date`, or an intraday `datetime` within a stated window. It also flags the plan prerequisite ('`datetime` needs a plan with intraday updates'). It never names a sibling tool as the alternative for cases this tool does not cover, so the guidance stops short of full routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources