fred-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/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: 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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fred-mcp MCP server](https://glama.ai/mcp/servers/mcpwright/fred-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mcpwright/fred-mcp)

Score Badge

Copy to your README.md:

[![fred-mcp MCP server](https://glama.ai/mcp/servers/mcpwright/fred-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mcpwright/fred-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/mcpwright/fred-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server