Skip to main content
Glama

Exchange Rates

query_exchange_rates
Read-only

Queries the latest available reference exchange rates for currency conversion and cross-currency analysis. Prefer this tool before converting or combining Tool4seller monetary results in different currencies. Request all required currencies together for one rate snapshot. Rates express target-currency units per one unit of base; multiply source amount by rate. Do not reconvert amounts already in the target currency. Historical and settlement rates are not supported. timestamp is source publication time in Unix seconds, or null if unavailable; rates may differ from earlier report snapshots.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "base": "<base>",
      "symbols": "<symbols>"
    },
    "name": "query_exchange_rates"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseYesRequired three-letter base currency, e.g. USD. No default.
symbolsYesRequired target currency codes. Case insensitive; duplicates are removed.

Output Schema

NameRequiredDescriptionDefault
baseNo
ratesNo
timestampNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered; the description adds genuinely non-obvious behavior: rates may differ from earlier report snapshots, historical/settlement rates are unavailable, and timestamp is Unix seconds or null. It stops short of stating the rate source, refresh cadence, or what happens when a requested symbol is unsupported.

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?

Six short sentences, front-loaded with purpose, then preference rule, then batching, then rate orientation, then exclusions, then timestamp caveat. Every sentence carries a distinct actionable fact with no restatement of the name or schema.

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?

Output schema exists so return values need not be explained, and the remaining burden — orientation of the rate, staleness, unsupported rate classes, timestamp encoding — is all addressed. Nothing an agent needs to call this correctly and interpret the result is missing.

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 baseline is 3; the description earns above that by defining the directionality of the pair ('target-currency units per one unit of base; multiply source amount by rate') and by advising that all symbols be requested in one call. The 20-item cap and case-insensitivity stay in the schema only, which is fine.

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 and resource — 'queries the latest available reference exchange rates' — with the scope qualifier 'latest available' and the two intended uses (currency conversion, cross-currency analysis). No sibling tool covers FX, and the description makes that boundary explicit by framing it as the prerequisite for combining monetary results.

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?

Gives explicit when-to-use routing ('Prefer this tool before converting or combining ... monetary results in different currencies'), a batching rule ('Request all required currencies together for one rate snapshot'), a do-not rule ('Do not reconvert amounts already in the target currency'), and hard exclusions ('Historical and settlement rates are not supported'). That is a rare level of when/when-not/alternative coverage.

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