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 what's the current unemployment rate?"
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.
A local Model Context Protocol server that gives Claude and other MCP clients access to Federal Reserve Economic Data (FRED) — 800,000+ economic time series covering GDP, inflation, employment, interest rates, and more.
Tool | Description |
| Find a series by natural-language query (e.g. "unemployment rate"), returns the most relevant |
| Metadata for a series — title, units, frequency, date range, and notes. |
| The actual time-series values, with optional transforms (e.g. year-over-year %) and frequency aggregation. |
Related MCP server: mcp-fred
Python 3.10+
uv — used to manage the environment and run the server
A free FRED API key — get one at fredaccount.stlouisfed.org/apikey
git clone https://github.com/yifudiao/fred-mcp.git
cd fred-mcp
uv syncFrom the project directory:
uv run mcp install server.py --name "FRED" -v FRED_API_KEY=your_keyThis writes the connector into Claude Desktop's config for you. Fully quit and reopen Claude Desktop (closing the window is not enough) and the FRED tools will appear.
Alternatively, edit claude_desktop_config.json directly
(Claude Desktop → Settings → Developer → Edit Config):
{
"mcpServers": {
"fred": {
"command": "uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/fred-mcp", "run", "server.py"],
"env": { "FRED_API_KEY": "your_key" }
}
}
}The --directory flag is what makes uv use this project (and its installed
dependencies) regardless of where Claude Desktop launches the process from.
claude mcp add fred -s user -e FRED_API_KEY=your_key -- \
uv --directory /ABSOLUTE/PATH/TO/fred-mcp run server.py-s user makes the server available across all your projects (drop it to scope it to the current project).
Verify with claude mcp list, or /mcp inside a session.
For a project-scoped, committable setup, add a .mcp.json to your project root with the
same command instead.
Example prompts:
Using fred, what is the current unemployment rate?
Using fred, look at the recession indicators, summarize them in a table and assign a probability of recession in 2026.
Editing the server: changes to server.py are picked up on the next Claude Desktop
restart — no reinstall needed. Don't move or rename the project folder, though; the
config points at its absolute path.
Never print() to stdout in a tool. stdout is the JSON-RPC channel for stdio
transport; use the MCP Context logging methods or write to stderr.
Result-size limit: Claude caps tool results at ~150k characters, so
get_observations limits the number of points returned. For long daily series, use
frequency to aggregate rather than raising the limit.
uv: command not found: GUI apps on macOS don't inherit your shell's PATH, so a
freshly installed uv in ~/.local/bin may not be found. Fix by using the absolute
path to uv (which uv) as the command in your config.
Logs: on macOS, see ~/Library/Logs/Claude/mcp-server-*.log for the spawned
server's stdout/stderr — the fastest way to diagnose a failed launch.
Get the observations (actual time-series values) for a FRED series.
Returns a compact list of {date, value} points plus metadata. To stay within the
client's result-size limit, the point count is capped; if a series has more points
than the cap over your window, narrow the date range or aggregate via frequency.
A value of "." means the observation is missing for that date.
Args: series_id: The FRED series ID, e.g. "UNRATE". start_date: Inclusive start "YYYY-MM-DD". Omit for the series start. end_date: Inclusive end "YYYY-MM-DD". Omit for the latest. units: Optional transform: "lin" (levels), "chg", "ch1", "pch", "pc1" (year-over-year %), "pca", "cch", "cca", "log". frequency: Optional down-aggregation: "d","w","bw","m","q","sa","a". Omit to use the series' native frequency. sort_order: "asc" (oldest first) or "desc" (newest first). limit: Max points to return (capped at the server maximum).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| units | No | ||
| end_date | No | ||
| frequency | No | ||
| series_id | Yes | ||
| sort_order | No | asc | |
| start_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It explains the compact return format, the point-count cap, the '.' sentinel for missing values, and parameter behaviors (e.g., units, frequency, sort_order). It does not cover error cases or rate limits, but given the output schema exists, the return metadata structure is not needed here. Substantial behavioral disclosure is present, though a few edge behaviors are omitted.
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 well-structured, starting with a one-sentence purpose, followed by a concise overview of behavior and caps, then a bulleted list of arguments. Every sentence contributes useful information, and the formatting makes it easy to scan. It is appropriately compact for the complexity of the tool.
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?
Given the tool has 7 parameters, no annotations, and no schema descriptions, the description covers all the essential invocation details: required series_id, date handling, transformations, aggregation, sorting, and limits. It also notes the result-size cap and missing value representation. It does not mention potential prerequisites like API keys or rate limits, but those are not implied by the tool's context. The presence of an output schema leaves return format details to the schema. Overall, it is nearly complete, with minor room for adding explicit exclusions or prerequisites.
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?
Schema description coverage is 0%, but the description includes an 'Args' section that thoroughly explains every parameter: series_id with example, start/end dates with format and inclusivity, units with possible values, frequency with possible values, sort_order, and limit. This fully compensates for the lack of schema descriptions, adding significant meaning beyond the raw property types.
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 uses a specific verb+resource: 'Get the observations (actual time-series values) for a FRED series.' It clearly distinguishes this from sibling tools like search_series (searching) and get_series_info (metadata) by indicating this tool retrieves time-series data points. The purpose is unambiguous and action-oriented.
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?
The description provides clear context for when to use the tool, such as retrieving observations over a date range with optional transformations. It gives practical guidance on handling result-size caps (narrow date range or use frequency aggregation), but it does not explicitly name alternatives or state when not to use this tool relative to siblings. This is clear context without explicit exclusions, meriting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a specific FRED series (title, units, frequency, range, notes).
Args: series_id: The FRED series ID, e.g. "UNRATE" or "GDPC1".
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'Get' suggests read-only behavior and the listed metadata fields indicate what is returned, but it does not disclose potential side effects, authentication needs, rate limits, or error behavior. It is not misleading but lacks depth.
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 extremely compact: a one-sentence purpose statement followed by a minimal Args block. Every word earns its place, and the key information is front-loaded.
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?
Given the tool's simplicity (1 parameter) and the existence of an output schema, the description sufficiently covers purpose and parameter semantics. It could be slightly more complete by noting that search_series should be used if the series ID is unknown, but overall it's adequate.
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?
Schema description coverage is 0%, so the description must compensate. The Args section clearly defines 'series_id' with concrete examples ('UNRATE' or 'GDPC1'), which adds meaning far beyond the bare schema title 'Series Id'.
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 clearly states the tool retrieves metadata for a specific FRED series, listing example metadata fields (title, units, frequency, range, notes). This specific verb+resource phrasing distinguishes it from siblings like search_series (searching) and get_observations (retrieving data points).
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?
The description implies usage when you already know a specific series ID, but it does not explicitly state when to use this tool versus search_series or get_observations, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FRED for economic data series matching a text query.
Use this first to turn a natural-language request (e.g. "real median household income, seasonally adjusted") into a concrete series_id for get_observations. Results are ordered by popularity.
Args: query: Free-text search, e.g. "unemployment rate" or "10-year treasury". limit: Max number of series to return (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the search-and-return behavior, ordering, and the practical mapping from natural language to series_id. It stops short of describing the exact return structure, but the output schema likely covers that. This is solid for a non-destructive search tool.
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 concise and well-structured: a lead sentence, a usage context sentence, a result-ordering note, and a clear Args list. Every sentence adds value, no redundancy or fluff.
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?
Given the simple two-parameter input, an output schema that likely defines return values, and clear guidance on purpose and usage, the description is complete. It gives the agent all needed context to invoke the tool correctly.
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?
Schema coverage is 0%, so the description fully compensates. It explains query as free-text search with examples, and limit as max number of series with a range (1-50). This adds meaning well beyond the bare schema properties.
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 clearly states the tool searches FRED for data series matching a query, with a specific verb ('Search'), resource ('FRED'), and scope ('economic data series'). It also distinguishes itself from siblings by indicating its role in converting natural language to a series_id for get_observations.
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?
Explicitly says 'Use this first' and names the downstream consumer (get_observations), providing clear when-to-use guidance. It also mentions ordering by popularity, which helps set expectations. No exclusions needed for a search tool.
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. Dates show when Glama detected each change.
v0.1.0get_observationsget_series_infosearch_seriesScored across 3 tools
Each tool has a clearly distinct purpose: search_series discovers series IDs, get_series_info retrieves metadata for a known series, and get_observations fetches time-series data. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern: search_series, get_series_info, get_observations. The verbs are specific and the objects are clear, making the naming predictable and readable.
With only three tools, the server is tightly scoped for its purpose of accessing FRED economic data. Each tool fills an essential role in the workflow—search, metadata, and observations—without unnecessary additions.
The tool set fully covers the core workflow for a read-only economic data API: discover series via search, understand a series via metadata, and retrieve its values. No obvious gaps exist for the stated domain; all necessary operations for accessing FRED data are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Hosted MCP server for live public-data APIs and Skills for AI agents.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yifudiao/fred-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server