FRED (連邦準備制度経済データ) API とモデルコンテキストプロトコル (MCP) の統合
Related MCP server: FRED MCP Server
MCP-FREDAPIは、モデルコンテキストプロトコルを介してセントルイス連邦準備銀行（FRED）の経済データへのアクセスを提供します。この統合により、Cursorやその他のMCP互換環境と併用することで、ClaudeのようなAIアシスタントが経済時系列データを直接取得できるようになります。
このパッケージは公式の FRED APIと統合され、特に経済指標の時系列データを提供するseries_observations エンドポイントに重点を置いています。
インストール方法は 2 つあります。
必要な依存関係をインストールします。
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-fredapiuv を使用してサーバーを実行します (依存関係を個別にインストールする必要はありません)。
uv run --with mcp --with httpx mcp run server.pyFRED API キーが必要になります。これはFRED APIから取得できます。
プロジェクト ルートに.envファイルを作成します。
FRED_API_KEY=your_api_key_hereこの MCP サーバーを使用するように Cursor を構成するには、 ~/.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 | str | 経済シリーズのID | - | （必須） | ✅ 動作します |
並べ替え順序 | str | 観測値の並び替え順 | 「昇順」、「降順」 | '昇順' | ✅ 動作します |
ユニット | str | データ値の変換 | 「lin」、「chg」、「ch1」、「pch」、「pc1」、「pca」、「cch」、「cca」、「log」 | 「リン」 | ✅ 動作します |
頻度 | str | 観察頻度 | 'd'、'w'、'bw'、'm'、'q'、'sa'、'a'、'wef'、'weth'、'wew'、'wetu'、'wem'、'wesu'、'wesa'、'bwew'、'bwem' | なし | ✅ 動作します |
集計方法 | str | 頻度の集計方法 | 「平均」、「合計」、「eop」 | '平均' | ✅ 動作します |
出力タイプ | 整数 | 観測の出力タイプ | 1、2、3、4 | 1 | ✅ 動作します |
リアルタイム開始 | str | リアルタイム期間の開始 (YYYY-MM-DD) | - | なし | ❌ 動作しない |
リアルタイム終了 | str | リアルタイム期間の終了日（YYYY-MM-DD） | - | なし | ❌ 動作しない |
制限 | 整数/文字列 | 返される観測の最大数 | 1から100000の間 | 10 | ❌ 動作しない |
オフセット | 整数/文字列 | 最初からスキップする観測数 | - | 0 | ❌ 動作しない |
観察開始 | str | 観察開始日（YYYY-MM-DD） | - | なし | ❌ 動作しない |
観察終了 | str | 観察終了日（YYYY-MM-DD） | - | なし | ❌ 動作しない |
ヴィンテージ日付 | str | ヴィンテージ日付のカンマ区切りリスト | - | なし | ❌ 動作しない |
[!WARNING]パラメータの互換性に関する注意
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.
