Skip to main content
Glama

Frankfurter

by io.github.lineofflight
OverviewDiscussionsAdmin

Server Details

Convert currencies and fetch blended FX rates from 50+ institutional sources.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 43 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
lineofflight/frankfurter-mcp
GitHub Stars
3
Server Listing
frankfurter-mcp

TDQS

A4.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: convert handles conversions, get_rates returns raw rates, and the two list tools provide reference data. The companion relationship between convert and get_rates is explicitly described, so there is little risk of misselection.

Naming Consistency5/5

All tool names follow a consistent lowercase verb_noun pattern: convert, get_rates, list_currencies, list_providers. The naming is predictable and immediately signals each tool's action and target.

Tool Count5/5

Four tools is well-scoped for a currency conversion server. Each tool covers a necessary function without redundancy or bloat.

Completeness5/5

The surface covers the core domain completely: currency conversion, current and historical rates, supported currencies, and available rate providers. Agents can accomplish any reasonable currency-related task without hitting dead ends.

Available Tools

4 tools
convertConvert currencyA
Read-only
Inspect

Convert an amount from one currency to another. Returns {amount, currency} rounded to the target's minor units. Upstream rounds rates per direction; for low-value sources, flip via get_rates for more precision. Pass provider to use one institution's published rate, e.g. UST for a U.S. Treasury reporting rate.

ParametersJSON Schema
NameRequiredDescriptionDefault
toYesISO 4217 target currency.
dateNoDate YYYY-MM-DD for a past rate; omit for latest.
fromYesISO 4217 source currency.
amountYesAmount in the source currency. Normalize localized input first: '100,50' -> 100.5; German '1.000,50' -> 1000.5; English '1,000.50' -> 1000.5.
providerNoProvider key, e.g. ECB for European Central Bank or UST for U.S. Treasury reporting rates. Serves that institution's published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses the return shape, rounding to minor units, direction-dependent rate rounding, and provider-specific rate behavior. It gives the agent important operational context without contradicting the annotations.

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?

Three sentences with no filler. The first sentence defines the core operation, and the subsequent sentences each add a distinct, useful behavioral detail. Everything is front-loaded and relevant.

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?

Even without an output schema, the description states the return shape and key rounding behavior. Provider nuances, date semantics, and the get_rates alternative are addressed either in the description or in the schema, making this complete for a read-only conversion tool.

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. The description adds extra meaning by explaining provider examples (UST) and the direction-dependent rounding behavior, which is not inferable from the schema alone.

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 a specific action and resource: converting an amount from one currency to another. It also distinguishes itself from the sibling get_rates tool by referencing it for an alternative precision behavior.

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?

The description explicitly tells the agent when to consider get_rates instead (low-value sources, to flip direction for more precision), and when to pass a provider. It does not spell out a comprehensive list of exclusions, but the primary use case is unambiguous and the alternative routing is concrete.

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

get_ratesGet exchange ratesA
Read-only
Inspect

Latest or a single day's exchange rates. The raw-rate companion to convert. With provider, published rates from one or more institutions: on its own base the digits are as published, with the date they took effect.

ParametersJSON Schema
NameRequiredDescriptionDefault
baseNoISO 4217 base currency. Default EUR.
dateNoSingle day YYYY-MM-DD. Omit for the latest rates.
quotesNoISO 4217 quote codes to return; omit for all.
providerNoProvider key or keys, e.g. ECB or ['ECB', 'HMRC']. Serves published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/.
providersNoAlias for `provider` accepting multiple provider keys.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already mark this as read-only and open-world, so the bar is lower. The description adds behavioral detail beyond those hints, notably that provider-sourced digits are returned as published and carry the date they took effect, and that omitting date yields latest rates.

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?

Two sentences, front-loaded with the core action and scope, with every clause earning its place. It avoids repeating schema content.

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 five-parameter tool with no required fields and no output schema, the description plus rich schema descriptions give an agent enough to call it correctly. Minor gaps remain around what the response looks like and what 'latest' resolves to, but they are not blocking.

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 coverage is 100%, so the schema already documents all five parameters and their defaults/aliases. The description reinforces provider behavior but adds little beyond the schema's parameter descriptions, keeping this at the baseline for high coverage.

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 first sentence states the tool returns exchange rates for either the latest date or a single specified day. Calling itself the 'raw-rate companion to convert' directly distinguishes its scope from the convert sibling, so an agent can pick it correctly.

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 gives clear context that this tool supplies raw rates rather than conversion and that provider should be used when published institutional rates are needed. It does not spell out explicit when-not-to-use conditions or list the other sibling alternatives, but the main choice between get_rates and convert is clear.

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

list_currenciesList currenciesA
Read-only
Inspect

List all supported ISO 4217 currency codes and their full names (e.g. { 'USD': 'United States Dollar' }).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

The description adds format details beyond the annotations: it returns a mapping of code to name. Annotations already declare readOnlyHint and openWorldHint, which align. No contradictions.

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?

Single sentence, front-loaded with purpose, no fluff. Every word earns its place.

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?

Given zero parameters, full annotation coverage, and a simple return format described, the description is fully complete for this tool.

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?

There are no parameters, and the schema coverage is 100% (empty). The description provides meaning about the output format, which is the only semantic needed. Baseline 4 is appropriate.

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?

Description clearly states the tool lists all supported ISO 4217 currency codes with their full names, using a specific verb and resource. It distinguishes from siblings 'convert' and 'get_rates' by specifying enumeration rather than conversion or rate retrieval.

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?

The description implies the tool is used for retrieving the full set of supported currencies. While it does not explicitly state when not to use it or mention alternatives, the sibling context makes the usage clear. No exclusions are needed given the simple scope.

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

list_providersList providersA
Read-only
Inspect

List the institutions whose rates Frankfurter relays, with key, rate type, frequency (daily, monthly or quarterly) and coverage dates. Use a key as provider in convert or get_rates for that institution's published rates instead of the blend.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds behavioral context by specifying the data fields (key, rate type, frequency, coverage dates) and the relationship to the blend, which goes beyond the annotations. It doesn't mention pagination or rate limits, but for a zero-parameter list operation this is sufficient.

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?

Two sentences with no filler. The first sentence states the resource and output fields; the second provides actionable usage guidance. Every sentence earns its place and the most important information is front-loaded.

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 zero-parameter, read-only list tool with no output schema, the description is nearly complete. It explains what is returned and how to use the results. The only minor gap is that it doesn't explicitly state the output format (e.g., JSON array), but the absence of an output schema and the simplicity of the tool make this a minor omission.

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?

The tool has zero parameters, so the schema provides no parameter documentation. The description compensates by explaining what the returned 'key' field is for and how it should be used as a parameter in sibling tools. This adds meaning beyond the empty schema, though it doesn't need to document any input parameters.

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 states a specific verb ('List') and resource ('institutions whose rates Frankfurter relays'), and enumerates the exact fields returned (key, rate type, frequency, coverage dates). It also distinguishes itself from siblings by explaining how the key is used in convert/get_rates, so an agent can tell it apart from list_currencies.

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?

The description explicitly tells the agent when to use this tool: to obtain a provider key for use as the `provider` parameter in `convert` or `get_rates`. It also implies the alternative (using the default blend) and clarifies the purpose of the returned keys, which is strong usage guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedconvert1 field changed
      • changedInput schema / properties / provider / description
        Previous value: -"Provider key, e.g. UST for U.S. Treasury reporting rates. Serves that institution's published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/."New value: +"Provider key, e.g. ECB for European Central Bank or UST for U.S. Treasury reporting rates. Serves that institution's published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/."
    • Changedget_rates6 fields changed
      • changedInput schema / properties / provider / description
        Previous value: -"Provider key, e.g. UST for U.S. Treasury reporting rates. Serves that institution's published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/."New value: +"Provider key or keys, e.g. ECB or ['ECB', 'HMRC']. Serves published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/."
      • addedInput schema / properties / provider / items
        Added value: +{
+  "maxLength": 8,
+  "minLength": 2,
+  "type": "string"
+}
      • removedInput schema / properties / provider / maxLength
        Removed value: -8
      • removedInput schema / properties / provider / minLength
        Removed value: -2
      • changedInput schema / properties / provider / type
        Previous value: -"string"New value: +"array"
      • addedInput schema / properties / providers
        Added value: +{
+  "description": "Alias for `provider` accepting multiple provider keys.",
+  "items": {
+    "maxLength": 8,
+    "minLength": 2,
+    "type": "string"
+  },
+  "type": "array"
+}
  2. 3 tool updates
    • Changedconvert1 field changed
      • addedInput schema / properties / provider
        Added value: +{
+  "description": "Provider key, e.g. UST for U.S. Treasury reporting rates. Serves that institution's published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/.",
+  "maxLength": 8,
+  "minLength": 2,
+  "type": "string"
+}
    • Changedget_rates1 field changed
      • addedInput schema / properties / provider
        Added value: +{
+  "description": "Provider key, e.g. UST for U.S. Treasury reporting rates. Serves that institution's published rates instead of the blend; a date inside a monthly or quarterly provider's period returns the rate in force. Keys at https://frankfurter.dev/providers/.",
+  "maxLength": 8,
+  "minLength": 2,
+  "type": "string"
+}
    • Addedlist_providers
  3. 3 tool updates
    • Changedconvert2 fields changed
      • changedInput schema / properties / amount / description
        Previous value: -"Amount in the source currency."New value: +"Amount in the source currency. Normalize localized input first: '100,50' -> 100.5; German '1.000,50' -> 1000.5; English '1,000.50' -> 1000.5."
      • changedInput schema / properties / date / description
        Previous value: -"Historical date YYYY-MM-DD. Omit for latest."New value: +"Date YYYY-MM-DD for a past rate; omit for latest."
    • Changedget_rates5 fields changed
      • changedInput schema / properties / date / description
        Previous value: -"Single day YYYY-MM-DD. Mutually exclusive with start/end."New value: +"Single day YYYY-MM-DD. Omit for the latest rates."
      • removedInput schema / properties / end
        Removed value: -{
-  "$ref": "#/properties/date",
-  "description": "Range end YYYY-MM-DD (inclusive). Requires start and quotes."
-}
      • removedInput schema / properties / providers
        Removed value: -{
-  "description": "Provider keys. Omit for blended (default).",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
      • changedInput schema / properties / quotes / description
        Previous value: -"ISO 4217 quote codes. Required when start/end is set."New value: +"ISO 4217 quote codes to return; omit for all."
      • removedInput schema / properties / start
        Removed value: -{
-  "$ref": "#/properties/date",
-  "description": "Range start YYYY-MM-DD (inclusive). Requires end and quotes."
-}
    • Addedlist_currencies
  4. 2 tool updates
    • First observedconvert
    • First observedget_rates

Related MCP Connectors

Related MCP Servers

  • currency-exchange-mcp

    Ruddxxy
    A
    license
    Not graded
    quality
    D
    maintenance
    Real-time currency exchange rates and crypto prices via MCP. Convert between 60+ fiat currencies and 30+ cryptocurrencies with multi-source failover. No API keys needed for upstream data.
    9 npm
    ISC

  • Rate-API MCP Server

    Vilgar
    A
    license
    A
    quality
    C
    maintenance
    Enables MCP clients to access exchange rates for 160+ currencies, currency conversion, historical rates, time series, crypto, metal and stock prices, usage checks, and rate alerts.
    17
    1 npm
    MIT
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