Skip to main content
Glama

exchange-rates-mcp-server

Fx Get Rates

fx_get_rates
Read-onlyIdempotent

Get all available exchange rates for one base currency in a single snapshot. Useful for bulk comparison and seeding downstream tools. Returns a map of quote currency → rate plus the snapshot date. Optionally filter to a subset of quote currencies via symbols. Listing the base currency itself in symbols is accepted and returns a rate of 1 for it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoISO 8601 date (YYYY-MM-DD). Omit for the latest available rate. ECB data starts 1999-01-04. Future dates are not supported.
symbolsNoOptional list of quote currency codes to filter the response. Omit to return all ~30 supported currencies (the base is not among them). Including base_currency here is valid — it comes back with a rate of 1.
base_currencyYesISO 4217 base currency code (e.g. USD). Call fx_list_currencies to get valid codes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
ratesNoMap of quote currency code → exchange rate (units of quote per 1 base).
sourceNoAlways "ECB via Frankfurter" — the upstream data provider.
rate_dateNoActual date of the rates. May differ from requested date on weekends/holidays — ECB publishes business days only; the API silently snaps to the prior business day.
rate_typeNoAlways "ECB reference (mid-market)" — these are reference rates, not tradeable bid/ask.
base_currencyNoThe base currency code.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only and idempotent behavior. The description adds valuable context about the return format (map of quote currency to rate plus snapshot date) and the special case of including the base currency (returns rate of 1). This goes beyond the annotations and provides actionable behavior details.

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 description is compact and well-organized, starting with the core purpose, then usage context, return format, filtering option, and a special edge case. Every sentence contributes information without redundancy, making it efficient for an agent to parse.

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?

For a tool with 3 parameters, a rich output schema, and clear annotations, the description covers all necessary aspects: purpose, usage, return structure, and special behavior. The date handling is mentioned in the schema, and the description suffices for correct invocation without requiring additional context.

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?

The schema has 100% coverage with each parameter described in detail, including the base currency special case. The description reiterates the symbols filter but doesn't add meaning beyond the schema. Since the schema already carries the semantic load, the description adds no extra value, warranting the baseline score of 3.

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?

The description clearly states the tool fetches all exchange rates for a base currency in one snapshot, with specific verbs and resource. It distinguishes itself from sibling tools by emphasizing the bulk snapshot nature versus single rate or timeseries, and mentions the filtering option.

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?

It indicates when to use the tool (bulk comparison, seeding downstream tools) and mentions the optional filter for subset of symbols. However, it doesn't explicitly name alternative tools or provide exclusions (e.g., when to use fx_get_rate or fx_get_timeseries), relying on implicit context from the sibling list.

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.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: conversion, single rate, bulk rates, timeseries, currency listing, and DataFrame inspection/query. The descriptions clearly differentiate between getting a rate vs converting an amount, and between inline vs DataCanvas-stored timeseries.

Naming Consistency5/5

All tools follow a consistent fx_verb_noun pattern (e.g., fx_get_rate, fx_convert_currency, fx_list_currencies). The two dataframe tools also adhere to fx_dataframe_verb, maintaining a uniform convention across the entire set.

Tool Count5/5

Seven tools is well-scoped for an exchange-rate server. Each tool addresses a needed operation (conversion, rates, timeseries, metadata) without redundancy or bloat, and adding DataFrame analysis feels justified for handling large datasets.

Completeness5/5

The surface covers the full lifecycle of exchange-rate queries: listing currencies, fetching single or bulk rates, converting with historical dates, and retrieving timeseries. The optional DataCanvas integration fills the gap for large-range analysis, leaving no obvious dead ends for common use cases.