Convert currencies on the daily European Central Bank reference rates. No API key, no signup.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 10 tools
The currency tools are clearly differentiated by scope: convert for single conversions, convert_many for bulk conversions, rate_on for a single rate, rate_history for historical windows, and rates_latest for current rates. The license tools are distinct. Some overlap exists between rate_on and rates_latest, but their purposes are sufficiently separated.
Tool names are mixed: some follow verb_noun (convert, license_activate), others are noun_noun (cache_status, currencies_list), and one is prepositional (fx_rates_for). While readable, the inconsistency in naming patterns reduces predictability.
10 tools is well within the ideal range for a domain-specific server, covering conversion, rates, history, and licensing without unnecessary bloat. Each tool has a clear purpose.
The currency domain is well covered with latest rates, historical rates, conversion, bulk conversion, and currency listing. A minor gap is the lack of a tool to retrieve all rates for a specific historical date, but existing tools can work around this. License management is also complete.
Report the ECB rate cache here: which dates are held, how old they are and when they refresh. Reads only. Check it before trusting a rate after time offline; a cache that no longer parses is quarantined and named.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those: the cache can become unparsable and 'quarantined and named', and the tool reports refresh timing. This enriches the agent's understanding of cache health without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the primary purpose, then adds the when-to-use hint and the quarantine caveat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only status tool, the description is complete: it states what is reported, when to check it, and a key failure behavior. No output schema exists, but the description does not need to enumerate return fields for an agent to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to clarify. Per baseline for zero-parameter tools, a score of 4 is appropriate; the description correctly focuses on the tool's no-input status behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Report') and resource ('ECB rate cache'), and details exactly what is reported: held dates, age, and refresh timing. It clearly distinguishes this cache-status tool from sibling rate-conversion and rate-query tools like rates_latest and rate_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use the tool: 'Check it before trusting a rate after time offline.' It also explains the quarantine behavior. It does not explicitly state when not to use it or name alternatives, but the usage trigger is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool to convert an amount between any two ECB-quoted currencies, today or on a past date. Returns the converted amount, the cross rate to 6 decimals, the rounding applied and the rate date used.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Currency to convert into; defaults to the shared business profile's default_currency, so you are never asked what currency you invoice in. The result is rounded once, at the end, to this currency's own ISO 4217 minor units, so JPY comes back whole and BHD to three places | |
| date | No | ISO date YYYY-MM-DD. Omit for the latest published rate. A weekend or TARGET holiday falls back to the last rate published on or before it, and the answer says so. A date older than the free 90-day window is shortened to the oldest free day, not refused, and the answer names the date it really used | |
| from | Yes | Currency the amount is in. Cross rates go through the euro, the only pair the ECB publishes | |
| amount | Yes | Amount in major units of the from currency, e.g. 100 or 12.34 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the all-false annotations, the description discloses exact return behavior: converted amount, cross rate to six decimals, rounding applied, and the rate date used. It stops short of discussing side-effect/read-only status, but for a conversion tool this is a meaningful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first names the action and scope, the second lists the return details. Every clause contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description's return-value enumeration is valuable and mostly complete. The rich parameter schema covers date fallback and rounding rules; the only gap is explicit routing versus convert_many for multi-currency batches.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already fully documented in the input schema. The description adds no parameter-level meaning beyond what the schema provides, which lands at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: convert an amount between ECB-quoted currencies. It also distinguishes from the convert_many sibling by focusing on a single amount, and from rate-focused siblings by emphasizing conversion output rather than raw rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase 'Call this tool to convert an amount...' gives a clear when-to-use trigger. It does not explicitly name alternatives like convert_many or state when not to use it, but the context is unambiguous enough to avoid misrouting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert one amount into many currencies off the SAME ECB rate date, each rounded to its own minor units. For several lines at once (mixed-currency invoice lines), call it once per line: every line then shares one rate date. Unknown targets are listed, never failed.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target currencies | |
| from | Yes | ||
| amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: same ECB rate date, rounding to each target's own minor units, and unknown targets being listed rather than causing failure. The annotations are all false and uninformative, so the description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler: core behavior is front-loaded, usage guidance follows, and the edge-case behavior is stated last. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse annotations, the description covers rate-date consistency, rounding, error handling, and batch usage. It does not mention source-currency failure behavior or the response shape, but these are secondary for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% because only 'to' has a description. The description partially compensates by explaining the amount, the target currencies, and rounding behavior, but it leaves 'from' semantics and amount units implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('convert'), the resource ('one amount into many currencies'), and a distinctive constraint (same ECB rate date, per-target minor-unit rounding). It also distinguishes this tool from sibling convert by emphasizing multi-currency and batch use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete when-to-use guidance: for mixed-currency invoice lines, call once per line so all lines share one rate date. It does not explicitly name convert as the alternative, but the usage context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every currency in the ECB daily set with its rate against the euro and its decimal places. This is the whole domain: a code not on this list cannot be converted, quoted or historised here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context beyond those: the result is the complete closed domain, contains rates and decimal places, and acts as an authoritative filter for other operations. This meaningfully complements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The first sentence states what the tool returns and the second immediately gives the operational implication. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool, the description is complete: it states the content, the scope, and the practical consequence for other tools. There is no output schema, but the description tells an agent enough about what to expect (currencies, rates, decimal places) to invoke and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema documents that fully, so there is nothing parameter-related to explain. The description correctly focuses on the returned content instead. The baseline of 4 applies because the schema already covers the complete parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (the ECB daily currency set), the content (rate against the euro and decimal places), and the scope (the whole domain). It also differentiates from sibling conversion/history tools by stating that any code not on this list cannot be used elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to enumerate the complete set of valid currencies or validate whether a code is supported. It does not explicitly name sibling alternatives like convert or rate_history, but the domain-boundary statement ('a code not on this list cannot be converted, quoted or historised here') gives strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | The 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 | |
| currencies | Yes | The 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the disclosure burden. It does describe the return behavior (fx_rates object plus rate date), which is useful, but it does not mention whether rates are freshly fetched, whether external calls/failures are possible, or that the operation has no side effects. Acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The trigger condition is front-loaded, and every phrase adds value: when to call, what not to do, and what to expect back.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with fully documented schema, the description adds the missing context: the multi-currency invoicing scenario and the shape of the return value. With no output schema, a bit more detail on the exact fx_rates object structure could help, but the cross-reference to expense_to_invoice and the rate date is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including the direction semantics of currencies and the meaning of target. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states when the tool applies (rebill/invoice spanning multiple currencies) and what it produces (the fx_rates object expense_to_invoice takes, plus the rate date). It does not name sibling alternatives, so it stops short of fully explicit differentiation, but the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger condition — 'when a rebill or an invoice spans more than one currency' — and an explicit alternative to avoid: asking the user for rates. It does not name sibling tools like convert or rates_latest, so exclusion guidance is contextual rather than exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool for the ECB rate of one currency pair across a window. Returns one row per published day plus the min, max, average and the change. A window wider than the free 90 days is shortened, not refused.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Quote currency of the pair. Each row is 1 from = X to | |
| days | No | Trailing window in calendar days, default 30. Only TARGET business days carry a rate, so 30 days holds about 21 rows. Free reads up to 90 days back; Pro reads the whole series back to 1999-01-04 | |
| from | Yes | Base currency of the pair | |
| to_date | No | ISO date, inclusive, default today | |
| max_rows | No | Cap the table, default 200. min/max/avg still cover the whole window | |
| from_date | No | ISO date, inclusive. Overrides days. Free is limited to the last 90 days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All annotations are false, so the description carries the full burden of behavioral disclosure. It adds genuinely useful behavior: one row per published day, summary statistics, and an over-wide window being shortened rather than refused. It does not explicitly state that this is read-only, but the description gives no hint of mutation either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, each earning its place: purpose, output shape, and edge-case behavior. The most important information is front-loaded, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description covers the core contract: what the tool returns, how it behaves on broad windows, and what data source it uses. It is slightly light on sibling differentiation and the exact meaning of 'change', but the rich input schema closes most remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters in detail. The description adds useful context about trailing windows and the free 90-day limit, but it does not provide parameter-level meaning beyond what the schema already covers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource combination: 'ECB rate of one currency pair across a window.' It also names the exact return shape (daily rows plus min/max/avg/change), which clearly distinguishes it from siblings like rates_latest and rate_on. This is more than adequate for an agent to understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening line 'Call this tool for...' gives an implied usage context: historical rate queries with summary statistics. However, it never names alternatives or states when not to use this tool, so an agent must infer its position among siblings like rate_on and rates_latest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool for the ECB rate of one pair on one date. Returns both directions and the rate date, so a reciprocal is never reported as the published figure. A date beyond the free window is shortened, never refused.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Quote currency. The rate returned is 1 from = X to | |
| date | Yes | ISO date YYYY-MM-DD. If the ECB published nothing that day - every weekend, 1 January, Good Friday, Easter Monday, 1 May, 25 and 26 December - the last rate published on or before it is returned and the answer names that date. Free covers the last 90 days: an older date is shortened to the oldest free day rather than refused, and rate_date says which day the numbers are really from. Pro covers every date back to 1999-01-04 | |
| from | Yes | Base currency. The ECB quotes every currency per 1 euro, so "the ECB rate for USD" is from EUR to USD, not the other way round; invert only if the user asked for the inverse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false/absent, so the description carries the full burden. It discloses the key behavioral traits: returns both directions, never reports a reciprocal as the published figure, shortens out-of-window dates instead of refusing, and names the actual rate date. It also explains the free-window cutoff and Pro coverage. This is rich, non-obvious behavior that an agent needs to know before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the tool's purpose, the second clarifies the return behavior, and the third covers edge cases. Every sentence earns its place, and the parameter descriptions in the schema carry the detailed semantics without bloating the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description plus schema covers everything an agent needs: what the tool returns, how dates are handled, the free-window limitation, and the currency convention. The sibling list provides enough contrast to avoid confusion with rate_history or rates_latest. No critical gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains the ECB convention (quotes every currency per 1 euro), warns that 'the ECB rate for USD' means from EUR to USD, and clarifies that the date parameter's fallback behavior. The only reason it's not a 5 is that the schema already documents the parameters thoroughly, so the description's added value is complementary rather than essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Call this tool for'), a precise resource ('the ECB rate of one pair on one date'), and immediately distinguishes it from siblings like rate_history and rates_latest by scoping it to a single pair and a single date. It also clarifies the return shape ('both directions and the rate date'), which removes ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call this tool ('for the ECB rate of one pair on one date') and implicitly contrasts with siblings that handle multiple dates or multiple pairs. It also gives concrete behavioral guidance: a reciprocal is never reported as the published figure, and older dates are shortened rather than refused. This is enough for an agent to select it over rate_history or rates_latest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool for the latest ECB daily reference rates against any base: 1.0812 for USD means 1 base = 1.0812 USD. Crosses go through the euro. Returns the ECB rate date and the cache age.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency; defaults to the shared business profile's default_currency, else EUR. A rate of 1.0812 for USD means 1 base = 1.0812 USD. Cross rates go through the euro, the only pair the ECB publishes | |
| quotes | No | Only these currencies, at most 200. Omit for all of them |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool to be read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds important behavioral details: cross rates are computed through the euro, and the response includes the ECB rate date and cache age. This provides context beyond the annotations that helps an agent interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured: the first sentence states the purpose and key interpretation, the second conveys additional behavioral details. Every sentence earns its place, with no redundant or filler content. The rate example is compact and immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters, the description covers the essential context: when to use it, how rates are expressed, and what the response includes. There is no output schema, but the description partially compensates by mentioning the returned fields. It could mention edge cases like invalid base currencies, but this is minor given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters, including the base/quote interpretation and the 'omit quotes for all' behavior. The description largely repeats this information, adding no new semantic detail beyond what is in the schema. With schema coverage at 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fetching the latest ECB daily reference rates against any base currency. It uses a specific verb ('call this tool for'), names the resource ('ECB daily reference rates'), and clarifies the rate interpretation with an example. This distinguishes it from sibling tools focused on historical rates or conversions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this tool when you need the latest ECB reference rates. It does not explicitly mention alternatives or exclusions, but the phrase 'latest ... rates' implies a contrast with historical rate tools like rate_history or rate_on. No conflicting guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cache_statusconvertconvert_manycurrencies_listfx_rates_forlicense_activatelicense_statusrate_historyrate_onrates_latestConvert currencies on the daily European Central Bank reference rates. No API key, no signup.
Convert currencies on the daily European Central Bank reference rates. No API key, no signup.
Convert currencies, get FX rates, and query historical ECB exchange rate data.
Free, keyless real-time currency conversion and exchange rates for any currency pair.
Add one secure layer between your agents and this server.