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
Uses .ENV to manage environment variables, particularly for storing and accessing the FRED API key securely.
Supports Git for version control, with instructions for cloning the repository as part of the installation process.
Hosts the repository at github.com/kablewy/fred-mcp-server, allowing for easy distribution and installation.
Requires Node.js v16 or higher as a runtime environment for the server.
Uses npm for package management, dependency installation, and running server commands through scripts.
Implements the server using TypeScript for type safety, with references to TypeScript interfaces and configuration.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@FRED MCP Serverget the unemployment rate for the last 6 months"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Here's the README formatted in proper markdown:
FRED MCP Server
A Model Context Protocol (MCP) server implementation for accessing the Federal Reserve Economic Data (FRED) API. This server provides tools to search and retrieve economic data series from FRED.
Prerequisites
Node.js (v16 or higher)
FRED API Key (obtain from FRED API)
Related MCP server: FRED MCP Server
Installation
Clone the repository:
git clone https://github.com/kablewy/fred-mcp-server cd fred-mcp-serverInstall dependencies:
npm installCopy the
.env.examplefile to.envand add your FRED API key:FRED_API_KEY=your_api_key_here
Usage
Development
Run the server in development mode:
npm run devProduction
Build the project:
npm run buildStart the server:
npm start
Available Tools
The server provides the following FRED API tools:
Series Search
Search for economic data series using various parameters.
Series Observations
Retrieve observations for a specific economic data series with options for:
Date range filtering
Frequency adjustment
Aggregation methods
Sorting and pagination
Development
Project Structure
fred-mcp-server/
├── src/
│ ├── index.ts # Server entry point
│ ├── tools.ts # Tool implementations
│ └── types.ts # TypeScript interfaces
├── package.json
├── tsconfig.json
└── .envTesting
Run the test suite:
npm testLicense
[Your chosen license]
Contributing
[Your contribution guidelines]
Acknowledgments
Built with Model Context Protocol SDK
Data provided by Federal Reserve Economic Data (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.
TDQS
B3.1/5.0
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
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
FRED MCP — Federal Reserve Economic Data (St. Louis Fed)
FRED macro data, Treasury yields, FX rates & macro indicators for AI agents. Pay-per-query via x402.
Equip AI with tools for researching economic data from Federal Reserve Economic Data (FRED).
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.
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 gradedqualityCmaintenanceFastMCP server for querying FRED financial and macroeconomic data, providing tools to search and retrieve economic indicators.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kablewy/fred-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server