Click on "Deploy 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., "@cre-fred-mcp Give me a CRE capital markets snapshot."
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.
An MCP server that pulls live Federal Reserve economic data (FRED) — the rates a CRE capital-markets routine runs on: SOFR, Treasury yields, the Fed funds rate, mortgage rates, CPI and PCE. Instead of re-scraping by hand, your MCP client pulls the current numbers on every run.
Not technical? You don't need to be. Hand this repo to Claude and let it do the work:
Open Claude Desktop (or Claude Code).
Give it this repo — paste the URL https://github.com/nik-mirando/cre-fred-mcp
(or this README) and say: "Help me install this MCP server in my Claude Desktop, step by step."
Claude walks you through the three things it needs:
a free FRED API key (~2 minutes, instant, no credit card — see below),
installing the server,
adding it to your Claude config and restarting.
Once it's connected, just ask the questions further down and Claude pulls the live numbers itself.
The one step Claude can't do for you is create the free FRED account — it'll hand you the link and tell you exactly where to paste the key. Everything else it handles.
Related MCP server: FeedOracle Macro MCP
"Give me a CRE capital markets snapshot."
"What's SOFR today, and the 10-year Treasury?"
"What's the current 30-year mortgage rate, and how has it moved this year?"
"What's CPI and PCE inflation right now, year over year?"
"Pull the Fed funds rate and the 2s/10s Treasury spread."
Tool | What it returns |
| One call: SOFR, UST 2/5/10/30yr, Fed funds, 30yr mortgage (latest %), plus CPI & PCE year-over-year % |
| Most recent non-missing observation for any series |
| Time series with date/value (supports |
| Title, units, frequency, last updated |
| Find series by free-text |
| Curated CRE-relevant series ids |
Missing values (FRED's ".", common on daily series over holidays) are
normalised to null, never crash, and are skipped by get_latest_value.
FRED keys are free and issued instantly:
Create / sign in to a FRED account.
Go to https://fredaccount.stlouisfed.org/apikeys and request a key.
Copy the 32-character key.
# from source (this folder)
pip install .
# or run without installing, via uv
uvx --from . cre-fred-mcpSet the key (either export it or drop a .env next to the server):
cp .env.example .env # then paste your key{
"mcpServers": {
"cre-fred": {
"command": "uvx",
"args": ["--from", "/abs/path/to/cre-fred-mcp", "cre-fred-mcp"],
"env": { "FRED_API_KEY": "your_key_here" }
}
}
}(Or "command": "python", "args": ["-m", "cre_fred_mcp"] with the package installed.)
python smoke_test.pyMakes real calls and asserts on real values — e.g. that DGS10 metadata titles
the 10-Year Treasury and that the latest SOFR print is a sane numeric rate.
Data: FRED, Federal Reserve Bank of St. Louis. This is an unofficial client and is not affiliated with or endorsed by the Fed. Series are subject to FRED's terms of use.
Snapshot of key CRE rates in one call: SOFR, UST 2/5/10/30yr, Fed funds, 30yr mortgage (latest %), plus CPI and PCE (latest year-over-year %).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It lists the data returned but does not disclose operational traits like read-only behavior, authentication needs, or rate limits. The description is moderately transparent.
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 a single, well-structured sentence that efficiently lists the included data points. No extraneous 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 absence of parameters and output schema, the description is fairly complete. It specifies all the rates returned, though it omits details on output format or update frequency, which are less critical for a snapshot 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?
There are no parameters, and the schema is empty with 100% coverage. Per the guidelines, zero parameters warrant a baseline of 4. The description does not need to add parameter information.
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 that the tool returns a snapshot of key CRE rates, listing specific rates (SOFR, UST yields, Fed funds, mortgage, CPI, PCE). This distinguishes it from sibling tools which retrieve individual series or metadata.
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 (for multiple rates in one call) but does not provide explicit guidance on when not to use or mention alternatives. For example, if only one rate is needed, another tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most recent non-missing observation for a FRED series.
series_id: FRED series id, e.g. 'SOFR', 'DGS10', 'MORTGAGE30US', 'FEDFUNDS'. Returns {series_id, date (YYYY-MM-DD), value}. Missing/holiday values are skipped so you always get a real number.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral traits: it skips missing/holiday values and always returns a real number. It also specifies the return format (series_id, date, value). However, it does not mention rate limits or error conditions.
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 three sentences: purpose, parameter explanation with examples, and return/behavior. Every sentence adds value, and the most important 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?
For a simple tool with one parameter and no output schema, the description covers purpose, parameter, return format, and behavioral nuance (skipping missing values). It lacks error handling or usage context but is complete enough for typical use.
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 adds significant meaning to the series_id parameter by providing examples (e.g., 'SOFR', 'DGS10') and stating it is a FRED series id. This compensates for the schema's lack of description.
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 'Most recent non-missing observation for a FRED series,' which is a specific verb-resource combination. It effectively distinguishes from sibling tools like get_series_observations (historical data) and search_series (search).
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 for obtaining the latest observation but does not explicitly specify when to use this tool versus alternatives, nor does it provide when-not scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadata for a FRED series: title, units, frequency, last_updated, notes.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet the description does not disclose behavioral traits like read-only nature, authentication requirements, or error cases. Only output fields are mentioned.
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 short but omits critical details. While efficient, it sacrifices clarity and completeness.
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 one parameter and no output schema, the description is incomplete. It doesn't explain parameter input or output structure beyond listing fields, leaving gaps for an agent.
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%. The description does not explain the series_id parameter (e.g., format or example), leaving the agent without additional meaning beyond the 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 it returns metadata (title, units, frequency, last_updated, notes) for a FRED series. It distinguishes from siblings like get_latest_value or get_series_observations, which focus on actual data values.
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?
No guidance on when to use this tool versus alternatives such as search_series or get_series_observations. Lack of context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time series of observations for a FRED series.
Dates are 'YYYY-MM-DD'. frequency aggregates coarser (d,w,m,q,a). units can transform values (e.g. 'pc1' = % change from a year ago, 'pch' = % change). Each row is {date, value (float or null when missing), raw_value}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| units | No | ||
| frequency | No | ||
| series_id | Yes | ||
| sort_order | No | asc | |
| observation_end | No | ||
| observation_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output format, date format, frequency aggregation, and units transformations. No annotation support, but covers key behavioral aspects without 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?
Three concise sentences with front-loaded purpose; every sentence adds value without redundancy.
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?
Explains output and two parameters, but lacks details on limit, sort_order, date ranges, pagination, or error handling. Adequate for a basic tool but incomplete given 7 parameters and no output schema.
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 frequency and units (e.g., 'd,w,m,q,a' and transformation examples), but leaves limit, sort_order, and date range parameters unexplained. Schema has 0% 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?
Description clearly states the tool retrieves time series observations for a FRED series, distinguishing it from siblings like metadata or single-value tools.
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?
Implies use for full time series data and provides parameter hints, but lacks explicit when-to-use vs. alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated CRE-relevant FRED series ids this server knows about (id -> label).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries responsibility for transparency. It states the output is an id-to-label mapping but omits details on curation, staleness, or side effects. Acceptable for a simple read-only 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?
Single sentence, no wasted words. Clearly communicates purpose and output format.
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 no parameters and no output schema, the description sufficiently informs an agent about the tool's purpose and output. Could mention the return format more explicitly, but adequate for this simple 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?
No parameters exist, so the description adds nothing beyond the schema. Baseline for 0 parameters is 4, and the description correctly indicates no inputs needed.
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 lists curated CRE-relevant FRED series IDs with labels, using a specific verb and resource. It distinguishes from sibling tools that focus on data retrieval or search.
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?
No explicit guidance on when to use this tool vs alternatives. The description implies its purpose but lacks context for when not to use it or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search FRED for series. Returns id/title/units/frequency/popularity.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It implies read-only search but does not mention rate limits, pagination, error cases, or ordering. The return fields are listed but no details on result structure.
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 short and front-loaded, but it omits necessary details. Efficient use of words, but at the cost of clarity.
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 absence of annotations, output schema, and low parameter coverage, the description is incomplete. It does not explain full-text search behavior, pagination, or result ordering.
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%, and the description adds no meaning to the parameters 'query' or 'limit'. The agent must infer their purpose solely from names, which is insufficient.
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 'Full-text search' and the resource 'FRED for series', and lists the return fields, making it distinct from sibling tools that retrieve specific series data.
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?
No guidance on when to use this tool versus alternatives like get_series_metadata or search alternatives. The description lacks context for selecting this 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.
v0.1.0get_capital_markets_snapshotget_latest_valueget_series_metadataget_series_observationslist_common_seriessearch_seriesScored across 6 tools
Tools have distinct purposes: snapshot bundles multiple rates, get_latest_value retrieves a single latest observation, get_series_metadata provides metadata, get_series_observations returns time series, list_common_series offers a curated list, and search_series performs full-text search. Some overlap exists between get_latest_value and get_series_observations, but descriptions clarify their distinct use cases.
Tool names follow a mostly consistent verb_noun pattern: three use 'get_', one 'list_', one 'search_'. The naming is readable and clear, though 'get_capital_markets_snapshot' is a bit verbose compared to others. No mixing of camelCase or snake_case, but the verb prefix varies slightly.
With 6 tools, the server is well-scoped for its purpose of providing CRE-relevant FRED data. Each tool serves a specific need without being excessive or insufficient. The count is appropriate for a focused domain-specific server.
The tool set covers key operations: retrieving data (latest, time series, snapshot), exploring available series (curated list, search), and obtaining metadata. A minor gap might be the lack of a tool to directly compare multiple series side-by-side, but the snapshot and get_series_observations largely cover this.
Fetch US Bureau of Labor Statistics data — CPI, unemployment, wages, JOLTS, and more via MCP.
GDP, unemployment, CPI, interest rates, and 800K+ economic time series from the Federal Reserve
Unlock the power of real-time financial data with our Finance MCP. Easily retrieve the latest
FRED macro data, Treasury yields, FX rates & macro indicators for AI agents. Pay-per-query via x402.