FRED(연방준비제도이사회 경제 데이터) API와 모델 컨텍스트 프로토콜(MCP) 통합
Related MCP server: FRED MCP Server
MCP-FREDAPI는 모델 컨텍스트 프로토콜(Model Context Protocol)을 통해 세인트루이스 연방준비은행(FRED)의 경제 데이터에 대한 접근을 제공합니다. 이러한 통합을 통해 Claude와 같은 AI 비서가 Cursor 또는 기타 MCP 호환 환경에서 경제 시계열 데이터를 직접 검색할 수 있습니다.
이 패키지는 공식 FRED API 와 통합되어 있으며, 특히 경제 지표에 대한 시계열 데이터를 제공하는 series_observations 엔드포인트 에 초점을 맞춥니다.
설치 방법은 두 가지가 있습니다.
필요한 종속성을 설치하세요:
지엑스피1
이 저장소를 복제하세요:
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 | - | (필수의) | ✅ 작동 |
정렬 순서 | 힘 | 관찰 결과 정렬 순서 | '오름차순', '내림차순' | '오름차순' | ✅ 작동 |
단위 | 힘 | 데이터 값 변환 | '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) | - | 없음 | ❌ 작동하지 않음 |
실시간 종료 | 힘 | 실시간 기간 종료(YYYY-MM-DD) | - | 없음 | ❌ 작동하지 않음 |
한계 | 정수/문자열 | 반환할 최대 관찰 수 | 1에서 100000 사이 | 10 | ❌ 작동하지 않음 |
오프셋 | 정수/문자열 | 처음부터 건너뛸 관찰 수 | - | 0 | ❌ 작동하지 않음 |
관찰_시작 | 힘 | 관찰 시작 날짜(YYYY-MM-DD) | - | 없음 | ❌ 작동하지 않음 |
관찰_끝 | 힘 | 관찰 종료일(YYYY-MM-DD) | - | 없음 | ❌ 작동하지 않음 |
빈티지_날짜 | 힘 | 쉼표로 구분된 빈티지 날짜 목록 | - | 없음 | ❌ 작동하지 않음 |
[!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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
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.
