The MCP-FREDAPI server integrates with the FRED API to retrieve economic time series data through the Model Context Protocol, enabling AI assistants like Claude to access and analyze economic indicators.
With this server, you can:
Retrieve time series observations for specific economic indicators using their series IDs
Customize data retrieval with parameters such as:
Sort order (ascending/descending)
Units/transformations (e.g., linear, percent change)
Frequency (annual, monthly, daily, etc.)
Aggregation method (average, sum, end of period)
Output format
The primary tool available is get_fred_series_observations, which can be used directly in environments like Cursor with AI assistants.
Used for configuration to securely store and access the FRED API key through environment variables
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., "@MCP-FREDAPI get unemployment rate data for the last 5 years"
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.
FRED (Federal Reserve Economic Data) API integration with Model Context Protocol (MCP)
Related MCP server: FRED MCP Server
MCP-FREDAPI provides access to economic data from the Federal Reserve Bank of St. Louis (FRED) through the Model Context Protocol. This integration allows AI assistants like Claude to retrieve economic time series data directly when used with Cursor or other MCP-compatible environments.
This package integrates with the official FRED API, focusing specifically on the series_observations endpoint which provides time series data for economic indicators.
There are two installation methods:
Install the required dependencies:
pip install "mcp[cli]" httpx python-dotenvClone this repository:
git clone https://github.com/Jaldekoa/mcp-fredapi.git
cd mcp-fredapiThis method is recommended as it matches the configuration shown in mcp.json.
First, install uv if you don't have it yet:
pip install uvClone this repository:
git clone https://github.com/Jaldekoa/mcp-fredapi.git
cd mcp-fredapiUse uv to run the server (no need to install dependencies separately):
uv run --with mcp --with httpx mcp run server.pyYou'll need a FRED API key, which you can obtain from FRED API.
Create a .env file in the project root:
FRED_API_KEY=your_api_key_hereTo configure Cursor to use this MCP server, add the following to your ~/.cursor/mcp.json file:
{
"mcpServers": {
"mcp-fredapi": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-fredapi", "run", "--with", "mcp", "--with", "httpx", "mcp", "run", "server.py"]
}
}
}Replace /path/to/mcp-fredapi with the actual path to the repository on your system. For example:
{
"mcpServers": {
"mcp-fredapi": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-fredapi", "run", "--with", "mcp", "--with", "httpx", "mcp", "run", "server.py"]
}
}
}Note: On Windows, you can use either forward slashes / or double backslashes \\ in the path.
Retrieves economic time series observations from FRED.
When using Claude in Cursor, you can access this tool directly with:
@mcp-fredapi:get_fred_series_observationsThe get_fred_series_observations tool accepts the following parameters. For complete technical details about each parameter, please refer to the official FRED API documentation.
Parameter | Type | Description | Allowed Values | Default Value | Status |
series_id | str | The ID of the economic series | - | (Required) | ✅ Works |
sort_order | str | Sort order of observations | 'asc', 'desc' | 'asc' | ✅ Works |
units | str | Data value transformation | 'lin', 'chg', 'ch1', 'pch', 'pc1', 'pca', 'cch', 'cca', 'log' | 'lin' | ✅ Works |
frequency | str | Frequency of observations | 'd', 'w', 'bw', 'm', 'q', 'sa', 'a', 'wef', 'weth', 'wew', 'wetu', 'wem', 'wesu', 'wesa', 'bwew', 'bwem' | None | ✅ Works |
aggregation_method | str | Aggregation method for frequency | 'avg', 'sum', 'eop' | 'avg' | ✅ Works |
output_type | int | Output type of observations | 1, 2, 3, 4 | 1 | ✅ Works |
realtime_start | str | Start of real-time period (YYYY-MM-DD) | - | None | ❌ Not working |
realtime_end | str | End of real-time period (YYYY-MM-DD) | - | None | ❌ Not working |
limit | int/str | Maximum number of observations to return | Between 1 and 100000 | 10 | ❌ Not working |
offset | int/str | Number of observations to skip from the beginning | - | 0 | ❌ Not working |
observation_start | str | Start date of observations (YYYY-MM-DD) | - | None | ❌ Not working |
observation_end | str | End date of observations (YYYY-MM-DD) | - | None | ❌ Not working |
vintage_dates | str | Comma-separated list of vintage dates | - | None | ❌ Not working |
Due to current limitations with the MCP implementation, only certain parameters are working properly:
✅ Working parameters: series_id, sort_order, units, frequency , aggregation_method, and output_type`.
❌ Non-working parameters: realtime_start, realtime_end, limit, offset, observation_start, observation_end, and vintage_dates.
For best results, stick with the working parameters in your queries. Future updates may resolve these limitations.
When using Claude in Cursor, you can ask for GDP data like this:
Can you get the latest GDP data from FRED?
@mcp-fredapi:get_fred_series_observations
{
"series_id": "GDP"
}Can you get the GDP data in descending order (newest first)?
@mcp-fredapi:get_fred_series_observations
{
"series_id": "GDP",
"sort_order": "desc"
}Can you get annual GDP data?
@mcp-fredapi:get_fred_series_observations
{
"series_id": "GDP",
"frequency": "a"
}To get consumer price index data with percent change:
What's the recent inflation rate in the US?
@mcp-fredapi:get_fred_series_observations
{
"series_id": "CPIAUCSL",
"units": "pch",
"frequency": "m"
}Show me GDP data in a different format.
@mcp-fredapi:get_fred_series_observations
{
"series_id": "GDP",
"output_type": 2
}Contributions are welcome. Please follow these steps:
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes
Commit your changes (git commit -m 'Add an amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
FRED API Documentation - Series Observations - Official documentation for the FRED API endpoint used in this project.
FRED API - Information on obtaining an API key and general API documentation.
Model Context Protocol - Documentation for the Model Context Protocol.
Get series observations from the Fred API.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes | The id for a series. | |
| realtime_start | No | The start of the real-time period. Format: YYYY-MM-DD. Defaults to today's date. | |
| realtime_end | No | The end of the real-time period. Format: YYYY-MM-DD. Defaults to today's date. | |
| limit | No | Maximum number of observations to return. Defaults to 10. | |
| offset | No | Number of observations to offset from first. Defaults to 0. | |
| sort_order | No | Sort order of observations. Options: 'asc' or 'desc'. Defaults to 'asc'. | asc |
| observation_start | No | Start date of observations. Format: YYYY-MM-DD. | |
| observation_end | No | End date of observations. Format: YYYY-MM-DD. | |
| units | No | Data value transformation. Options: 'lin', 'chg', 'ch1', 'pch', 'pc1', 'pca', 'cch', 'cca', 'log'. Defaults to 'lin'. | lin |
| frequency | No | Frequency of observations. Options: 'd', 'w', 'bw', 'm', 'q', 'sa', 'a', 'wef', 'weth', 'wew', 'wetu', 'wem', 'wesu', 'wesa', 'bwew', 'bwem'. Defaults to no value for no frequency aggregation. | |
| aggregation_method | No | Aggregation method for frequency. Options: 'avg', 'sum', 'eop'. Defaults to 'avg'. | avg |
| output_type | No | Output type of observations. Options: 1, 2, 3, 4. Defaults to 1. | |
| vintage_dates | No | Comma-separated list of vintage dates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get series observations' which implies a read-only operation, but doesn't mention any behavioral traits like rate limits, authentication requirements, error handling, or what the return format looks like (e.g., JSON structure, pagination). This leaves significant gaps for an API 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 a single, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized for a tool with a clear name and detailed schema, though it could benefit from more context.
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 (13 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the output format, error conditions, or typical usage patterns. For a data retrieval tool with many filtering options, more guidance on what 'observations' entail and how results are structured is needed.
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%, meaning all parameters are well-documented in the schema itself. The description adds no additional meaning beyond the schema—it doesn't explain parameter interactions, provide examples, or clarify complex concepts like 'realtime period' vs. 'observation period'. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Get series observations from the Fred API' states the basic action (get) and resource (series observations), but it's vague about what 'observations' means in this context (e.g., economic data points over time). With no sibling tools, it doesn't need differentiation, but the purpose lacks specificity about the nature of the data being retrieved.
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 no guidance on when to use this tool versus alternatives, prerequisites, or typical use cases. With no sibling tools, it doesn't need sibling differentiation, but it offers no context about appropriate scenarios (e.g., retrieving historical economic indicators).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool has a clear and distinct purpose, making disambiguation trivial.
Since there is only one tool, naming consistency is inherently perfect. The tool name follows a clear verb_noun pattern (get_fred_series_observations), which would be consistent if more tools existed.
A single tool is too few for a server named MCP-FREDAPI, which suggests broader functionality related to the Fred API. This minimal toolset likely leaves significant gaps in coverage for typical API interactions.
The server is severely incomplete, offering only one tool to get series observations. It lacks essential operations like listing series, searching, or managing data, which are core to interacting with the Fred API domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Equip AI with tools for researching economic data from Federal Reserve Economic Data (FRED).
FRED macro data, Treasury yields, FX rates & macro indicators for AI agents. Pay-per-query via x402.
Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Macroeconomic and FX time-series data for AI agents: indicators, calendars, COT, forex, commodities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jaldekoa/mcp-fredapi'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
