The FrankfurterMCP server provides access to currency exchange rates and conversion functionalities based on the Frankfurter API, exposed as tools over the Model Context Protocol (MCP).
You can:
Retrieve a list of all supported currencies using
get_supported_currenciesGet latest exchange rates for a base currency with
get_latest_exchange_ratesConvert amounts between currencies at current rates via
convert_currency_latestAccess historical exchange rates for specific dates or date ranges using
get_historical_exchange_ratesConvert currency using exchange rates from a specific date with
convert_currency_specific_date
Enables containerization of the MCP server, allowing it to run as a Docker container with configurable environment variables and exposed ports.
Supports configuration through environment variables using .env files, making it easy to customize server settings and API endpoints.
Includes integration with Git for version control, with pre-commit hooks support for code quality maintenance.
Uses GitHub Actions for continuous integration testing, as evidenced by the pytest workflow badge.
Integrates with pre-commit for automated code quality checks before commits are made to the repository.
Published as a package on PyPI, allowing for easy installation via pip with download statistics tracking.
Uses pytest for automated testing, with GitHub Actions integration for continuous test execution.
Built for Python 3.12+, leveraging Python's language features for implementing the MCP server functionality.
Integrates with Ruff for Python code linting and formatting as part of the development workflow.
Uses Shields.io for generating status badges in the README to display Python version, test status, and package information.
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., "@FrankfurterMCPwhat's the current exchange rate from 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.
Frankfurter MCP
Frankfurter is a useful API for latest currency exchange rates, historical data, or time series published by sources such as the European Central Bank. Should you have to access the Frankfurter API as tools for language model agents exposed over the Model Context Protocol (MCP), Frankfurter MCP is what you need.
Installation
If your objective is to use the tools available on this MCP server, please refer to the usage > client sub-section below.
The directory where you clone this repository will be referred to as the working directory or WD hereinafter.
Install just to manage project tasks.
Install uv. To install the project with its minimal dependencies in a virtual environment, run the just install in the WD. To install all non-essential dependencies (which are required for developing and testing), run just install-all instead.
Environment variables
Following is a list of environment variables that can be used to configure the application. A template of environment variables is provided in the file .env.template. Note that the default values listed in the table below are not always the same as those in the .
The following environment variables can be specified, prefixed with FASTMCP_: HOST, PORT, DEBUG and LOG_LEVEL. See global configuration options for FastMCP. Note that on_duplicate_ prefixed options specified as environment variables will be ignored.
The underlying HTTP client also respects some environment variables, as documented in the HTTPX library. In addition, SSL_CERT_FILE and SSL_CERT_DIR can be configured to use self-signed certificates of hosted API endpoint or intermediate HTTP(S) proxy server(s).
Frankfurter MCP will cache calls to the Frankfurter API to improve performance. The cache happens with two different strategies. For API calls whose responses do not change for certain parameters, e.g., historical rate lookup, a least recently used (LRU) cache is used. For API calls whose responses do change, e.g., latest rate lookup, a time-to-live (TTL) cache is used with a default time-to-live set to 15 minutes. The cache parameters can be adjusted using the environment variables, see below.
Variable | [Default value] and description |
| [INFO] The level for logging. Changing this level also affects the log output of other dependent libraries that may use the same environment variable. See valid values at Python logging documentation. |
| [5.0] The time for the underlying HTTP client to wait, in seconds, for a response from the Frankfurter API. The acceptable range of values is between 5.0 and 60.0. |
| [True] This variable can be set to False to turn off SSL certificate verification, if, for instance, you are using a proxy server with a self-signed certificate. However, setting this to False is advised against: instead, use the |
| [localhost] This variable specifies which host the MCP server must bind to unless the server transport (see below) is set to |
| [8000] This variable specifies which port the MCP server must listen on unless the server transport (see below) is set to |
| ["localhost", "127.0.0.1"] This variable specifies Cross-Origin Resource Sharing (CORS) allowed origins for the MCP server unless the server transport (see below) is set to |
| [stdio] The acceptable options are |
| [True] This specifies if additional metadata will be included with the MCP response from each tool call. The additional metadata, for example, will include the API URL of the Frankfurter server, amongst others, that is used to obtain the responses. |
| [https://api.frankfurter.dev/v1] If you are self-hosting the Frankfurter API, you should change this to the API endpoint address of your deployment. |
| [1024] The maximum size of the least recently used (LRU) cache for API calls. The acceptable range of values is between 128 and 65536. |
| [256] The maximum size of the time-to-live (TTL) cache for API calls. The acceptable range of values is between 64 and 16384. |
| [900] The time limit, in seconds, of the time-to-live (TTL) cache for API calls. The acceptable range of values is between 60 and 3600. |
| [100] The maximum number of concurrent connections the server will accept. This helps prevent resource exhaustion from too many simultaneous connections. Only applies when using HTTP transports ( |
| UVICORN_TIMEOUT_KEEP_ALIVE | [60] The timeout in seconds for keeping idle connections alive. Idle connections will be closed after this period to free up resources. Only applies when using HTTP transports (sse or streamable-http). The acceptable range of values is between 60 and 300. |
| UVICORN_TIMEOUT_GRACEFUL_SHUTDOWN | [5] The timeout in seconds for graceful shutdown. The server will wait this long for active connections to complete before forcefully shutting down. Only applies when using HTTP transports (sse or streamable-http). The acceptable range of values is between 5 and 60. |
| RATE_LIMIT_MAX_REQUESTS_PER_SECOND | [10.0] The maximum number of requests allowed per second using a token bucket algorithm. This implements rate limiting to prevent API abuse and ensure fair resource allocation. The acceptable range of values is between 1.0 and 10000.0. |
| RATE_LIMIT_BURST_CAPACITY | [20] The burst capacity for the rate limiter, allowing short bursts of requests above the per-second limit. This provides flexibility for legitimate usage patterns while still protecting against sustained high request rates. The acceptable range of values is between 2x and 5x the RATE_LIMIT_MAX_REQUESTS_PER_SECOND value. |
| REQUEST_SIZE_LIMIT_BYTES | [102400] The maximum size in bytes for HTTP request bodies (default 100KB). Requests exceeding this limit will be rejected with a 413 status code. This prevents memory exhaustion attacks from large payloads. Only applies when using HTTP transports (sse or streamable-http). The acceptable range of values is between 10240 (10KB) and 524288 (512KB). |
| DOCKER_TMPFS_SIZE_MB | [100] The size in megabytes for the temporary filesystem (/tmp) when running in Docker with read-only root filesystem. This temporary storage is used for runtime file operations. Increase this value if the application requires more temporary storage for caching or processing large datasets. Only relevant when deploying with Docker Compose. |
Usage
The following sub-sections illustrate how to run the Frankfurter MCP as a server and how to access it from MCP clients.
Related MCP server: CoinStats MCP Server
Server
While running the server, you have the choice to use stdio transport or HTTP options (sse or the newer streamable-http).
Using default settings and MCP_SERVER_TRANSPORT set to sse or streamable-http, the MCP endpoint will be available over HTTP at http://localhost:8000/sse for the Server Sent Events (SSE) transport, or http://localhost:8000/mcp for the streamable HTTP transport.
If you want to run Frankfurter MCP with stdio transport and the default parameters, execute the commands below without using the .env.template file.
Server with uv
Optional: Copy the .env.template file to a .env file in the WD, to modify the aforementioned environment variables, if you want to use anything other than the default settings. Or, on your shell, you can export the environment variables that you wish to modify.
Run the following in the WD to start the MCP server.
Server with pip from PyPI package
Add this package from PyPI using pip in a virtual environment (possibly managed by uv, pyenv or conda) and then start the server by running the following.
Optional: Add a .env file with the contents of the .env.template file if you wish to modify the default values of the aforementioned environment variables. Or, on your shell, you can export the environment variables that you wish to modify.
Server using Docker
There are two Dockerfiles provided in this repository.
local.dockerfilefor containerising the Frankfurter MCP server.smithery.dockerfilefor deploying to Smithery AI, which you do not have to use. Note that runtime hardening of the container based on this Dockerfile is not provided in this repository through Docker Compose because this is managed by Smithery AI during deployment.
First, make a copy of the .env.template to a .env file. Then, modify the following variables in the .env file as needed.
FASTMCP_HOST: Set to0.0.0.0to allow external access to the container. This is only for local testing and is not recommended for production deployments.CORS_MIDDLEWARE_ALLOW_ORIGINS: Set to*to allow external access to the MCP server from any origin. This is needed if you want to test the server using the MCP Inspector over HTTP transport and is not recommended for production deployments.
To build the image, create the container and start it using Docker Compose, run the following in WD.
If you change the port to anything other than 8000 in .env, do remember to change the port number in . Instead of using the .env file, you can also modify docker-compose.yml to pass individual environment variables using the environment section.
To run in detached mode (background), add the -d flag:
To stop the container:
The docker-compose.yml file includes security hardening with read-only filesystem, dropped capabilities, seccomp and AppArmor profiles, and resource limits (512MB memory, 1 CPU).
Upon successful build and container start, the MCP server will be available over HTTP at http://localhost:8000/sse for the Server Sent Events (SSE) transport, or http://localhost:8000/mcp for the streamable HTTP transport.
Cloud hosted servers
The currently available cloud hosted options are as follows.
FastMCP Cloud: https://frankfurtermcp.fastmcp.app/mcp
Glama.AI: https://glama.ai/mcp/servers/@anirbanbasu/frankfurtermcp
Smithery.AI: https://smithery.ai/server/@anirbanbasu/frankfurtermcp (This will be deprecated beyond March 2026.)
Client access
This sub-section explains ways for a client to connect and test the FrankfurterMCP server.
The official MCP visual inspector
The MCP Inspector is an official Model Context Protocol tool that can be used by developers to test and debug MCP servers. This is the most comprehensive way to explore the MCP server.
To use it, you must have Node.js installed. The best way to install and manage node as well as packages such as the MCP Inspector is to use the Node Version Manager (or, . Once you have nvm installed, you can install and use the latest Long Term Release version of node by executing the following.
Following that (install and) run the MCP Inspector by executing the following in the WD.
This will create a local URL at port 6274 with an authentication token, which you can copy and browse to on your browser. Once on the MCP Inspector UI, press Connect to connect to the MCP server. Thereafter, you can explore the tools available on the server.
Claude Desktop, Visual Studio, and so on
The server entry to run with stdio transport that you can use with systems such as Claude Desktop, Visual Studio Code, and so on is as follows.
Instead of having frankfurtermcp as the last item in the list of args, you may need to specify the full path to the script, e.g., WD/.venv/bin/frankfurtermcp. Likewise, instead of using uv, you could also have the following JSON configuration with the path properly substituted for python3.12, for instance such as WD/.venv/bin/python3.12.
List of available MCP features
FrankfurterMCP has the following MCP features.
Tools
The following table lists the names of the tools as exposed by the FrankfurterMCP server. The descriptions shown here are for documentation purposes, which may differ from the actual descriptions exposed over the model context protocol.
Name | Description |
| Get a list of currencies supported by the Frankfurter API. |
| Get latest exchange rates in specific currencies for a given base currency. |
| Convert an amount from one currency to another using the latest exchange rates. |
| Get historical exchange rates for a specific date or date range in specific currencies for a given base currency. |
| Convert an amount from one currency to another using the exchange rates for a specific date. |
| Get a greeting from the FrankfurterMCP server. This is mostly used for internal testing. |
The required and optional arguments for each tool are not listed in the following table for brevity but are available to the MCP client over the protocol.
Contributing
Install prek. Then enable prek by running the following in the WD.
Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.
Testing and coverage
To run the provided test cases, execute the following. Add the flag --capture=tee-sys to the command to display further console output.
Invoke just test-coverage to run all the tests and generate a coverage report as follows. If all tests are run, the generated coverage report may look like the one below.
License
MIT.
Security considerations
This section documents security-related findings from vulnerability scans and provides context for deployment decisions.
Airtable vulnerability scan findings and rationale
Check for security-related findings from the Airtable vulnerability scan (search for frankfurtermcp) below, along with rationale and counter-arguments.
Rule ID | Issue and counter arguments |
MCP-R001 | Issue: Tools are registered dynamically at server startup without cryptographic signatures, immutable versioning, or integrity checks. The architecture permits hot-reload scenarios (via Counter arguments: Tools are not loaded from external sources or plugins—they are defined directly in the application source code. Integrity is ensured through version control and code review processes. Since tools are part of the application binary (not dynamically loaded plugins), cryptographic signing would add complexity without meaningful security benefit. |
MCP-R004 | Issue: The server warns but accepts wildcard in CORS origins. Counter arguments: This server is not intended to be run directly in a production environment when using HTTP transports. For deployments with stricter CORS origin control, users should use the . |
MCP-R005 | Issue: There is no TLS enforcement when the server is set to listen on Counter arguments: This configuration is a requirement for deployment on Smithery, which functions as an MCP gateway. Smithery provides its own security layer including TLS termination, authentication, and access control. If TLS requirement is enforced in the code, the Smithery deployment will fail. For local deployments, users should use the . |
MCP-R013 | Issue: There is no support for HTTPS when the server binds to any IP other than 127.0.0.1. Counter arguments: This server is not intended to be run directly in a production environment with HTTPS support when using HTTP transports. For deployments requiring HTTPS support, users should use the . |
MCP-R018 | Issue: There are no authentication or authorisation checks. Counter arguments: This server is not intended to be run directly in a multi-user mode of operation when using HTTP transports. For deployments with access control, users should use the . |
Project status
Following is a table of some updates regarding the project status. Note that these do not correspond to specific commits or milestones.
Date | Status | Notes or observations |
January 15, 2025 | active | Improved code with rate and size limiting middleware. |
December 2, 2025 | active | Added a middleware to remove unknown tool arguments, such as those passed by . |
November 26, 2025 | active | Using the new |
November 21, 2025 | active | New tooling using |
September 6, 2025 | active | Code refactoring and cleanup. |
June 27, 2025 | active | Successful remote deployments on Glama.AI and Smithery.AI. |
June 9, 2025 | active | Added containerisation, support for self-signed proxies. |
June 7, 2025 | active | Project started. Added tools to cover all the functionalities of the Frankfurter API. |