exchange-rates-mcp-server
Server Details
Convert currencies, get FX rates, and query historical ECB exchange rate data.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
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.
Available Tools
7 toolsfx_convert_currencyFx Convert CurrencyARead-onlyIdempotentInspect
Convert 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 a positive number. | |
| 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, and openWorld hints. The description adds valuable behavioral details: return of rate, actual rate date, snapping from weekends/holidays, and EUR triangulation. This goes well 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 redundancy. Front-loaded with the core purpose. Every sentence provides value.
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?
Description covers key behavioral aspects and return values. With output schema present, additional details on errors or edge cases are not essential but could be beneficial. Slightly incomplete regarding what happens for unsupported pairs, but the triangulation note mitigates.
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?
Input schema has 100% coverage. Description adds extra meaning: date format, historical range, hint to call fx_list_currencies for valid currency codes, and amount positivity constraint. No missing info.
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 converts an amount between two currencies using latest or historical rates, and specifies return values. It distinguishes from sibling tools like fx_get_rate by focusing on conversion with an amount.
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 explains when to use this tool (converting an amount) and mentions key behaviors (cross-rate triangulation through EUR). It does not explicitly state when not to use it or provide direct alternatives, but the purpose is clear enough.
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 DescribeARead-onlyIdempotentInspect
List 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.
| 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; the description adds useful context about the data dependency and canvas_id expiration, going beyond 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?
Two concise sentences, front-loaded with purpose and usage, with no extraneous 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 simple tool with one parameter and an output schema, the description fully covers purpose, prerequisites, and usage context.
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 single parameter canvas_id is fully described in the input schema with 100% coverage, so the tool description adds no extra parameter meaning beyond 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 clearly states the tool lists tables and columns from a prior fx_get_timeseries call, using a specific verb and resource, and distinguishes it from the sibling fx_dataframe_query.
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 states it is the required first step before fx_dataframe_query and instructs to re-run fx_get_timeseries if the canvas_id expires, providing clear when-to-use and alternatives.
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 QueryARead-onlyIdempotentInspect
Run 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.
| 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. |
Output Schema
| 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 | Total rows in the full result set before the row cap was applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds specific behavioral capabilities (supports aggregations, GROUP BY, window functions, JOINs) and explicitly states 'read-only SQL SELECT', confirming the read-only nature. No contradictions with 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 sentences: first states core purpose, second provides essential usage advice. No redundant words, clearly front-loaded with action and resource.
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 good annotations (read-only, idempotent) and presence of an output schema, the description covers input preparation (run fx_dataframe_describe first), supported SQL features, and the read-only nature. No missing critical context for a query 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?
Schema description coverage is 100%, and both parameters have descriptive schema entries (query with an example, canvas_id with expiration guidance). The description adds no new parameter-specific meaning beyond repeating the SQL nature and referencing fx_dataframe_describe for table names. 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 specifies a clear verb ('Run a read-only SQL SELECT') and resource ('DataCanvas tables staged by fx_get_timeseries'). It differentiates from siblings by mentioning companion tools (fx_dataframe_describe for discovery, fx_get_timeseries for staging) and notes supported SQL features (aggregations, GROUP BY, window functions, JOINs).
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 tells the agent to run fx_dataframe_describe first to discover table names and column schemas, establishing a usage prerequisite. It implies this tool is for read-only SELECT queries after data has been fetched by fx_get_timeseries. Does not explicitly state when not to use it, but the context is clear enough.
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 RateARead-onlyIdempotentInspect
Get 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. 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". |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnly, openWorld, and idempotent hints. The description adds valuable behavioral context: the actual rate date may differ from requested date on weekends/holidays because ECB only publishes business days, cross-rates are triangulated through EUR, and source provenance is included. 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 four sentences, each serving a distinct purpose: stating the action, explaining behavior, mentioning cross-rates, and contrasting with a sibling. There is no redundancy or wasted words. It is concise yet comprehensive.
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 (exchange rate retrieval with date handling, cross-rates, and provenance), the description covers all essential aspects: default behavior, date adjustments, source data constraints, and cross-rate methodology. The presence of an output schema further reduces the need to describe return values. It is complete for agent decision-making.
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 has 100% parameter description coverage. The description adds extra semantic details: default date (latest), ECB data start date (1999-01-04), unsupported future dates, and how the rate is expressed ('how many quote units per 1 base unit'). These additions enhance understanding beyond 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 clearly states the tool gets exchange rates for a currency pair. It distinguishes itself from the sibling tool fx_convert_currency by specifying that this tool is for rate numbers, not conversions. It also mentions cross-rate triangulation and source provenance, making the purpose very 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?
The description explicitly contrasts with fx_convert_currency, telling the agent to use this tool when only the rate number is needed. It implies context for when to use it (getting rates on a given date, default latest) but does not explicitly list exclusions or alternative tools like fx_list_currencies (though that is covered in the parameter description). Still, the guidance is clear and helpful.
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 RatesARead-onlyIdempotentInspect
Get 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.
| 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. | |
| base_currency | Yes | ISO 4217 base currency code (e.g. USD). Call fx_list_currencies to get valid codes. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format ('map of quote currency → rate plus the snapshot date') and optional filtering. Annotations already declare readOnlyHint and idempotentHint, and the description adds no contradictions, providing full transparency.
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 wasted words. The first sentence states the core purpose, the second adds usage guidance, and the third covers optional parameters. Each sentence is essential.
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 tool (3 params, all described in schema), return value explained (map + date), and presence of output schema, the description is fully complete without needing more detail.
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%, but the description adds significant value: explains date behavior ('Omit for latest, ECB data starts 1999, no future dates'), clarifies symbols ('filter to all ~30 supported currencies'), and tells where to get valid base_currency codes (fx_list_currencies).
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 all available exchange rates for one base currency in a single snapshot' with specific verb and resource. It distinguishes from siblings like fx_get_rate (single rate) and fx_list_currencies (just currency codes) by mentioning 'bulk comparison' and 'seeding downstream tools'.
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 usage context ('Useful for bulk comparison and seeding downstream tools') and mentions optional filtering. However, it does not explicitly exclude alternatives or state when not to use this tool over siblings like fx_convert_currency 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_get_timeseriesFx Get TimeseriesARead-onlyIdempotentInspect
Get historical daily exchange rates for a currency pair over a date range. ECB publishes on business days only — weekends and holidays produce no entry (not snapped). Short ranges (≤90 days by default) are returned inline as a date→rate map. Long ranges spill to DataCanvas: 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.
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rates | Yes | Date → rate map for the inline result. Business days only. Empty when the result was spilled to canvas. |
| 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 | Actual last date in the returned series (may differ from requested if that date had no ECB fix). |
| 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 (business days) in the range. |
| start_date | Yes | Actual first date in the returned series (may differ from requested if that date had no ECB fix). |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral context: ECB publishes only on business days, no snapping for weekends/holidays, short ranges inline, long ranges spill to DataCanvas with response fields (spilled, canvas_id, table_name). No 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?
Description is 5 sentences, each serving a purpose: purpose statement, data source note, short vs long range behavior, instructions for long ranges. Front-loaded with key information, no redundancy, efficient.
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 5 parameters, 100% schema coverage, and an output schema, the description explains output fields (spilled, canvas_id, table_name) but doesn't detail the inline date->rate map. However, with output schema present, it's sufficient. It also covers the data source and spillover behavior.
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?
All 5 parameters have schema descriptions (100% coverage). The description adds extra context: ECB data starts 1999-01-04, actual first data may be later; future dates not supported; optional canvas_id for appending. This adds value beyond what the schema provides.
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 it retrieves historical daily exchange rates for a currency pair over a date range, distinguishing it from siblings like fx_get_rate (likely a single rate) and fx_convert_currency. It also explains spillover behavior and references sibling tools for long ranges.
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 explains when to use the tool (get historical daily rates for a pair over a date range), notes ECB publication schedule (business days only), and describes short vs long range behavior. It explicitly says to use fx_dataframe_describe and fx_dataframe_query for long ranges. Missing explicit 'when not to use' but context is clear.
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 CurrenciesARead-onlyIdempotentInspect
List 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 | |||
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, openWorld. Description adds the scope (list of all supported codes, ~30 currencies) and the purpose of disambiguation, providing useful behavioral context beyond what annotations state.
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 concise sentences with no wasted words. Front-loaded with main purpose, followed by usage guidance. Ideal length.
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 parameters, rich annotations, and an output schema, the description fully covers what the tool does, when to use it, and its scope. No 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?
No parameters exist, so baseline is 4. Description adds meaning about the return value (list of codes and names) and use cases, which is above the baseline for a parameterless tool.
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?
Explicitly states it lists ISO 4217 currency codes with full names, and distinguishes from conversion/sibling tools by noting it is for disambiguation or validation before converting.
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 when-to-use guidance: 'Call this before converting to disambiguate dollars or to validate a user-supplied currency code.' Also states coverage (~30 ECB currencies).
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.
Discussions
No comments yet. Be the first to start the discussion!