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
以下是以正确的 markdown 格式编写的 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执照
[您选择的许可证]
贡献
[您的贡献指南]
致谢
使用模型上下文协议 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.-