Skip to main content
Glama
Sign In

fxapi Exchange Rates MCP Server

by com.fxapi.api
OverviewDiscussionsAdmin

Average, low and high rates per month, quarter or year

getAverage

Averages the daily rates per calendar period (month, quarter, year, or total for the whole span) and reports each period's low and high. Daily rates are first expressed against base_currency and then averaged, so the average EUR rate in GBP is the mean of the daily EUR/GBP rates. Average rates are what IFRS and US GAAP allow for translating income and expenses.

date_from and date_to may be at most 1830 days apart. The first and last period are cut to the requested span; date_from, date_to and days of each period tell exactly which days went into it.

Input Schema

NameRequiredDescriptionDefault
typeNoFilter the returned currencies by type.
formatNo`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`.
periodNoHow to group the days.
date_toYesLast day (`YYYY-MM-DD`), yesterday at the latest.
date_fromYesFirst day (`YYYY-MM-DD`), 1999-01-01 or later.
currenciesNoComma-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.
base_currencyNoThe base currency that all returned values are relative to. Defaults to `USD`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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"
+]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations contain only a title, so the description carries the behavioral burden, and it does substantial work: the 1830-day maximum span, how the first and last partial periods are cut, and how daily rates are converted to base_currency before averaging. It stops short of explicitly declaring read-only behavior, error conditions, or rate limits.

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?

The definition is front-loaded with the core computation, then the accounting rationale, then constraints; no sentence is filler. Two compact paragraphs cover method, purpose, and edge-case behavior without redundancy.

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 7-parameter tool with no output schema, the description explains the averaging model, the currency conversion order, and the partial-period rule, and it names date_from/date_to/days as the fields that describe each period. It could say more about the response shape per currency, but the essentials an agent needs before calling are present.

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 3 is the baseline, but the description goes further by explaining that period groups days into month/quarter/year/total and by giving a worked example of base_currency averaging (mean of daily EUR/GBP rates). The date_from/date_to span limit adds meaning beyond the schema's format strings.

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: averages daily rates per calendar month/quarter/year/total and reports each period's low and high. The computation is described precisely enough to distinguish it from getLatest or getHistorical, but no sibling is named explicitly, so the differentiation is implicit rather than stated.

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 IFRS/US GAAP sentence supplies a real use context (translating income and expenses), so the agent can infer when averaging is appropriate. However, it never names an alternative such as getHistorical for daily rates or getOhlc for open/close values, and gives no when-not-to-use guidance.

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 toolsInspect
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