Skip to main content
Glama

FX rates in the shape expense-tracker wants

fx_rates_for

Retrieves current exchange rates for specified currencies against a target currency, providing the rate date to use when invoicing across multiple currencies.

Instructions

Call this tool when a rebill or an invoice spans more than one currency, instead of asking the user for rates. Returns the fx_rates object expense_to_invoice takes, plus the rate date to write on the invoice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoThe currency the invoice will be issued in; defaults to the shared business profile's default_currency. Pass it on as target_currency alongside the fx_rates object
currenciesYesThe other currencies present, e.g. ["EUR", "GBP"]. Direction: each returned rate means 1 unit of that key = X units of the target, so {"EUR": 1.08} is 1 EUR = 1.08 of the target. The target needs no rate of its own

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses the return value and its purpose, but does not explicitly state read-only/non-mutating behavior, rate source, freshness, or error conditions. It is adequately transparent for a lookup, but not exhaustive.

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 compact sentences, front-loaded with when to use, followed by the return contract. No filler or redundancy.

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 simple two-parameter read tool with a thorough schema, the description covers when to call it and what it returns. The main gap is that the output shape is defined only by reference to 'expense_to_invoice', which may be ambiguous if that concept isn't known to the agent.

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%, with good detail about target, currencies, direction, and defaults. The description adds no additional parameter meaning beyond what the schema already explains, so baseline 3 applies.

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?

clear and specific: it is a call-to-get FX rates for multi-currency invoices/rebills, returning a shaped object and rate date. It does not explicitly contrast itself with sibling rate tools like rates_latest or convert, so it stops short of full sibling differentiation.

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 trigger condition (rebill or invoice spans more than one currency) and an explicit alternative (asking the user for rates). It lacks comparison to sibling FX rate tools, so it doesn't fully cover when-not-to-use cases.

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

Install Server

Other Tools