Currency & Exchange Rate MCP
Server Details
Currency conversion + exchange rates: free convert/rates, paid historical & trend analytics.
- 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.1/5 across 7 of 7 tools scored. Lowest: 1.8/5.
Each tool has a clearly distinct purpose: brief_summary is a cheap sampler, daily_brief is the full report, convert performs conversions, rates provides current rates, historical_rate gives past rates, rate_trend shows trend analysis, and mint_info covers protocol details. No two tools overlap in functionality.
Naming conventions are mixed: brief_summary and daily_brief use nouns, convert is a verb, historical_rate is adjective+noun, mint_info is noun+noun, rates is a noun, and rate_trend is noun+noun. While each name is readable, there's no consistent verb_noun or other pattern across the set.
7 tools is well-suited for a currency/exchange server. It covers current rates, historical rates, conversion, trend analysis, daily briefs, and protocol info—enough to be useful without being overwhelming or too sparse.
The tool surface covers core currency operations: retrieval of current and historical rates, conversion, trend analysis, and a daily brief. A minor gap is the lack of a dedicated tool to list all available currencies, but the mint_info tool provides network context, and the core workflows are well-supported.
Available Tools
7 toolsbrief_summaryAInspect
Get the top 5 signals from today's brief as structured JSON — a cheap sample of the full daily_brief. Returns the day's highest-priority items (no prose) so an agent can decide whether to buy the full brief.
PAID: $0.50 USDC (vs the full daily_brief price). Defaults to today (UTC). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool returns top 5 signals, costs $0.50 USDC, defaults to today, and details payment retry on 402. It does not mention rate limits or behavior for past dates, but the payment flow is well-documented.
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 front-loaded with purpose, then covers pricing and retry logic. While slightly lengthy, every sentence adds value and the structure is logical.
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 complexity (paid tool with output schema), the description covers purpose, pricing, retry, default date, and auth bypass. It lacks some edge cases but is sufficient for a tool with three optional params.
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 baseline is 3. The description adds extra meaning for the payment_tx parameter (explaining the retry flow) and notes the default date behavior. agent_id is schema-described but not elaborated, still above baseline.
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 verb (Get) and the resource (top 5 signals from today's brief as structured JSON). It explicitly contrasts with the full daily_brief, distinguishing its purpose as a cheap sample.
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 (to decide whether to buy the full brief) and provides payment instructions. It implicitly defines when not to use (if full brief is needed, use daily_brief) and gives context on pricing and retry logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convertAInspect
Convert an amount from one currency to another at the latest ECB reference rate. FREE — the gateway tool every agent handling international transactions needs. Returns the converted amount, the rate used, and the as-of date.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | the amount to convert (e.g. 100). | |
| to_currency | Yes | ISO 4217 target code, e.g. "EUR". | |
| from_currency | Yes | ISO 4217 source code, e.g. "USD". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data source (ECB reference rate) and the return fields (converted amount, rate, as-of date). It does not mention side effects, but the 'Convert' verb could misleadingly imply mutation; however, the output description clarifies it is a query. Overall, sufficiently transparent for a simple conversion tool.
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 extremely concise with two sentences, front-loading the core purpose and data source. Every sentence contributes value without redundancy or padding.
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 existence of an output schema (context: has output schema=true), the description appropriately covers the tool's purpose, data source, and return values. No significant gaps remain for such a straightforward conversion function.
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% description coverage with clear parameter descriptions (ISO 4217 codes, example amount). The tool description adds context about the ECB rate and output fields, which complements the schema but does not add new semantic detail beyond what is already provided.
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 verb 'Convert', the resource 'currency', and specifies 'at the latest ECB reference rate'. It distinguishes from siblings (e.g., historical_rate, rates) by emphasizing it as the 'gateway tool every agent handling international transactions needs'.
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 indicates when to use ('every agent handling international transactions') and implies it is the primary conversion tool. However, it does not explicitly exclude cases where alternatives like historical_rate or rates might be more appropriate, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_briefAInspect
Get the curated daily FX brief — the biggest 7-day movers across major currencies (vs USD), current key cross-rates, and a snapshot date, in one package. Each brief carries a MINT provenance attestation so a buyer can verify it was produced by this server, unaltered.
PAID: $5 USDC per brief. Defaults to today (UTC); a brief expires at the next midnight UTC. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An fnet_ Bearer key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402 (x402 rail). | |
| stripe_token | No | Stripe Checkout Session id (cs_…), when re-calling after paying the Stripe payment link (alternative to x402). Can also be supplied via the X-Stripe-Token header. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: cost ($5 USDC), expiration (midnight UTC), payment flows (x402 and Stripe), and provenance attestation. This is comprehensive for a payment-gated tool.
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 dense but efficient, containing all essential information in a single paragraph. It could be slightly improved with more structure (e.g., separating payment details), but it remains concise.
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 (payment, expiration, provenance), the description covers key aspects. The existence of an output schema means return values don't need description. Some minor details (like error handling beyond 402) are omitted, but overall it is complete enough.
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 context beyond schema descriptions: e.g., 'date' defaults to today UTC, 'agent_id' scopes free-tier counter, 'payment_tx' and 'stripe_token' are for re-call after payment. This enhances parameter understanding.
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 returns a 'curated daily FX brief' detailing the biggest 7-day movers, key cross-rates, and snapshot date. This specific verb-resource pair with included items distinguishes it from sibling tools like 'rates' or 'historical_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 explains when to use (to get the daily brief) and provides explicit payment flow instructions for post-402 retries. However, it does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
historical_rateAInspect
Get the exchange rate for a currency pair on a specific past date (ECB reference, nearest prior business day). For back-dating invoices, settlements, and historical accounting.
PAID: $0.005 USDC per query after a daily free allowance. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | the date, YYYY-MM-DD. | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| to_currency | Yes | ISO 4217 target code, e.g. "EUR". | |
| from_currency | Yes | ISO 4217 source code, e.g. "USD". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: ECB reference, nearest business day, payment model with daily free allowance, 402 error handling, and authorization bypass. This exceeds transparency expectations.
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 front-loaded with purpose and use cases, followed by payment details. While slightly lengthy, every sentence provides essential information about behavior and error recovery.
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 (payment model, date handling, output schema exists), the description covers all necessary aspects: purpose, behavioral quirks, payment process, and error handling. 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?
Schema coverage is 100%, but the description adds valuable behavioral context, especially for payment_tx (explaining its use in 402 retry) and agent_id (free counter scoping). This goes beyond the schema's 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 clearly states the tool retrieves exchange rates for a specific past date, using ECB reference and nearest prior business day. It also lists specific use cases like back-dating invoices, distinguishing it from sibling tools that may handle current 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 implies usage for historical accounting but does not explicitly state when to use this tool over siblings like 'rates' or 'convert'. No exclusions or alternatives are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_infoDInspect
FoundryNet Data Network + MINT Protocol details (FREE). How to attest your agent's FX conversions and rate analysis on-chain for verifiable proof of work, and the sibling data servers available across the network.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose what the tool does beyond providing 'details'. It does not mention output format, side effects, or behavioral traits.
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 a single verbose sentence that tries to cover multiple concepts (network, protocol, instructions, siblings). It is not concise and lacks clear structure.
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 zero parameters and existence of an output schema, the description should clarify what the tool returns. Instead, it focuses on how to attest conversions, leaving the output unclear.
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 no parameters, and schema coverage is 100%. The description adds minimal value beyond the empty schema by stating it provides 'details', but it does not enhance parameter understanding.
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 mentions 'FoundryNet Data Network + MINT Protocol details' but mixes in instructional phrasing about attesting FX conversions. It does not clearly state a specific action or resource, making the purpose vague.
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?
No guidance is provided on when to use this tool versus its siblings (convert, daily_brief, etc.). The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ratesAInspect
Get all current exchange rates for a base currency at the latest ECB reference fix. FREE. Returns a {currency: rate} map plus the as-of date.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | ISO 4217 base currency (default "USD"). | USD |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the data source (ECB), that it's free, and the return format. It lacks specifics on update frequency or rate limits, but for a read-only tool, it provides adequate 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, no fluff, and immediately conveys the core function, data source, and output format. 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?
Given the output schema exists (not shown but indicated), the description's mention of return format suffices. It could mention error handling or edge cases, but for a simple tool, it is complete enough.
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 already describes the single parameter 'base' with full coverage. The description adds no extra meaning beyond stating the tool's purpose, which already implies the parameter. 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 identifies the tool as fetching all current exchange rates for a base currency from the latest ECB reference fix, distinguishing it from sibling tools like 'convert' (which converts) and 'historical_rate' (historical data).
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 implies usage for obtaining all current rates at once, and mentions 'FREE' to indicate no cost. However, it does not explicitly state when to avoid using it or direct to alternatives like 'convert' for single conversions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rate_trendAInspect
Get the rate history for a currency pair over the last N days, with the trend direction (appreciating/depreciating/flat), percentage change, and volatility — for FX risk, hedging, and timing decisions.
PAID: $0.01 USDC per query after a daily free allowance. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | lookback window in days (2–365, default 30). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| to_currency | Yes | ISO 4217 target code, e.g. "EUR". | |
| from_currency | Yes | ISO 4217 source code, e.g. "USD". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses cost model (free allowance, $0.01 USDC per query), 402 error handling, and alternative Auth header bypass. Also states output includes trend direction, percentage change, volatility.
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 clear paragraphs: first describes functionality, second details payment flow. Front-loaded with main purpose, no superfluous text. Every sentence adds 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?
Considering complexity (payment model, 5 parameters, output schema exists), description covers functionality, payment instructions, and output summary. Leaves no major gaps for agent to infer.
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 are covered in schema with descriptions (100% coverage). Description adds meaning: explains payment_tx as 're-call after 402' and agent_id as 'scopes free-tier counter', beyond schema defaults.
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 gets rate history for a currency pair over N days with trend, percentage change, and volatility for FX risk, hedging, and timing decisions. This distinguishes it from siblings like 'rates' (simple rate) or 'historical_rate' (raw 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?
Provides explicit usage context (FX risk, hedging, timing decisions) and payment flow instructions (free allowance, 402 handling, re-call with payment_tx). Misses explicit when not to use vs. siblings, but purpose is specific enough.
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!