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
インストール
リポジトリをクローンします。
git clone https://github.com/kablewy/fred-mcp-server cd fred-mcp-server依存関係をインストールします:
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ライセンス
[選択したライセンス]
貢献
[ご寄稿のガイドライン]
謝辞
連邦準備制度経済データ（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.-