Skip to main content
Glama

exchange-rates-mcp-server

Fx List Currencies

fx_list_currencies
Read-onlyIdempotent

List currently supported ISO 4217 currency codes with full names and as_of, the latest served rate date. Use this to disambiguate dollars (USD vs AUD vs CAD). Historical availability is checked against the requested historical snapshot or range and can include retired currencies absent from current discovery.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
as_ofNoLatest served daily rate date for this current-discovery list; historical availability is checked against historical data.
countNoTotal number of supported currencies.
errorNoPresent when the call failed. Absent on success.
sourceNoAlways "Frankfurter v1" — the upstream data provider.
currenciesNoAll supported currencies, sorted alphabetically by code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / anyOf
      Previous value: -[
      -  {
      -    "not": {
      -      "required": [
      -        "error"
      -      ]
      -    },
      -    "required": [
      -      "currencies",
      -      "count",
      -      "source"
      -    ]
      -  },
      -  {
      -    "required": [
      -      "error"
      -    ]
      -  }
      -]New value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "currencies",
      +      "count",
      +      "as_of",
      +      "source"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / as_of
      Added value: +{
      +  "description": "Latest served daily rate date for this current-discovery list; historical availability is checked against historical data.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / source / description
      Previous value: -"Always \"ECB via Frankfurter\" — the upstream data provider."New value: +"Always \"Frankfurter v1\" — the upstream data provider."
  2. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "currencies",
      +      "count",
      +      "source"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / error
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "Present when the call failed. Absent on success.",
      +  "properties": {
      +    "code": {
      +      "description": "JSON-RPC error code for this failure.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "data": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "reason": {
      +          "description": "Machine-readable failure mode.",
      +          "type": "string"
      +        },
      +        "recovery": {
      +          "additionalProperties": {},
      +          "description": "Actionable next step for the caller.",
      +          "properties": {
      +            "hint": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "hint"
      +          ],
      +          "type": "object"
      +        },
      +        "retryable": {
      +          "description": "Whether retrying may succeed.",
      +          "type": "boolean"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "message": {
      +      "description": "Human-readable description of what went wrong.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "code",
      +    "message"
      +  ],
      +  "type": "object"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "currencies",
      -  "count",
      -  "source"
      -]
  3. First observed

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, idempotency and open-world behavior, and the description adds non-obvious context: results are scoped to the 'latest served rate date' (as_of) and historical lookups can surface retired currencies absent from current discovery. That caveat is genuinely useful. It stops short of describing snapshot/range staleness behavior.

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-loaded with the core action and return shape, then the disambiguation guidance in the second sentence. The third sentence about historical availability is a slight topic shift and is wordier than necessary, but it carries real caveat value.

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?

An output schema exists, so return-shape detail is not required, and the description still names the key fields (code, full name, as_of). Combined with the historical-scope caveat, an agent has what it needs to call this correctly; only the snapshot/range scoping mechanics remain implicit.

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 takes zero parameters, so the baseline is 4; there is no parameter surface to document and the description does not waste space inventing one.

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?

States a specific verb ('List') and resource ('currently supported ISO 4217 currency codes') plus the returned fields (full names, as_of). It is clearly distinguishable from the rate/conversion siblings, which all operate on specific pairs rather than discovery.

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 an explicit use case ('use this to disambiguate dollars (USD vs AUD vs CAD)'), which tells an agent when to prefer this over fx_get_rate or fx_convert_currency. No when-not-to-use or prerequisite conditions are stated, keeping it below a 5.

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.