FRED（美联储经济数据）API 与模型上下文协议（MCP）集成
Related MCP server: FRED MCP Server
MCP-FREDAPI 通过模型上下文协议 (MCP Protocol) 提供对圣路易斯联邦储备银行 (FRED) 经济数据的访问。此集成允许像 Claude 这样的 AI 助手在与 Cursor 或其他兼容 MCP 的环境配合使用时直接检索经济时间序列数据。
该软件包与官方 FRED API集成，特别关注为经济指标提供时间序列数据的series_observations 端点。
安装方法有两种：
安装所需的依赖项：
pip install "mcp[cli]" httpx python-dotenv克隆此存储库：
git clone https://github.com/Jaldekoa/mcp-fredapi.git
cd mcp-fredapi推荐使用此方法，因为它与 mcp.json 中显示的配置相匹配。
首先，如果您还没有安装 uv，请安装它：
pip install uv克隆此存储库：
git clone https://github.com/Jaldekoa/mcp-fredapi.git
cd mcp-fredapi使用 uv 运行服务器（无需单独安装依赖项）：
uv run --with mcp --with httpx mcp run server.py您需要一个 FRED API 密钥，您可以从FRED API获取。
在项目根目录中创建一个.env文件：
FRED_API_KEY=your_api_key_here要配置 Cursor 使用此 MCP 服务器，请将以下内容添加到您的~/.cursor/mcp.json文件中：
{
"mcpServers": {
"mcp-fredapi": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-fredapi", "run", "--with", "mcp", "--with", "httpx", "mcp", "run", "server.py"]
}
}
}将/path/to/mcp-fredapi替换为你系统上仓库的实际路径。例如：
{
"mcpServers": {
"mcp-fredapi": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-fredapi", "run", "--with", "mcp", "--with", "httpx", "mcp", "run", "server.py"]
}
}
}注意：在 Windows 上，您可以在路径中使用正斜杠/或双反斜杠\\ 。
从 FRED 检索经济时间序列观测数据。
在 Cursor 中使用 Claude 时，您可以直接使用以下方式访问此工具：
@mcp-fredapi:get_fred_series_observationsget_fred_series_observations工具接受以下参数。有关每个参数的完整技术细节，请参阅官方 FRED API 文档。
范围 | 类型 | 描述 | 允许值 | 默认值 | 地位 |
系列 ID | 字符串 | 经济系列ID | - | （必需的） | ✅ 有效 |
排序顺序 | 字符串 | 对观察结果进行排序 | ‘升序’，‘降序’ | ‘升序’ | ✅ 有效 |
单位 | 字符串 | 数据价值转化 | 'lin'、'chg'、'ch1'、'pch'、'pc1'、'pca'、'cch'、'cca'、'log' | 林 | ✅ 有效 |
频率 | 字符串 | 观察频率 | 'd'、'w'、'bw'、'm'、'q'、'sa'、'a'、'wef'、'weth'、'wew'、'wetu'、'wem'、'wesu'、'wesa'、'bwew'、'bwem' | 没有任何 | ✅ 有效 |
聚合方法 | 字符串 | 频率聚合方法 | “平均值”、“总和”、“eop” | ‘平均’ | ✅ 有效 |
输出类型 | 整数 | 观测值的输出类型 | 1、2、3、4 | 1 | ✅ 有效 |
实时启动 | 字符串 | 实时周期的开始 (YYYY-MM-DD) | - | 没有任何 | ❌ 不工作 |
realtime_end | 字符串 | 实时周期结束时间 (YYYY-MM-DD) | - | 没有任何 | ❌ 不工作 |
限制 | 整数/字符串 | 返回的最大观测数 | 介于 1 到 100000 之间 | 10 | ❌ 不工作 |
抵消 | 整数/字符串 | 从头开始跳过的观察次数 | - | 0 | ❌ 不工作 |
观察开始 | 字符串 | 观察开始日期（YYYY-MM-DD） | - | 没有任何 | ❌ 不工作 |
观察结束 | 字符串 | 观察结束日期（YYYY-MM-DD） | - | 没有任何 | ❌ 不工作 |
年份日期 | 字符串 | 以逗号分隔的年份列表 | - | 没有任何 | ❌ 不工作 |
关于参数兼容性的注意事项
由于当前 MCP 实施的限制，只有某些参数可以正常工作：
✅工作参数：
series_id、sort_order、units、frequency、aggregation_method, andoutput_type。❌非工作参数：
realtime_start、realtime_end、limit、offset、observation_start、observation_end和vintage_dates。为了获得最佳效果，请在查询中坚持使用有效参数。未来的更新可能会解决这些限制。
在 Cursor 中使用 Claude 时，可以像这样请求 GDP 数据：
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"
}获取百分比变化的消费者价格指数数据：
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
}欢迎贡献。请按照以下步骤操作：
分叉存储库
创建功能分支（ git checkout -b feature/amazing-feature ）
进行更改
提交您的更改（ git commit -m 'Add an amazing feature' ）
推送到分支（ git push origin feature/amazing-feature ）
打开拉取请求
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。
FRED API 文档 - 系列观察- 本项目使用的 FRED API 端点的官方文档。
FRED API - 有关获取 API 密钥和一般 API 文档的信息。
模型上下文协议- 模型上下文协议的文档。
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 only says 'Get', implying a read operation, but does not describe response format, pagination behavior, real-time period semantics, potential errors, or any side effects. The description is too thin to inform the agent about how the tool behaves beyond the obvious.
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 concise sentence with zero wasted words and is front-loaded with the core verb and resource. It is appropriately brief, though given the tool's complexity, a little more structure could have made it more useful without losing conciseness.
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?
This is a 13-parameter tool with no output schema and no annotations. The description does not explain what an 'observation' is, what the return payload looks like, or how concepts like vintage dates and real-time periods work. The schema covers parameters, but the overall tool context is under-specified for an agent to use it confidently.
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 schema has 100% description coverage across all 13 parameters, so the baseline is 3. The description itself contributes nothing to parameter understanding, but the schema adequately documents defaults, formats, and enums, so no deduction beyond baseline is warranted.
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 states a clear verb ('Get') and resource ('series observations') with the API ('Fred'), which adequately identifies the operation. However, it does not elaborate on what 'observations' actually are or provide any differentiating detail, and it closely mirrors the tool name.
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 given about when to use this tool, what conditions favor it, or what alternatives exist. Since there are no sibling tools, there is no differentiation burden, but there is also no scenario or prerequisite context to help an agent decide to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_fred_series_observationsScored across 1 tool
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.
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.
