Skip to main content
Glama

converters_exchange_rates

Read-onlyIdempotent

Exchange rates: daily reference rates for about 200 currencies, crypto and metals, with ECB fallback and ECB history (reference rates, not live)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "converters_exchange_rates"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoCurrency code, or a list of up to 20 codes, to convert to. Required unless listCurrencies is true.
dateNoA past date, YYYY-MM-DD: the daily rate for that day (ECB set: the latest earlier working day if none was published).
fromNoCurrency code to convert from (default USD): ISO codes such as USD, plus crypto and metal codes in the broad set.
amountNoAmount to convert (default 1).
sourceNoauto (default): the broad daily set of about 200 currencies, crypto and metals, falling back to the ECB set; broad: only the broad set; ecb: only the ECB set (about 30 currencies, and the only one with history ranges).
endDateNoHistory: last day of the range.
startDateNoHistory: first day of a range of up to 366 days (send with endDate).
listCurrenciesNotrue returns the supported currency codes (with type and name) and the date of the latest rates.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / date / description
      Previous value: -"A past date, YYYY-MM-DD: the ECB rate for that day (the latest earlier working day if none was published)."New value: +"A past date, YYYY-MM-DD: the daily rate for that day (ECB set: the latest earlier working day if none was published)."
    • changedInput schema / properties / from / description
      Previous value: -"Three-letter currency code to convert from (default USD)."New value: +"Currency code to convert from (default USD): ISO codes such as USD, plus crypto and metal codes in the broad set."
    • changedInput schema / properties / listCurrencies / description
      Previous value: -"true returns the supported currency codes and the date of the latest rates."New value: +"true returns the supported currency codes (with type and name) and the date of the latest rates."
    • addedInput schema / properties / source
      Added value: +{
      +  "description": "auto (default): the broad daily set of about 200 currencies, crypto and metals, falling back to the ECB set; broad: only the broad set; ecb: only the ECB set (about 30 currencies, and the only one with history ranges).",
      +  "enum": [
      +    "auto",
      +    "broad",
      +    "ecb"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already mark the tool read-only, idempotent, non-destructive and open-world. The description adds meaningful context beyond annotations by disclosing that rates are daily reference rates, not live, and that there is ECB fallback and ECB history. It does not mention rate limits or response shape, but the annotations carry much of the safety burden.

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 a single, front-loaded sentence with no wasted words. It packs the key scope, coverage, fallback behavior and freshness constraint into one readable line.

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 an eight-parameter read-only tool with full schema coverage, rich annotations and no output schema, the description is mostly complete. It could say more about the response structure, but the schema and annotations cover the calling mechanics and safety profile well enough.

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 description coverage is 100%, so all eight parameters are already documented in the schema. The description adds high-level context about the broad set, ECB fallback and history but does not add parameter-specific semantics beyond what the schema provides. This meets the baseline 3 for a fully documented schema.

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?

The description states a specific resource and scope: daily reference exchange rates for about 200 currencies, crypto and metals, including ECB fallback and history, explicitly noting they are not live. It is clear what the tool returns, though it does not directly distinguish itself from the sibling convert_currency tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains capabilities but gives no explicit when-to-use guidance or alternatives. It does not say when to prefer this over convert_currency, nor does it specify exclusions beyond the parenthetical 'not live' note.

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.

Resources