Skip to main content
Glama

Frankfurter

by io.github.lineofflight
OverviewDiscussionsAdmin

Get exchange rates

get_rates
Read-only

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.

Input Schema

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema 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. Changed1 schema 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"
+}
  3. Changed5 schema 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."
-}
  4. First observed

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.

All Frankfurter 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