Fred MCP Server

FRED — Federal Reserve Economic Data

The St. Louis Fed's data warehouse: 800,000+ economic time series spanning interest rates, inflation, employment, GDP, money supply, exchange rates, and metro-level indicators. The most authoritative, continuously updated source for US macro and monetary data — used by economists, policymakers, and journalists.

Part of Pipeworx — an MCP gateway connecting AI agents to 1865+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Why this matters for AI agents

Most "what is the current X" macro questions resolve to a FRED series. An agent that knows the series ID can answer with the actual current value, not a training-data snapshot. Common ones:

• 30-year mortgage rate → MORTGAGE30US
• Federal funds rate → DFF
• CPI (all items) → CPIAUCSL
• Unemployment rate → UNRATE
• 10-year treasury yield → DGS10
• Housing starts → HOUST
• Case-Shiller home price index → CSUSHPISA

If your agent is answering a question about US macroeconomic state, the right pattern is fred_search (find the right series) → fred_series_info (confirm units and frequency) → fred_get_series (get the values).

Auth

FRED requires an API key. It's free at https://fred.stlouisfed.org/docs/api/api_key.html — takes 30 seconds, no payment, no rate-limit terror.

Pass via _apiKey per call:

fred_get_series({
  series_id: "MORTGAGE30US",
  _apiKey: "your-fred-api-key"
})

Or subscribe to the Housing Vertical which manages the key for you.

Update cadence

Pipeworx caches FRED responses with TTLs matching these cadences — see caching and freshness.

Citable URI

Embed in your output for stable citations:

pipeworx://fred/series/{series_id}
pipeworx://fred/series/{series_id}/observations

Other agents (and resources/read) can resolve these to the current value of the series.

ALFRED vintages: "what did this number say on date X"

FRED revises most series after first publication (GDP, payrolls, retail sales…). fred_get_series defaults to the latest revised values — pass one of these to ask for an earlier vintage instead:

• as_of: "2020-03-15" — the data exactly as it stood on that date. Shorthand for realtime_start = realtime_end = as_of.
• realtime_start / realtime_end — an explicit publication window, for the rarer case of a custom range rather than a single date.

Omitting all three is the default and is unchanged: no vintage field, same values as before this parameter existed. Passing any of them adds a vintage object to the response ({as_of, realtime_start, realtime_end}) so you can tell which vintage you're looking at.

fred_get_series({ series_id: "GDPC1", as_of: "2024-01-15", limit: 1 })
// -> the GDP print as FRED had it published on 2024-01-15, before later revisions

Two more tools cover the revision history directly:

• fred_vintage_dates({ series_id }) — every date FRED published a new vintage of the series (initial release or a later revision).
• fred_revisions({ series_id, observation_date }) — how ONE observation's value changed across every vintage, from first_release to latest. Use this on revision-prone series (GDP GDPC1, payrolls PAYEMS) to see the originally reported number versus today's.

fred_revisions({ series_id: "GDPC1", observation_date: "2023-10-01" })
// -> revisions: [{ vintage_date: "2023-10-26", value: "22490.692" }, ...]
//    one entry per ALFRED vintage, oldest first; first_release is the
//    earliest, latest the most recent. Consecutive vintages can repeat the
//    same value — compare first_release.value to latest.value to see
//    whether this observation was ever actually revised.

Reading a fred_get_series response

The last two rows are the one to know about. FRED's observations endpoint echoes observation_start/observation_end back as it received them, and substitutes 1600-01-01 / 9999-12-31 when the caller sets neither — so this pack used to report that US GDP ran from 1600 through 9999. Those names now carry the coverage from the series metadata, matching what fred_series_info and fred_search already mean by them.

Regional Fed nowcasts (keyless, not FRED series)

Two tools in this pack proxy regional Federal Reserve Bank websites directly rather than the St. Louis Fed's API — neither series exists in FRED's own catalog, confirmed by fred_search before building. No _apiKey needed.

• nyfed_gdp_nowcast() — the Federal Reserve Bank of New York's weekly real GDP growth nowcast for the quarter(s) it is currently tracking, with 50%/80% probability intervals, the publisher's own narrative, and recent concluded quarters' final nowcast versus the actual BEA GDP print. Updated every Friday.
• cleveland_fed_inflation_nowcast() — the Federal Reserve Bank of Cleveland's daily CPI/PCE inflation nowcast (headline and core), as month-over-month, year-over-year, and quarterly-annualized figures. A blank cell means the official BLS/BEA release for that period already exists. Updated every business day.

nyfed_gdp_nowcast({})
// -> current_estimates: [{ quarter: "2026:Q3", nowcast_pct: 2.7, ... }, { quarter: "2026:Q4", nowcast_pct: 2.8 }]

cleveland_fed_inflation_nowcast({})
// -> current: { month: "October 2026", month_over_month_pct: { cpi: 0.27, ... }, year_over_year_pct: { cpi: 3.77, ... } }

Common pitfalls

• Vintages: FRED preserves historical "vintages" (data as it was reported at time T). Default tool calls get the latest revised series. Pass as_of (or realtime_start/realtime_end) to fred_get_series for as-of queries, or use fred_revisions to see the full history of one observation.
• Frequency aggregation: frequency parameter coerces to a different cadence (e.g., daily → monthly average). Default is the series' native frequency.
• Units transformation: units parameter computes derived series at request time (pch for percent change, pca for compound annual rate, etc.). Don't compute these client-side; let FRED do it.
• Series renamed: occasionally the Fed deprecates a series and creates a successor. Old IDs return errors. fred_search is the recovery path.

Quick Start

Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):

{
  "mcpServers": {
    "fred": {
      "url": "https://gateway.pipeworx.io/fred/mcp"
    }
  }
}

What this endpoint actually serves

tools/list at https://gateway.pipeworx.io/fred/mcp returns the tools in the table above plus the shared Pipeworx meta-tools — ask_pipeworx, discover_tools, search_within, remember/recall and the rest of the gateway-wide set. So the tool count you see is larger than this table: a single-pack endpoint currently lists roughly 30 shared tools alongside the pack's own. The connection's initialize response states its exact scope, and is the authoritative answer for a given day.

This is deliberate, not multiplexing by accident. The meta-tools are what let a scoped connection answer a question this pack does not cover — via ask_pipeworx, which routes across the whole catalog — without you adding a second MCP server. There is currently no way to mount a pack endpoint without them; if the extra schemas cost you more context than the routing is worth, connect to the full gateway once rather than to several pack endpoints.

Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

Both URLs reach the same gateway and the same 1865+ data sources. The only difference is which pack's tools are listed directly; ask_pipeworx reaches all of them from either one.

No MCP client? Call it over HTTP

curl -X POST https://gateway.pipeworx.io/v1/tools/fred_get_series \
  -H 'Content-Type: application/json' \
  -d '{"series_id":"MORTGAGE30US"}'

No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/fred_get_series. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.

Run it from npm

@pipeworx/mcp-fred is a local stdio bridge to the Pipeworx gateway: your MCP client starts it with npx, and it forwards every call to the same https://gateway.pipeworx.io/fred/mcp endpoint shown above. It needs network access; there is no offline mode.

{
  "mcpServers": {
    "fred": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-fred"]
    }
  }
}

Without a key it calls anonymously, capped at 50 calls a day. A free account raises that to 200 a day: get a key at https://pipeworx.io/signup and add "env": { "PIPEWORX_API_KEY": "<your key>" } to the server entry. The key is sent as a Bearer token, the same way a hosted connection sends it, so calls are metered and billed exactly as they are there.

It lists only this pack's tools by default. Set PIPEWORX_META_TOOLS=1 to also list ask_pipeworx and the other gateway-wide tools.

Behind an HTTPS proxy: Node's built-in fetch does not read HTTPS_PROXY by default. Newer Node releases honour it when NODE_USE_ENV_PROXY=1 is set; check your Node version's documentation.

Using with ask_pipeworx

Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:

ask_pipeworx({ question: "your question about Fred data" })

The gateway picks the right tool and fills the arguments automatically.

More

• Docs and guides
• pipeworx.io

License

MIT