A
licenseC
qualityD
maintenanceProvides access to economic data from the Federal Reserve Bank of St. Louis (FRED) through the Model Context Protocol, allowing AI assistants to retrieve economic time series data directly.
1
6
MIT
FRED MCP Server
by kablewy
다음은 적절한 마크다운 형식으로 작성된 README입니다.
FRED MCP 서버
연방준비제도이사회 경제 데이터(FRED) API에 접근하기 위한 모델 컨텍스트 프로토콜(MCP) 서버 구현입니다. 이 서버는 FRED에서 경제 데이터 시리즈를 검색하고 불러오는 도구를 제공합니다.
필수 조건
Node.js(v16 이상)
FRED API 키( FRED API 에서 얻음)
Related MCP server: FRED MCP Server
설치
저장소를 복제합니다.
지엑스피1
종속성 설치:
npm install.env.example파일을.env로 복사하고 FRED API 키를 추가하세요.FRED_API_KEY=your_api_key_here
용법
개발
개발 모드에서 서버를 실행합니다.
npm run dev생산
프로젝트를 빌드하세요:
npm run build서버를 시작합니다:
npm start
사용 가능한 도구
서버는 다음과 같은 FRED API 도구를 제공합니다.
시리즈 검색
다양한 매개변수를 사용하여 경제 데이터 시리즈를 검색합니다.
시리즈 관찰
다음 옵션을 사용하여 특정 경제 데이터 시리즈에 대한 관찰 결과를 검색합니다.
날짜 범위 필터링
주파수 조정
집계 방법
정렬 및 페이지 매김
개발
프로젝트 구조
fred-mcp-server/
├── src/
│ ├── index.ts # Server entry point
│ ├── tools.ts # Tool implementations
│ └── types.ts # TypeScript interfaces
├── package.json
├── tsconfig.json
└── .env테스트
테스트 모음을 실행합니다.
npm test특허
[선택하신 라이센스]
기여하다
[귀하의 기여 지침]
감사의 말
모델 컨텍스트 프로토콜 SDK 로 구축됨
연방준비제도이사회 경제데이터(FRED) 에서 제공하는 데이터
Available Tools
2 toolssearchB
Search for FRED data series with advanced filtering options
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| searchText | Yes | Search text for FRED series | |
| limit | No | Maximum number of results to return (default: 1000) | |
| orderBy | No | Order results by this property | |
| sortOrder | No | Sort order (default: asc) | |
| filterVariable | No | Variable to filter results by | |
| filterValue | No | Value of filter variable | |
| tagNames | No | Series tags to include | |
| excludeTagNames | No | Series tags to exclude |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'advanced filtering options' but doesn't explain what 'advanced' entails, such as pagination, rate limits, authentication needs, or what happens with invalid inputs. For a search tool with 8 parameters, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a search tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, no output schema), the description is minimal. It states the purpose but lacks details on usage, behavioral traits, or output format. While concise, it doesn't fully compensate for the missing structured data, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by hinting at 'advanced filtering options,' but doesn't provide additional meaning or context beyond what's in the schema. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('FRED data series'), and mentions 'advanced filtering options' which adds specificity. However, it doesn't explicitly differentiate from the 'series' sibling tool, which might offer different functionality like retrieving specific series details rather than searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the 'series' sibling tool, nor does it mention any prerequisites, contexts, or exclusions for usage. It's a generic statement that lacks operational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seriesC
Get observations for a specific FRED data series with advanced options
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| seriesId | Yes | FRED series ID | |
| startDate | No | Start date in YYYY-MM-DD format | |
| endDate | No | End date in YYYY-MM-DD format | |
| sortOrder | No | Sort order (default: asc) | |
| limit | No | Maximum number of results to return | |
| offset | No | Number of results to skip | |
| frequency | No | Frequency of observations (d=daily, w=weekly, bw=biweekly, m=monthly, q=quarterly, sa=semiannual, a=annual) | |
| aggregationMethod | No | Aggregation method for frequency conversion (avg=average, sum=sum, eop=end of period) | |
| outputType | No | 1=observations by real-time period, 2=observations by vintage date, 3=vintage dates, 4=initial release plus current value | |
| vintageDates | No | Vintage dates in YYYY-MM-DD format |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, pagination behavior (beyond the limit/offset parameters), or what the output looks like. For a tool with 10 parameters and no output schema, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the core purpose. Every word earns its place - 'Get observations' establishes the action, 'for a specific FRED data series' specifies the resource, and 'with advanced options' hints at the parameter complexity without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'observations' are in the FRED context, doesn't mention authentication requirements, doesn't describe the return format, and provides no guidance on parameter interactions. The 100% schema coverage helps, but the description itself lacks necessary context for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'advanced options' which hints at the numerous parameters, but doesn't provide additional context about parameter interactions, defaults, or usage patterns. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get observations for a specific FRED data series with advanced options'. It specifies the verb ('Get'), resource ('observations for a specific FRED data series'), and scope ('with advanced options'). However, it doesn't explicitly differentiate from the sibling 'search' tool, which likely searches for series rather than retrieving observations for a specific series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions 'advanced options' but doesn't specify what makes it advanced or when simpler alternatives might exist. There's no mention of the sibling 'search' tool, prerequisites, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
search - First observed
series
TDQS
B3.1/5.0
Scored across 2 tools
Disambiguation4/5
The two tools have distinct purposes: 'search' is for finding data series, while 'series' is for retrieving observations for a specific series. There is minimal overlap, though the 'advanced options' in both descriptions could cause slight confusion if not detailed further, but the core functions are clearly separated.
Naming Consistency5/5
Both tool names are single, lowercase nouns ('search' and 'series'), which is consistent and simple. There are no mixed conventions or deviations, making the naming pattern predictable and easy to understand.
Tool Count2/5
With only 2 tools, the server feels thin for a data service like FRED, which typically involves more operations such as listing categories, getting metadata, or managing favorites. This limited set may hinder agents from performing comprehensive tasks in the domain.
Completeness2/5
The tool surface is severely incomplete for a FRED server. It lacks essential operations like listing available series categories, retrieving series metadata, or supporting updates and deletions. Agents will face significant gaps when trying to navigate or manipulate FRED data beyond basic search and observation retrieval.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents. This is the official MCP server of www.ceyloncharts.com
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that provides access to Federal Reserve Economic Data (FRED), enabling users to retrieve, analyze, and compare economic indicators and time series data through natural language.2-
- FlicenseNot gradedqualityDmaintenanceAn MCP server that wraps the Federal Reserve Economic Data (FRED) API, providing access to over 800,000 economic time series like GDP and unemployment. It enables AI agents to search for data, retrieve metadata, and fetch historical observations directly from the St. Louis Fed.-
- FlicenseNot gradedqualityDmaintenanceFastMCP server for querying FRED financial and macroeconomic data, providing tools to search and retrieve economic indicators.-