Currency Converter MCP
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Currency Converter MCPconvert 500 USD to EUR"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Currency Converter Server
An MCP server that provides real-time currency conversion and exchange rate data using the Frankfurter API.
Using
URL base is https://currency-mcp.wesbos.com
There are two endpoints - /mcp for streamable HTTP and /sse for legacy HTTP+SSE.
Right now many clients do not offer support for streamable http, so you can use it with a proxy:
{
"mcpServers": {
"currency-conversion": {
"command": "npx",
"args": ["mcp-remote", "https://currency-mcp.wesbos.com/sse"]
}
},
}Related MCP server: Frankfurter Forex MCP
Available Tools
convert_currency
Convert an amount from one currency to another.
Parameters:
from(string): Source currency code (3 letters, e.g., "USD", "EUR")to(string): Target currency code (3 letters, e.g., "USD", "EUR")amount(number): Amount to convert (positive number)
Example: Convert 100 USD to EUR
{
"from": "USD",
"to": "EUR",
"amount": 100
}get_latest_rates
Fetch the latest exchange rates.
Parameters:
base(string, optional): Base currency code (defaults to EUR)symbols(string, optional): Comma-separated currency codes to limit results
Example: Get USD rates for specific currencies
{
"base": "USD",
"symbols": "EUR,GBP,JPY"
}get_currencies
List all available currencies with their full names.
Parameters: None
get_historical_rates
Get historical exchange rates for a specific date.
Parameters:
date(string): Date in YYYY-MM-DD formatbase(string, optional): Base currency code (defaults to EUR)symbols(string, optional): Comma-separated currency codes to limit results
Example: Get historical EUR rates for January 1, 2024
{
"date": "2024-01-01",
"base": "EUR",
"symbols": "USD,GBP"
}Data Source
Exchange rate data is provided by the Frankfurter API
Available Tools
4 toolsconvert_currencyD
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Source currency code (e.g., USD, EUR) | |
| to | Yes | Target currency code (e.g., USD, EUR) | |
| amount | Yes | Amount to convert |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_currenciesD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_historical_ratesD
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format | |
| base | No | Base currency code (default: EUR) | |
| symbols | No | Comma-separated currency codes to limit results |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latest_ratesD
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency code (default: EUR) | |
| symbols | No | Comma-separated currency codes to limit results (e.g., USD,GBP,JPY) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
- First observed
convert_currency - First observed
get_currencies - First observed
get_historical_rates - First observed
get_latest_rates
TDQS
Each tool has a clearly distinct purpose with no overlap: convert_currency performs conversions, get_currencies lists available currencies, get_historical_rates retrieves past rates, and get_latest_rates provides current rates. The names alone make their functions unambiguous.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., convert_currency, get_currencies). There are no deviations in style or convention, making the set predictable and easy to parse.
With 4 tools, this server is well-scoped for a currency converter domain. Each tool serves a distinct and essential function, covering core operations without bloat or unnecessary complexity.
The tool set provides complete coverage for currency conversion workflows: listing currencies, getting latest rates, accessing historical data, and performing conversions. There are no obvious gaps for the stated purpose.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A MCP server for the Frankfurter API for currency exchange rates.
Frankfurter MCP — wraps Frankfurter API (api.frankfurter.dev)
Exchange MCP — wraps the Frankfurter currency exchange API (free, no auth)
Related MCP Servers
- AlicenseBqualityAmaintenanceA MCP server for the Frankfurter API for currency exchange rates.66MIT
- FlicenseBqualityDmaintenanceAn MCP server that provides currency rates, conversions, and historical exchange-rate data using the Frankfurter API. It enables users to retrieve latest rates, convert amounts between currencies, and access time-series data for currency pairs.3-
- -licenseNot gradedqualityNot gradedmaintenanceMCP server that provides real exchange-rate data from the European Central Bank, including latest rates, currency conversion, historical rates, and time series.-
- FlicenseNot gradedqualityCmaintenanceAn MCP server that integrates ExchangeRate-API and Open-Meteo to provide currency conversion and weather tools, enabling natural language queries for exchange rates, weather, and geocoding.-
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wesbos/currency-conversion-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server