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 What's the unemployment rate right now?"
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.
FRED® economic data inside your AI agent — including what the numbers said before the revisions. An MCP server for the Federal Reserve Bank of St. Louis's FRED® API: search and read 800,000+ U.S. and international time series, follow the release calendar, and — the distinctive part — query ALFRED® vintage data: any series exactly as it was known on a past date, and any single data point's full revision history from its initial print to today's value.
Read-only, built on public endpoints, powered by your own free FRED API key. Live API calls with a volatility-aware cache (vintage reads are immutable and cache long; current data stays fresh) — no bulk mirroring.
This product uses the FRED® API but is not endorsed or certified by the Federal Reserve Bank of St. Louis. By using this server you agree to the FRED® API Terms of Use.
Status: v0.1.0 — live on PyPI
(uvx mcpwright-fred) and the official MCP Registry
(io.github.mcpwright/fred-mcp). 9 tools, CI-gated, built on
mcpwright-core.
Economic numbers get revised — sometimes dramatically. The advance estimate
of Q4-2008 real GDP told policymakers the economy was shrinking far more
slowly than the number that stands today. If an agent reasons about what
decision-makers knew at the time using current data, it is quietly wrong.
get_series_as_of and get_revision_history make as-published data a
first-class question.
Related MCP server: FRED Economic MCP Server
Tool | What it does |
| Find series IDs by free text, best matches first |
| One series' full metadata + verbatim notes |
| A date window of values; transforms ( |
| The most recent value + the next scheduled release date |
| 2–5 series aligned on one date axis |
| Upcoming data releases ("when's the next jobs report?") |
| A series exactly as known on a past date (ALFRED vintage) |
| One data point's life: initial print → every revision → today |
| When a series was released/revised; bounds the vintage tools |
All tools are read-only and annotated as such.
Every question below was run live against the real FRED API through these tools (answers as of June 2026 — ask again and they'll be current).
Everyday questions:
"What's the unemployment rate right now, and when's the next jobs
report?" — get_latest(UNRATE) → 4.3% (May 2026), next release 2026-07-02.
"What's the 10-year Treasury yield today?" — get_latest(DGS10) → 4.53%
(it correctly skips the . rows daily series publish on holidays).
"How has inflation trended over the past year?" —
get_observations(CPIAUCSL, transform=pct_change_yoy) → 2.4% → 3.3% →
3.8% → 4.2% over Feb–May 2026.
"Find me data on median household income." — search_series →
MEHOINUSA672N (real) and MEHOINUSA646N (nominal), annual.
"Is the labor market loosening? Compare unemployment and job openings
since 2024." — compare_series([UNRATE, JTSJOL]) → one aligned table.
"What economic data comes out this week?" — get_release_calendar(7) →
241 release dates, CPI included.
"What was real GDP growth each quarter of 2025?" —
get_observations(A191RL1Q225SBEA) → −0.6, +3.8, +4.4, +0.5%.
"Give me CPI as annual averages for the 2020s." —
get_observations(CPIAUCSL, frequency=annual) → one row per year.
Questions only the vintage tools can answer:
"How bad did Q4-2008 GDP look to policymakers in early 2009, versus what
we know now?" — get_series_as_of(GDPC1, "2009-02-15") → a −3.8%
annualized decline as known then (in chained-2000 dollars — the metadata
is vintage-pinned too) versus −8.5% in today's data. Policy ran on the
first number.
"Was the May 2020 COVID unemployment rate ever revised?" —
get_revision_history(UNRATE, "2020-05-01") → first published as 13.3
(2020-06-05), currently 13.2, with each revision dated.
"What mortgage rate did the Fed see going into the March 2022 liftoff
meeting?" — get_series_as_of(MORTGAGE30US, "2022-03-16") → 3.85% as
known then; 6.48% today.
"How often does GDP actually get revised?" — get_vintage_dates(GDPC1)
→ 415 vintages since 1991-12-04.
You need a free FRED API key (takes seconds): https://fred.stlouisfed.org/docs/api/api_key_request.html. Keys are personal under the FRED terms — bring your own.
uvx (any MCP client){
"mcpServers": {
"fred": {
"command": "uvx",
"args": ["mcpwright-fred"],
"env": { "FRED_API_KEY": "your-key-here" }
}
}
}claude mcp add fred -e FRED_API_KEY=your-key-here -- uvx mcpwright-fredUse the one-click .mcpb extension from the
latest release (it prompts
for your API key), or add the uvx JSON above to your
claude_desktop_config.json.
Any MCP-capable client works — point it at uvx mcpwright-fred over stdio
with FRED_API_KEY in the environment.
Revisions: current values often differ from what was originally published; for "what was known at the time", use the vintage tools.
Copyrighted series: some FRED series are owned by third parties; their
notes carry the owner's terms (surfaced verbatim, flagged via
copyrighted). You are responsible for complying with them beyond personal
use.
Caching & rate limits: responses are cached in-memory (vintage reads
long, live reads short) and requests are throttled well under FRED's rate
limit. Set FRED_MCP_CACHE=0 to disable caching, FRED_MCP_USER_AGENT to
identify your own deployment.
git clone https://github.com/mcpwright/fred-mcp && cd fred-mcp
uv sync
uv run pytest # tests
uv run mypy # types
uv run ruff check src/ && uv run ruff format --check src/ # lint + format
uv run pre-commit run --all-files # everything, like CIDev loop: feature branch → PR → Code Quality & Tests green → squash-merge.
v1 tool surface (9 tools incl. the ALFRED vintage lane)
Publish to PyPI (mcpwright-fred) + the MCP Registry
Site page at mcpwright.com/fred
.mcpb one-click Claude Desktop extension (v0.1.0 release)
GeoFRED / maps (pairs with census-mcp)
Discussions for questions and ideas · Issues for bugs.
Part of mcpwright — polished MCP servers for authoritative public data · built by Devender Gollapally. FRED® and ALFRED® are registered trademarks of the Federal Reserve Bank of St. Louis. This project is not affiliated with, endorsed, or certified by the Federal Reserve Bank of St. Louis.
Align 2-5 series on one date axis for comparison.
`series_ids`: 2-5 FRED series IDs. Same `start`/`end`/`transform` as
`get_observations`. If the series have DIFFERENT native frequencies you
must pass `frequency` (a frequency at least as coarse as the coarsest
series) — mixing frequencies without it returns misaligned dates. Units
differ per series unless a relative transform (e.g. pct_change_yoy) is
used — check each entry's `units` before comparing levels.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| frequency | No | ||
| transform | No | level | |
| max_points | No | ||
| series_ids | Yes |
| Name | Required | Description |
|---|---|---|
| rows | Yes | Aligned values, oldest first |
| series | Yes | The series compared |
| transform | Yes | The transform applied to every series |
| truncated | Yes | True if more rows exist than were returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behaviors: misalignment if frequency not specified, unit dependency on transform, and the 2-5 series limit, adding value beyond readOnlyHint and openWorldHint annotations.
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?
Front-loaded with purpose, uses efficient bullet-like structure; every sentence adds value, though could be slightly more concise.
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?
Covers core purpose, key caveats, and parameter constraints; defers some parameter details to get_observations, which is acceptable given output schema exists.
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?
Adds meaning for series_ids (2-5 IDs) and frequency (coarse enough), but defers start/end/transform to get_observations and omits max_points, only partially compensating for 0% schema coverage.
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 compares multiple series aligned on one date axis, distinguishing it from single-series tools like 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?
Provides clear guidance on when to use the frequency parameter for mixed-frequency series and warns about unit differences, but does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most recent value of a series, plus its next scheduled release.
`series_id`: a FRED series ID. The value is the most recent NON-MISSING
print (daily series publish '.' on holidays) and is CURRENT data — it may
itself be revised later (see `get_revision_history` for how much this
series typically moves). `next_release_date` is null when FRED publishes
no schedule for the series' release.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| date | Yes | Date of the latest observation (period start) |
| title | Yes | Series title |
| units | Yes | Units of the value |
| value | Yes | The latest value (null if missing) |
| series_id | Yes | The FRED series ID |
| last_updated | Yes | When FRED last updated this series |
| next_release_date | No | The next scheduled release date for this series' release, if FRED publishes a schedule for it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds behavioral details: the value is the most recent non-missing print, daily series use '.' on holidays, it's current but may be revised, and next_release_date is null when no schedule is published. No contradictions.
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: one topic sentence followed by a focused paragraph on the parameter and behavior. Every sentence adds value, with 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 presence of an output schema (not shown), the description omits return values, which is acceptable. It covers the main behavior, parameter semantics, and edge cases (null next_release_date). Minor gap: no mention of error handling for invalid series_id, but overall complete for the tool's simplicity.
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?
With 0% schema description coverage, the description defines series_id as 'a FRED series ID,' adding basic meaning beyond the schema. However, it does not provide format, examples, or constraints, making it adequate but not rich.
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 states 'The most recent value of a series, plus its next scheduled release,' specifying a clear verb (get) and resource (value and release date). It distinguishes from siblings like get_observations and get_revision_history.
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 explicitly points to get_revision_history as an alternative when interested in revisions, and explains that the data is current and may be revised. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A series' values in a date window, optionally transformed/downsampled.
`series_id`: a FRED series ID. `start`/`end`: ISO dates bounding the
window. `transform`: level | change | pct_change | pct_change_yoy | log.
`frequency`: optionally downsample to daily/weekly/monthly/quarterly/
semiannual/annual (with `aggregation` avg | sum | eop); only coarser than
the native frequency is valid. `max_points` caps the result, keeping the
most RECENT points (`truncated` tells you when the cap bit).
Values are CURRENT (post-revision) data. For numbers as originally
published, use `get_series_as_of` / `get_revision_history`.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| frequency | No | ||
| series_id | Yes | ||
| transform | No | level | |
| max_points | No | ||
| aggregation | No | avg |
| Name | Required | Description |
|---|---|---|
| title | Yes | Series title |
| units | Yes | Units of the VALUES RETURNED — the native units when transform='level', otherwise the transform (e.g. '% change from year ago') |
| frequency | Yes | Frequency of the values returned |
| series_id | Yes | The FRED series ID |
| transform | Yes | The transform applied (level if none) |
| truncated | Yes | True if more observations exist than were returned — narrow the date range or raise max_points for more |
| observations | Yes | The data points, oldest first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds critical behavioral context: values are current post-revision data, and max_points truncation keeps most recent points with a truncated flag. This goes beyond annotations.
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 efficiently structured with a one-sentence summary followed by a bullet-like list of parameter details. Every sentence adds value without redundancy, and the most important info 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 7 parameters, 1 required, and an output schema present (not shown), the description covers all parameter semantics, usage guidelines, and behavioral traits. It is fully self-contained and useful for an agent to select and invoke the tool.
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. It explains each parameter: series_id (FRED series ID), start/end (ISO dates), transform (with options), frequency/aggregation (downsampling rules), and max_points (capping behavior). This adds full meaning beyond the bare schema.
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 returns 'A series' values in a date window, optionally transformed/downsampled', using specific verbs and resources. It distinguishes from siblings like get_revision_history and get_series_as_of by highlighting the transformation and downsampling capabilities.
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 explicit guidance on when to use alternatives, e.g., 'For numbers as originally published, use get_series_as_of / get_revision_history'. It explains transform and frequency options but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upcoming data-release dates ("when is the next jobs report / CPI?").
`days`: how far ahead to look (1-90, default 14). Returns each release's
name and date, soonest first. Dates are the SCHEDULED dates FRED knows
about; not every release publishes a schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
| end | Yes | Window end (YYYY-MM-DD) |
| start | Yes | Window start (YYYY-MM-DD) |
| releases | Yes | Release dates in the window, soonest first |
| truncated | No | True if more release dates exist in the window than were returned — an absent release is NOT proof nothing is scheduled; narrow `days` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations by noting dates are scheduled and not all releases publish a schedule. This informs about data completeness, complementing the readOnlyHint and openWorldHint annotations.
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?
Description is extremely concise: two sentences and a parameter note. Front-loaded with purpose, no redundant text.
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 presence of an output schema, the description covers what the tool returns (name and date sorted soonest first) and the sole parameter. This is complete for a simple listing tool.
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 has 0% coverage, but description fully explains the days parameter: valid range (1-90), default (14), and behavior. This compensates entirely for the schema gap.
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?
Description clearly states the tool returns upcoming data-release dates with examples like jobs report or CPI. It distinguishes from sibling tools that deal with series data, not calendar events.
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?
Description provides example usage ('when is the next jobs report / CPI?') and explains the days parameter range. It implies usage for calendar queries but does not explicitly contrast with alternatives like get_series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One data point's life across revisions: earliest archived print -> today.
`series_id`: a FRED series ID. `observation_date`: the data point's PERIOD
START date (ISO) — quarterly series use quarter starts (Q4 2008 =
"2008-10-01"), monthly use month starts. Returns the earliest archived
value, every revision with its publication date, the current value, and
the total drift.
Caveat: ALFRED's archive starts late for many series (`archive_starts`
shows where). `initial_value` is the true first print — what
decision-makers actually saw — only when the archive reaches back to the
observation's original release.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes | ||
| observation_date | Yes |
| Name | Required | Description |
|---|---|---|
| steps | Yes | Each distinct value the point has held, oldest first (consecutive re-publications of an unchanged value are merged) |
| title | Yes | Series title |
| units | Yes | Units of the values |
| series_id | Yes | The FRED series ID |
| current_value | Yes | The value as published today, after all revisions |
| initial_value | Yes | The value in ALFRED's earliest archived vintage — the as-published 'real-time' number when archive_starts reaches back to the observation's release |
| archive_starts | No | The first vintage in ALFRED's archive for this point. If this is much later than observation_date, initial_value is the earliest ARCHIVED value, not the true first print |
| total_revision | No | current_value - initial_value (null if either is missing) |
| steps_truncated | No | True if middle revisions were omitted to cap the list (the initial and current steps are always kept) |
| observation_date | Yes | The observation the history is for (period start date) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, but the description adds critical behavioral context: it details the return value (initial, revisions, current, drift), explains archive start caveats, and clarifies what 'initial_value' represents. No contradiction with annotations.
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 with an overview sentence, parameter explanations, and a caveat paragraph. It is concise without unnecessary words, though the caveat could be slightly more streamlined.
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 complexity (revision history with archive limitations) and the presence of an output schema, the description adequately covers input, output, and important caveats. It is complete for an agent to understand usage.
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 has 0% description coverage, but the description fully explains both parameters: series_id is a FRED series ID, observation_date is the period start date in ISO format with examples for quarterly and monthly series. This adds significant meaning beyond the bare schema.
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 returns 'one data point's life across revisions' and specifies the output includes earliest archived value, every revision with publication date, current value, and total drift. It distinguishes itself from siblings like get_latest or get_observations by focusing on revision history.
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 use for revision history but does not explicitly state when to use this tool vs alternatives like compare_series or get_observations. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full metadata for one series: units, frequency, range, and notes.
`series_id`: a FRED series ID (e.g. "GDPC1"). The `notes` are returned
verbatim — they carry methodology caveats and, for third-party series,
the owner's copyright terms (also flagged via `copyrighted`).
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| notes | No | The series' FRED notes, verbatim — methodology, caveats, and any copyright notice (never stripped) |
| title | Yes | Series title |
| units | Yes | Units of the raw data |
| frequency | Yes | Native frequency |
| series_id | Yes | The FRED series ID |
| popularity | No | FRED popularity rank component |
| copyrighted | Yes | True if third-party-copyrighted (see notes for the owner's terms) |
| last_updated | Yes | When the series data was last updated |
| observation_end | Yes | Latest observation date (YYYY-MM-DD) |
| observation_start | Yes | First observation date (YYYY-MM-DD) |
| seasonal_adjustment | Yes | Seasonal adjustment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), description adds behavioral context: notes returned verbatim with methodology caveats and copyright terms flagged via 'copyrighted'. No contradictions. Could expand on response format but covered by output schema.
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?
Extremely concise: two sentences plus parameter note. First sentence sets overall purpose; second clarifies the sole parameter. No wasted words, 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 simple tool (one parameter, has output schema, annotations present), description covers purpose, parameter, and behavioral nuance. Complete for agent to use 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 has 0% description coverage. Description compensates by explaining 'series_id: a FRED series ID (e.g. 'GDPC1')', adding format and example. This provides meaning beyond schema's type and required flag.
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?
Description clearly states 'Full metadata for one series: units, frequency, range, and notes.' It specifies the verb (get) and resource (series metadata). Differentiates from siblings like search_series (multiple series) and get_observations (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?
Description implies usage for obtaining metadata of a known series with example 'GDPC1'. While not explicit about when not to use, the context from sibling tool names (e.g., search_series, get_observations) provides clear alternatives. No explicit exclusions or alternative names mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A series EXACTLY as it was known on a past date — before later revisions.
`series_id`: a FRED series ID. `as_of`: the knowledge date (ISO) — e.g.
"2009-03-18" shows the data the Fed saw at its March 2009 meeting.
`start`/`end` bound the observation window as usual.
Vintage coverage varies by series: dates before the first vintage have no
data (check `get_vintage_dates`). Values can differ sharply from today's —
that's the point.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| as_of | Yes | ||
| start | No | ||
| series_id | Yes | ||
| max_points | No |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | The knowledge date — values are as published on this date, before any later revisions |
| title | Yes | Series title (current title) |
| units | Yes | Units of the values |
| series_id | Yes | The FRED series ID |
| truncated | Yes | True if more observations exist than were returned |
| observations | Yes | The data as known on as_of, oldest first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. The description adds beyond that by mentioning that vintage coverage varies, dates before the first vintage have no data, and values can differ sharply from today's. This informs the agent about expected behavior and limitations, complementing the annotations without contradiction.
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 (approx. 80 words) and well-structured: a clear purpose statement, followed by parameter explanations and behavioral notes. Every sentence adds value with no redundancy or fluff, achieving optimal density of information.
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 complexity of vintage data retrieval and the presence of an output schema, the description covers the core concept, parameter usage, and key behavioral nuance (vintage coverage). It references a sibling tool for further checking. It does not discuss the output format or pagination, but the output schema likely handles that. Overall, it is adequately complete for an agent to use 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 description coverage is 0%, so the description must compensate. It explains 'series_id' and 'as_of' well, including an example, and describes 'start' and 'end' as bounding the observation window. However, 'max_points' is not mentioned at all. With 5 parameters and only partial coverage, the description adds some meaning but leaves a gap.
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's purpose: retrieving a series exactly as it was known on a past date, before later revisions. It distinguishes itself from siblings like 'get_observations' (current data) and 'get_revision_history' (tracking changes) by emphasizing the vintage aspect, providing a specific verb-resource-scope.
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 concrete usage context, such as showing data the Fed saw at a meeting, and advises to check 'get_vintage_dates' for coverage. It implies when to use (for historical revisions) and when not to (for current data), though it does not explicitly list alternatives. The guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When a series' data was released or revised (its ALFRED vintages).
`series_id`: a FRED series ID. Answers "how often is this revised?" and
bounds the vintage tools: `get_series_as_of` has no data before
`first_vintage`. The full list is capped to the most recent dates;
`total_vintages` is the true count.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| series_id | Yes | The FRED series ID |
| truncated | Yes | True if total_vintages exceeds the dates listed |
| first_vintage | No | The earliest vintage date — as-of queries before this date have no data |
| vintage_dates | Yes | Vintage dates, most recent first (capped — see truncated) |
| latest_vintage | No | The most recent vintage date |
| total_vintages | Yes | Total number of vintage dates on record |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. Description adds that the full list is capped to most recent dates with total_vintages being true count, disclosing a key behavioral limitation. No contradiction with annotations.
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?
Three concise sentences with line breaks for readability. Not verbose, but could be slightly more structured (e.g., bullet points for parameter). Every sentence contributes value.
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 output schema exists (not shown), description covers purpose, usage context, and behavioral limitations. For a 1-parameter tool, this is sufficient. Could mention pagination or max dates, but capped list is disclosed.
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?
Only parameter series_id is explained as a FRED series ID with context on its use (revision frequency and bounding). Schema coverage is 0%, so description adds meaning beyond the schema by linking to tool purpose and sibling tools.
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?
Description clearly states the tool retrieves vintage dates (release/revision history) for a FRED series. It distinguishes from siblings like get_series_as_of by explaining bounding behavior, and addresses revision frequency. The verb 'get' and resource 'vintage_dates' are specific.
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?
Description explains that it answers 'how often is this revised?' and bounds vintage tools, giving explicit context for when to use. However, it does not explicitly state when not to use or mention alternatives like get_revision_history, though the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find FRED series by free-text search, best matches first.
`query`: plain words (e.g. "unemployment rate", "median home price").
Returns series IDs with title, units, native frequency, and a
`copyrighted` flag — some FRED series are owned by third parties whose
terms (in the series notes) apply beyond personal use. Resolve a series
ID here first; the data tools key off it.
| 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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds important behavioral context: it returns series IDs with title, units, native frequency, and a copyrighted flag. It also warns that some series are copyrighted by third parties with terms beyond personal use. This is valuable transparency beyond the annotations.
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 appropriately sized: 4 sentences, front-loaded with the purpose. Every sentence adds value: overall function, query example, return fields with copyright warning, and workflow hint. No wasted words.
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 low complexity (2 parameters, output schema exists), the description is complete. It explains the tool's role in the workflow, what is returned, and a special note about copyright. The output schema likely details the return structure, so the description doesn't need to repeat that.
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?
With schema description coverage at 0%, the description must compensate. It explains the query parameter clearly with examples ('plain words (e.g. 'unemployment rate', 'median home price').' The limit parameter is not mentioned but has a default in the schema. While the description adds meaning for the critical parameter, it could briefly note the optional limit parameter.
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 verb (Find) and resource (FRED series) with 'by free-text search, best matches first.' It distinguishes from sibling tools like get_series and get_observations by positioning this as the initial search step: 'Resolve a series ID here first; the data tools key off it.'
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 when to use: before data tools (get_observations, etc.) as it says 'Resolve a series ID here first.' It provides context about the return values and the copyrighted flag. However, it does not explicitly state when not to use this tool or compare to alternatives like compare_series or get_revision_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation on FRED data: search, metadata, observations, latest value, revision history, vintage dates, as-of data, release calendar, and multiple series comparison. No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_observations, search_series). No mixing of conventions or ambiguous verbs.
9 tools cover the essential FRED API operations without being excessive. The count is well-scoped for an agent to effectively interact with economic data.
The set covers the full lifecycle: search and discovery, metadata retrieval, raw data access, revision history, vintage snapshots, release dates, and cross-series comparison. No critical operations are missing for typical use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Equip AI with tools for researching economic data from Federal Reserve Economic Data (FRED).
FRED macro data, Treasury yields, FX rates & macro indicators for AI agents. Pay-per-query via x402.
Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcpwright/fred-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
