Convert currencies, get FX rates, and query historical ECB exchange rate data.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 7 of 7 tools scored.
Each tool serves a distinct purpose: conversion, rate lookup, bulk rates, timeseries, listing, and DataCanvas management. Descriptions explicitly differentiate between similar tools (e.g., fx_convert_currency vs fx_get_rate). No ambiguity.
All tools follow a consistent 'fx_verb_noun' pattern. Verbs are specific (convert, get, list, describe, query) and nouns clearly indicate the resource (currency, rate, rates, timeseries, dataframe).
Seven tools cover the core functionality of an exchange rates server without excess. The count is well-scoped for the domain, providing necessary CRUD-like operations and advanced querying via DataCanvas.
The tool set covers all essential operations: listing currencies, getting current rates, bulk rates, conversion, historical timeseries, and SQL-based analysis of large datasets. No obvious gaps for the intended use case.
fx_convert_currencyFx Convert CurrencyAConvert an amount between any two currencies at the latest or a historical rate. Returns the converted amount, the rate used, the actual rate date, and whether the date was snapped from a weekend/holiday to the prior business day. Cross-rates are triangulated through EUR automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO 8601 date (YYYY-MM-DD) for a historical rate. Omit for the latest available rate. ECB data starts 1999-01-04. Future dates are not supported. | |
| amount | Yes | Amount in the base currency to convert. Must be greater than zero. | |
| base_currency | Yes | ISO 4217 source currency code (e.g. USD). Call fx_list_currencies to get valid codes. | |
| quote_currency | Yes | ISO 4217 target currency code (e.g. EUR). The amount will be expressed in this currency. |
| Name | Required | Description |
|---|---|---|
| rate | Yes | Exchange rate used: units of quote currency per 1 unit of base currency. |
| source | Yes | Always "ECB via Frankfurter" — the upstream data provider. |
| rate_date | Yes | Actual date of the rate used for conversion. |
| rate_type | Yes | Always "ECB reference (mid-market)" — these are reference rates, not tradeable bid/ask. |
| base_amount | Yes | The input amount in the base currency. |
| date_snapped | Yes | True when the API returned a different date than requested — ECB silently snaps weekend/holiday requests to the prior business day. |
| quote_amount | Yes | The converted amount in the quote currency, rounded to 6 decimal places. |
| base_currency | Yes | Source currency code. |
| quote_currency | Yes | Target currency code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnly/idempotent annotations by disclosing specific behavior: date snapping from weekends/holidays, triangulation through EUR, and the ability to use historical or latest rates. This gives the agent actionable expectations for edge cases.
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 long, front-loads the core action, and packs essential details (returns, triangulation) without any fluff. Every word 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?
The tool has an output schema and rich annotations, so the description only needs to cover key behavioral nuances. It does so by explaining date snapping, triangulation, and the nature of the returned data. No critical gaps remain for a conversion tool.
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 input schema covers all four parameters with clear descriptions, so the description's added value is limited. It does mention 'latest or historical rate' for the date parameter and 'any two currencies' for the currency codes, but these are minor extensions of the schema, not substantial new meaning.
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 ('Convert') with a clear resource ('an amount between any two currencies') and scope ('latest or historical rate'). It distinguishes from sibling rate-lookup tools by focusing on conversion rather than rate retrieval, and even previews the return values.
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 context for use is clear: converting amounts rather than just querying rates. It also gives a helpful pointer to fx_list_currencies for valid currency codes. However, it does not explicitly state when not to use this tool or name alternative tools like fx_get_rate or fx_get_timeseries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fx_dataframe_describeFx Dataframe DescribeAList tables and columns staged on a DataCanvas from a prior fx_get_timeseries call. Required first step before fx_dataframe_query — use it to discover table names and column schemas. Requires DataCanvas (CANVAS_PROVIDER_TYPE=duckdb) — without it this tool is not listed at all and fx_get_timeseries returns every range inline.
| Name | Required | Description | Default |
|---|---|---|---|
| canvas_id | Yes | Canvas ID returned by fx_get_timeseries. Re-run fx_get_timeseries to obtain a fresh canvas_id if this one has expired. |
| Name | Required | Description |
|---|---|---|
| tables | Yes | All tables and views currently staged on this canvas. |
| canvas_id | Yes | The canvas ID echoed back — use this in fx_dataframe_query. |
| expires_at | Yes | ISO 8601 timestamp when this canvas will be evicted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint false, and idempotentHint. The description adds valuable behavioral context beyond annotations: it requires DataCanvas (CANVAS_PROVIDER_TYPE=duckdb) and reveals that without it the tool is absent from listings. This gives the agent important operational nuance, although it doesn't detail return format—but that's covered by the output schema.
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 long, front-loads the core purpose, and every phrase contributes value. It avoids redundancy and is well-structured for quick parsing.
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 tool with one parameter, a rich output schema, and strong annotations, the description fully covers the tool's role, prerequisites, and relationship to siblings. It explains the prerequisite (DataCanvas), the dependency on fx_get_timeseries, and the fallback behavior, making the tool's context complete.
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 coverage is 100%, with the canvas_id parameter fully described in the input schema. The description's mention of 'canvas_id returned by fx_get_timeseries' adds no additional meaning beyond the schema's own description. Thus, 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 clearly states the tool's function: 'List tables and columns staged on a DataCanvas from a prior fx_get_timeseries call.' It uses a specific verb ('List') and resource ('tables and columns'), and distinguishes itself from the sibling fx_dataframe_query by positioning itself as the required first step for schema discovery.
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 use the tool: 'Required first step before fx_dataframe_query — use it to discover table names and column schemas.' It also explains the alternative behavior (if DataCanvas is absent, the tool isn't listed and fx_get_timeseries returns inline), providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fx_dataframe_queryFx Dataframe QueryARun a read-only SQL SELECT against DataCanvas tables staged by fx_get_timeseries. Supports aggregations, GROUP BY, window functions, and JOINs across multiple registered tables. Run fx_dataframe_describe first to discover table names and column schemas. Requires DataCanvas (CANVAS_PROVIDER_TYPE=duckdb) — without it this tool is not listed at all and fx_get_timeseries returns every range inline.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Read-only SQL SELECT statement. Reference tables by the names returned by fx_dataframe_describe or the table_name field from fx_get_timeseries. Example: SELECT date, rate FROM fx_usd_eur WHERE date > '2024-01-01' ORDER BY date | |
| canvas_id | Yes | Canvas ID returned by fx_get_timeseries. Re-run fx_get_timeseries to obtain a fresh canvas_id if this one has expired. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | Result rows, capped at the canvas row limit (default 10 000). Each key is a column name from the query. |
| canvas_id | Yes | The canvas ID used — pass to a subsequent fx_dataframe_query or fx_dataframe_describe call. |
| row_count | Yes | Rows returned. Equals the materialized row count; when truncated is true this is the row cap, not the full result size. Narrow the SELECT (add WHERE/LIMIT or aggregate) to see all rows. |
| truncated | Yes | True when the query produced more rows than the canvas row cap and the result was capped. Refine the query to materialize the complete result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description reinforces read-only nature and adds valuable context about environment prerequisites and the consequence of missing DataCanvas, which goes beyond 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?
The description is three sentences, front-loaded with the core action, then supporting features, then usage context. Every sentence earns its place with no repetition or fluff.
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 the output schema exists and the tool is complex (SQL querying), the description covers prerequisites, dependencies, and typical workflow. It is fully sufficient without explaining return values due to the output schema.
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 baseline is 3. The main description does not add deep parameter-level detail beyond what the schema already provides, though it hints at using fx_dataframe_describe for table discovery. No significant extra meaning is added.
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 runs a read-only SQL SELECT against DataCanvas tables staged by fx_get_timeseries, naming specific capabilities (aggregations, GROUP BY, window functions, JOINs). This differentiates it from siblings like fx_get_timeseries and fx_dataframe_describe.
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?
Provides explicit guidance: run fx_dataframe_describe first to discover table schemas, and notes the hard dependency on DataCanvas (DUCKDB) including behavior when unavailable. This gives clear context for when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fx_get_rateFx Get RateAGet the exchange rate for a currency pair on a given date (default: latest). Returns the rate, the actual rate date (which may differ from the requested date on weekends/holidays — ECB publishes business days only), and source provenance. Cross-rates are triangulated through EUR automatically. A same-currency pair returns a rate of 1, dated to the same publication day any other pair would report for that date. Use fx_convert_currency when you want the converted amount; use this tool when you only need the rate number.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO 8601 date (YYYY-MM-DD). Omit for the latest available rate. ECB data starts 1999-01-04. Future dates are not supported. | |
| base_currency | Yes | ISO 4217 base currency code (e.g. USD). Call fx_list_currencies to get valid codes. | |
| quote_currency | Yes | ISO 4217 quote currency code (e.g. EUR). The rate is expressed as "how many quote units per 1 base unit". |
| Name | Required | Description |
|---|---|---|
| rate | Yes | Exchange rate: units of quote currency per 1 unit of base currency. |
| source | Yes | Always "ECB via Frankfurter" — the upstream data provider. |
| rate_date | Yes | Actual date of the rate returned. |
| rate_type | Yes | Always "ECB reference (mid-market)" — these are reference rates, not tradeable bid/ask. |
| date_snapped | Yes | True when the API returned a different date than requested — ECB silently snaps weekend/holiday requests to the prior business day. |
| base_currency | Yes | The base currency code. |
| quote_currency | Yes | The quote currency code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent, and the description adds non-obvious behaviors: rate date may differ on weekends/holidays, cross-rates are triangulated via EUR, and same-currency pairs return 1. These complement the annotations without contradiction.
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 four focused sentences with no redundancy, front-loaded with the main purpose, and each sentence adds value for selection and invocation.
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 rich annotations, full schema coverage, an output schema, and explicit usage guidance, the description covers edge cases (weekend dates, same-currency pairs) and source provenance, making it complete 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 coverage is 100%, so the baseline is 3. The description adds context about the default date and triangulation, but most parameter meaning is already in the schema, so minimal added value.
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 'Get the exchange rate for a currency pair on a given date' with a specific verb and resource scope, distinguishing it from fx_convert_currency by noting when to use this tool instead.
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?
Explicitly provides an alternative: 'Use fx_convert_currency when you want the converted amount; use this tool when you only need the rate number.' Also explains the default date behavior and business-day handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fx_get_ratesFx Get RatesAGet all available exchange rates for one base currency in a single snapshot. Useful for bulk comparison and seeding downstream tools. Returns a map of quote currency → rate plus the snapshot date. Optionally filter to a subset of quote currencies via symbols. Listing the base currency itself in symbols is accepted and returns a rate of 1 for it.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO 8601 date (YYYY-MM-DD). Omit for the latest available rate. ECB data starts 1999-01-04. Future dates are not supported. | |
| symbols | No | Optional list of quote currency codes to filter the response. Omit to return all ~30 supported currencies (the base is not among them). Including base_currency here is valid — it comes back with a rate of 1. | |
| base_currency | Yes | ISO 4217 base currency code (e.g. USD). Call fx_list_currencies to get valid codes. |
| Name | Required | Description |
|---|---|---|
| rates | Yes | Map of quote currency code → exchange rate (units of quote per 1 base). |
| source | Yes | Always "ECB via Frankfurter" — the upstream data provider. |
| rate_date | Yes | Actual date of the rates. May differ from requested date on weekends/holidays — ECB publishes business days only; the API silently snaps to the prior business day. |
| rate_type | Yes | Always "ECB reference (mid-market)" — these are reference rates, not tradeable bid/ask. |
| base_currency | Yes | The base currency code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by specifying the return format ('map of quote currency → rate plus the snapshot date'), optional filtering via symbols, and the edge case that including base_currency returns a rate of 1. This goes beyond the annotations without contradicting them.
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 five sentences, but every sentence provides distinct value: purpose, use case, return shape, filtering, and the special symbol behavior. It is front-loaded with the core purpose and contains no fluff.
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 the simple nature of the tool, the output schema, and the strong annotations, the description fully covers behavior and usage context. It even includes the edge case for base_currency in symbols, leaving no obvious 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?
The schema provides 100% coverage for all three parameters, including detailed descriptions for symbols and base_currency. The description mostly restates these schema details, adding little new meaning, so the baseline 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 starts with 'Get all available exchange rates for one base currency in a single snapshot,' which clearly specifies a unique action and scope. It differentiates from siblings like fx_get_rate (single rate) and fx_get_timeseries (historical series) by emphasizing 'all available' and 'single snapshot.'
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 says 'Useful for bulk comparison and seeding downstream tools,' giving clear context for when to use this tool. However, it does not explicitly mention alternatives, such as using fx_get_rate for a single pair, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fx_get_timeseriesFx Get TimeseriesAGet historical daily exchange rates for a currency pair over a date range. ECB publishes on business days only — weekends and holidays produce no entry, and no date outside the requested range is ever returned, so a range covering only non-publication days comes back with an empty rates map and a notice explaining why. A same-currency pair returns a rate of 1 on each publication day in the range. Short ranges (≤90 days by default) are returned inline as a date→rate map. When DataCanvas is enabled (CANVAS_PROVIDER_TYPE=duckdb) long ranges spill to it: the response carries spilled=true, a canvas_id, and a table_name — call fx_dataframe_describe to inspect the staged table, then fx_dataframe_query to run SQL against it. Without DataCanvas long ranges stay inline (spilled=false) and the notice says so.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | ISO 8601 end date (YYYY-MM-DD). Must be >= start_date. Future dates are not supported. | |
| canvas_id | No | Optional canvas ID from a prior call. Omit on the first call to start a fresh canvas; pass the returned canvas_id to append tables to an existing canvas. | |
| start_date | Yes | ISO 8601 start date (YYYY-MM-DD). ECB data starts 1999-01-04. The actual first data point may be later if start_date falls on a weekend/holiday. | |
| base_currency | Yes | ISO 4217 base currency code (e.g. USD). Call fx_list_currencies to get valid codes. | |
| quote_currency | Yes | ISO 4217 quote currency code (e.g. EUR). Call fx_list_currencies to get valid codes. |
| Name | Required | Description |
|---|---|---|
| rates | Yes | Date → rate map for the inline result. Publication days inside the requested range only. Truncated to a preview when the result was spilled to canvas; empty when the range contains no publication day at all. |
| notice | No | Explains a result that would otherwise look broken — an empty series, or a long range that stayed inline because DataCanvas is not configured. |
| source | Yes | Always "ECB via Frankfurter" — the upstream data provider. |
| spilled | Yes | True when the full result was staged on the DataCanvas (range exceeded threshold). |
| end_date | Yes | Last date in the returned series. Always inside the requested range — earlier than the requested end when that day had no ECB fix, and equal to it when the series is empty. |
| canvas_id | No | Canvas ID — present when spilled is true. Pass to fx_dataframe_query. |
| rate_type | Yes | Always "ECB reference (mid-market)" — these are reference rates, not tradeable bid/ask. |
| rate_count | Yes | Total number of data points (publication days) inside the requested range. |
| start_date | Yes | First date in the returned series. Always inside the requested range — later than the requested start when that day had no ECB fix, and equal to it when the series is empty. |
| table_name | No | Canvas table name — present when spilled is true. Use in fx_dataframe_query SQL. |
| base_currency | Yes | Base currency code. |
| quote_currency | Yes | Quote currency code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint, and the description goes far beyond these by explaining ECB publication-day behavior, empty results for non-publication ranges, same-currency rate=1, inline vs spilled handling for long ranges, and the notice text. This adds substantial context without contradicting 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?
The description is long but each sentence earns its place — from the core purpose to edge cases, short/long range behavior, and DataCanvas spill instructions. It is well-structured and front-loaded with the primary purpose.
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 the tool's complexity (range handling, DataCanvas spill) and the presence of an output schema, the description is complete. It covers all important behaviors, gives next-step guidance for spilled data, and does not need to duplicate return-value details because the output schema exists.
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 descriptions cover 100% of the 5 parameters, so the baseline is 3. The description does add some context about date semantics (e.g., weekends/holidays yield no entry) and the DataCanvas spill behavior tied to the canvas_id parameter, but it does not substantially go beyond the schema's per-parameter descriptions.
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 starts with 'Get historical daily exchange rates for a currency pair over a date range' — a specific verb, resource, and scope that clearly distinguishes it from sibling tools like fx_get_rate (single rate) or fx_convert_currency. It also covers key behavioral details (ECB business days, empty maps, same-currency rate).
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 indicates the tool is for historical daily rates over a date range, and references fx_dataframe_describe and fx_dataframe_query for post-processing spilled data. However, it does not explicitly state when to use this tool over alternatives (e.g., 'for a single rate, use fx_get_rate'), so it lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fx_list_currenciesFx List CurrenciesAList all supported ISO 4217 currency codes with their full names. Call this before converting to disambiguate "dollars" (USD vs AUD vs CAD vs HKD vs SGD) or to validate a user-supplied currency code. Covers the ~30 ECB reference currencies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of supported currencies. |
| source | Yes | Always "ECB via Frankfurter" — the upstream data provider. |
| currencies | Yes | All supported currencies, sorted alphabetically by code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it covers ~30 ECB reference currencies, which provides useful scope beyond 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?
Three sentences with no wasted words. First sentence states purpose, second provides a concrete use case, third gives scope.
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 list tool with no parameters and complete annotations, the description's addition of scope (ECB reference) and use cases is sufficient.
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?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter info, and baseline for 0 params is 4.
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 lists ISO 4217 currency codes with full names, and distinguishes itself from sibling conversion/rate tools by specifying its role in disambiguation and validation.
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?
Explicitly advises calling this before conversion to disambiguate currency codes, which is clear when-to-use guidance. The sibling tools perform different actions, so no confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.