Provides an MCP server that gives AI assistants clean access to US macroeconomic data from FRED, with tools to query indicators, historical series, comparisons, release schedules, snapshots, recession signals, and keyword search.
list_indicators – See all 58 indicators, optionally filtered by category (inflation, employment, growth, housing, consumer, rates, stress, markets, fiscal).
get_indicator – Get the latest reading of one indicator with previous value, year-ago value, and percentage changes already calculated.
get_history – Fetch a full time series for an indicator, with optional date range and limit.
compare_indicators – Compare two or more indicators over the same period (1y, 2y, 5y, 10y), normalised for comparison.
release_calendar – See upcoming US economic data releases over the next days (up to 90).
macro_snapshot – Get a single-call snapshot of the whole economy or one category, covering 19 headline indicators at once.
recession_signals – Check Sahm rule, yield curve, credit spreads, jobless claims, and financial conditions, each with a plain-English status.
search_indicators – Find indicators by keyword when you don't know the exact name.
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., "@us-macro-mcp What's the latest unemployment rate?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants clean access to US macroeconomic data — 58 indicators covering inflation, employment, growth, housing, consumer behaviour, interest rates, financial stress, markets and federal finances, sourced from the Federal Reserve's FRED database.
It is built so the assistant never has to know a FRED series ID, and never has to do arithmetic. Ask for cpi and you get the latest reading, the previous one, the year-ago value, and the percentage changes already calculated.
Registry Official Link : https://pypi.org/project/us-macro-mcp/
Date | Version | Comment |
2026-07-27 | 0.1.2 | Added OS and Python version classifiers, changelog, and contact address switched to GitHub noreply. |
2026-07-27 | 0.1.1 | Added |
2026-07-27 | 0.1.0 | Initial release — 58 indicators, 8 tools. Yanked; superseded by 0.1.1. |
Related MCP server: FRED Economic MCP Server
Tool | What you use it for |
| See every indicator available, grouped by category |
| The current reading of one indicator, with its changes |
| A full time series, for trends and charting |
| Two or more indicators over the same window, normalised for comparison |
| Which economic reports are scheduled over the coming days |
| The whole economy — or one category — in a single call |
| The Sahm rule, yield curve, credit spreads, claims and financial conditions, each graded |
| Find an indicator by keyword when you don't know its name |
A free FRED API key. Request one at fredaccount.stlouisfed.org/apikeys — it takes about a minute and costs nothing.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"us-macro": {
"command": "uvx",
"args": ["us-macro-mcp"],
"env": { "FRED_API_KEY": "your_key_here" }
}
}
}claude mcp add us-macro --env FRED_API_KEY=your_key_here -- uvx us-macro-mcpRun uvx us-macro-mcp with FRED_API_KEY set in the environment. The server speaks MCP over stdio.
It runs locally. Nothing is hosted. Your client launches the server as a subprocess on your own machine, using your own API key. No data leaves your computer except the read-only requests to FRED.
It caches. A single macro_snapshot fetches 19 indicators at once, and conversations tend to ask for the same series repeatedly. Answers are held in memory for a period matched to how often the number can actually change — an hour for daily series like Treasury yields, half a day for monthly series like CPI. The cache is discarded when the process exits. Adjust CACHE_SECONDS in fred.py if you want different behaviour.
It never logs your API key. Requests are logged as endpoint, series and status code only, and any error text is stripped of the key before it is written or returned.
The ISM Manufacturing and Services PMI are not available. ISM licenses its data commercially and withdrew it from FRED. The same applies to the Conference Board Consumer Confidence Index. There is no free source for either.
Rates are national averages, not per-bank. The 30-year mortgage rate is Freddie Mac's weekly survey across thousands of lenders — not any particular bank's advertised rate. Per-institution rates are not published free by anyone.
FOMC meeting dates are not included. FRED publishes data release schedules, not the Federal Reserve's meeting calendar.
Michigan consumer sentiment lags. As of this writing FRED's UMCSENT and MICH series are running about two months behind other monthly indicators. The latest_date field always tells you what you actually got.
Data is reported for the period it covers. June CPI is dated 2026-06-01 and publishes in mid-July. Always read latest_date rather than assuming the most recent month exists yet.
All data comes from FRED, maintained by the Federal Reserve Bank of St. Louis, which aggregates it from the Bureau of Labor Statistics, the Bureau of Economic Analysis, the Census Bureau, the Federal Reserve Board and others.
The recession_signals tool applies well-known statistical thresholds to public data. It is not a forecast, and nothing this server returns is investment advice.
The Federal Reserve publishes its meeting schedule about two years ahead, and Python, the MCP SDK and FRED's own catalog all drift over a year. Work through this list every January and cut a new release.
Data
Refresh the FOMC schedule in src/us_macro_mcp/fomc.py from
federalreserve.gov/monetarypolicy/fomccalendars.htm,
and move VALID_THROUGH forward. The next_fomc_meeting field goes empty once the list runs out.
Re-validate every series ID in the catalog. FRED retires series without warning — the ADP employment series was discontinued this way, returning a valid response with zero observations: cd ~/Downloads/Apps/US-Macro-MCP && uv run python -c " import asyncio, logging logging.getLogger('us_macro_mcp').setLevel(logging.WARNING) from us_macro_mcp import catalog, fred async def main(): sem = asyncio.Semaphore(8) async def check(i): async with sem: try: p = await fred.get_observations(i.series_id, start='2025-01-01', frequency_hint=i.frequency) return (i.name, 'OK' if p else 'EMPTY', p[-1]['date'] if p else '-') except Exception as e: return (i.name, 'FAIL: ' + str(e)[:70], '-') rows = await asyncio.gather(*(check(i) for i in catalog.CATALOG)) print('problems:', [r for r in rows if r[1] != 'OK']) asyncio.run(main()) "
Check whether anything previously unavailable has become free — particularly the ISM PMI and the Conference Board Consumer Confidence Index, both currently absent from FRED.
Check FRED's API terms and rate limit (currently 120 requests per minute per key) for changes.
Dependencies
Bump the mcp SDK and read its changelog for breaking changes. FastMCP is part of the official
SDK, so a major version there can change how tools are declared or how the server starts.
Check whether the MCP specification has revised its transports or tool schema.
Bump httpx.
Review requires-python. Drop versions that have reached end of life, and confirm the current
floor still installs cleanly.
Release
Run the full test sweep: all eight tools, plus the negative and boundary cases.
Bump the version in pyproject.toml and in server.json. They must match or the registry
rejects the publish.
uv build and uv publish to PyPI.
mcp-publisher publish to the official MCP registry.
Tag the release on GitHub.
MIT
Compare two or more indicators over the same period, for questions like "did wage growth beat inflation" or "how do the 2-year and 10-year yields compare".
Args: names: Two or more friendly indicator names, for example ["cpi", "avg_hourly_earnings"]. period: How far back to look - "1y", "2y", "5y" or "10y". Defaults to "1y".
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | ||
| period | No | 1y |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals the tool's purpose, parameters, and default behavior. It does not explicitly state that the tool is read-only or describe side effects, but the nature of comparison implies no destructive actions. Additional detail on return format could be added.
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, front-loaded with the core purpose, and uses a clear docstring format for parameters. 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?
Given the tool's moderate complexity, the presence of an output schema, and no annotations, the description covers all necessary aspects: what it does, parameters with examples, and default behavior. It is complete for effective 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?
The description adds significant meaning beyond the schema: it explains 'names' are friendly indicator names with examples, and 'period' includes allowed values ('1y', '2y', '5y', '10y') and default. Since schema coverage is 0%, this is essential and well-done.
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 compares two or more indicators over the same period, with concrete examples like 'did wage growth beat inflation'. It distinguishes from sibling tools such as 'list_indicators' or 'get_indicator' by focusing on comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('for questions like...'), implying comparative analysis. It does not explicitly state when not to use or list alternatives, but the examples and scope give sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the historical time series for one indicator.
Args: name: Friendly indicator name, for example "cpi" or "sp500". start: Optional first date as YYYY-MM-DD. Defaults to about two years ago. end: Optional last date as YYYY-MM-DD. Defaults to today. limit: Maximum number of data points to return, most recent kept. Defaults to 500.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| name | Yes | ||
| limit | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses parameter defaults and 'most recent kept' for limit. Lacks details on error handling (invalid name, date range) and rate limits. Adequate but not exhaustive.
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 structured with an Args section, concise without redundant words. Could be slightly more concise but is well-organized and front-loaded with purpose.
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 annotations and presence of output schema, description sufficiently explains input parameters and their behavior (defaults, format). Lacks output description but output schema is available. Adequately complete for basic 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 description coverage is 0%, so description must add meaning. It does so comprehensively: explains 'name' as friendly indicator name, date formats as YYYY-MM-DD, limit behavior, and defaults. Adds significant value beyond 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?
Description clearly states 'Get the historical time series for one indicator' with a specific verb and resource. Distinguishes from siblings like list_indicators (listing) and compare_indicators (comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use the tool for time series data. Does not provide explicit when-not-to-use or alternative tool references, but the sibling context aids inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest value of one economic indicator, with its recent changes already calculated.
Args: name: A friendly indicator name such as "cpi", "unemployment_rate", "jobless_claims" or "mortgage_30y". Use list_indicators to see all names.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation (gets latest value) and mentions recent changes. No annotations are present, so the description carries the full burden; it is clear but lacks details on rate limits or permissions.
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 (two sentences plus parameter detail) and front-loaded with the purpose, with no unnecessary 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 tool's simplicity, one parameter, and the presence of an output schema, the description adequately covers the tool's functionality and context.
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?
Despite 0% schema description coverage, the description fully explains the 'name' parameter with examples and a reference to list_indicators, adding significant meaning beyond the schema's minimal title.
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 gets the latest value of one economic indicator with recent changes, differentiating it from siblings like get_history (historical data) and compare_indicators (comparison).
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 mentions using list_indicators to see all names, providing a prerequisite. However, it does not explicitly compare when to use this tool vs other similar tools like get_history or compare_indicators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every US economic indicator this server provides.
Call this first to discover valid indicator names before using the other tools.
Args: category: Optional filter. One of: inflation, employment, growth, housing, consumer, rates, stress, markets, fiscal. Omit to list all indicators.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states it lists indicators but does not mention idempotency, side effects, or response structure. However, an output schema exists, so return details are not required. Minimal but adequate for a simple read operation.
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?
Very concise: two sentences and one line for args. The first sentence states purpose, the second gives usage guidance, and the parameter is explained clearly. No redundant 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 simple tool (one optional param, no required) and presence of output schema, the description is nearly complete. It explains purpose, usage order, and parameter options. Could mention that listing is all indicators without pagination, but not necessary.
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 compensates by explaining the 'category' parameter and listing valid values: inflation, employment, etc. This adds significant meaning beyond the schema which only defines type 'string or null'.
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?
Clearly states 'List every US economic indicator this server provides.' Identifies the specific verb (list) and resource (indicators). Differentiates from sibling tools by advising to call this first before using other tools like get_indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Call this first to discover valid indicator names before using the other tools.' Provides guidance on when to use (before others) and optional filtering with category values. No explicit when-not-to-use, but strong usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a current snapshot of the US economy in one call - the latest value and recent change for every headline indicator.
Args: category: "all" for the headline indicators across every category, or one of inflation, employment, growth, housing, consumer, rates, stress, markets, fiscal to get every indicator in that category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | all |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses that it returns latest value and recent change, but does not define 'recent change' (time frame), data sources, or update frequency. Some ambiguity remains.
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?
Concise single-sentence purpose followed by clear Args section. Efficient and well-structured, though 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?
Output schema exists, so return values need not be described. Covers purpose and parameter adequately. Lacks clarification on 'recent change' but sufficient 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?
Input schema has 0% description coverage, but the description explains the single parameter 'category', listing valid values like 'all', inflation, employment, etc. Adds 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?
Clearly states it gets a current snapshot of the US economy with latest value and recent change for every headline indicator. Distinguishes from sibling tools that focus on specific indicators or historical 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?
Implies usage for broad economic overview, but does not explicitly state when not to use or mention alternatives. However, sibling tool names provide context for tool separation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the main US recession warning signals at once - the Sahm rule, the yield curve, credit spreads, jobless claims and financial conditions - each with a plain-English status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output (plain-English status for each signal) but does not mention rate limits, auth needs, data sources, or update frequency. For a read-only tool with no parameters, this is adequate but could be improved.
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 superfluous content. Efficiently communicates purpose and included indicators.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is sufficiently complete. It lists the signals covered, which aligns with the expected output.
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 zero parameters, so schema coverage is 100%. The description adds value by enumerating the specific signals checked, which is more meaningful than the empty schema. Baseline for 0 params is 4.
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 checks main US recession warning signals, lists specific indicators (Sahm rule, yield curve, etc.), and notes each has a plain-English status. This distinguishes it from siblings like list_indicators or macro_snapshot.
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 a quick overview of multiple recession signals but does not explicitly state when to use or not use this tool, nor does it mention alternatives among the 7 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which US economic data releases are scheduled over the coming days, for questions like "what economic data comes out this week".
Args: days_ahead: How many days forward to look. Defaults to 14, maximum 90.
| Name | Required | Description | Default |
|---|---|---|---|
| days_ahead | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool shows scheduled releases but does not explicitly disclose that it is read-only, nor does it mention any limitations or side effects. The default and max for days_ahead are noted, but more transparency (e.g., 'this is a read-only operation') would improve the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and parameter documentation. It front-loads the purpose and example, with 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 tool's simplicity (1 optional parameter, no required inputs, output schema exists), the description provides all necessary context. It covers the tool's purpose, the parameter, and provides an example query, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It fully explains the 'days_ahead' parameter with purpose ('How many days forward to look'), default (14), and maximum (90), adding significant meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Show', 'scheduled') and clearly identifies the resource ('US economic data releases') and scope ('over the coming days'). The example query distinguishes it from sibling tools like list_indicators (list all indicators) and get_indicator (specific details).
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 states the use case with an example question, implying when to use this tool. It does not explicitly state when not to use it, but the sibling tools provide clear alternatives, making the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find indicators by keyword when you do not know the exact name - for example "gas prices", "wages", "mortgage" or "recession".
Args: query: Free-text words to search for across indicator names, titles and descriptions. limit: Maximum number of matches to return. Defaults to 10.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains that the search covers indicator names, titles, and descriptions, but does not mention any additional behavioral traits such as pagination, ordering, or whether it's read-only. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 4 lines, with a clear front-loaded purpose and parameter explanations. 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?
Given the tool has only 2 parameters and an output schema exists, the description is complete enough. It explains the search behavior and parameters; no need to detail return values. It could mention ordering or pagination but is still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must add meaning. It describes 'query' as free-text words across specific fields and 'limit' as max matches with a default of 10. This adds sufficient context beyond the bare schema titles.
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 finds indicators by keyword and explicitly says it's for when you don't know the exact name, giving concrete examples like 'gas prices', 'wages'. This distinguishes it from sibling tools like list_indicators and get_indicator.
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 says 'when you do not know the exact name', providing clear context for when to use this tool over others. However, it does not explicitly name alternatives or state when not to use it.
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.2compare_indicatorsget_historyget_indicatorlist_indicatorsmacro_snapshotrecession_signalsrelease_calendarsearch_indicatorsScored across 8 tools
Each tool has a distinct purpose: listing, current value, history, comparison, calendar, snapshot, recession signals, and search. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., list_indicators, get_history, compare_indicators.
8 tools is ideal for the US macroeconomics domain, covering discovery, retrieval, comparison, and specialized checks without excess.
The set covers all key operations: discovery, single value, history, multi-indicator comparison, future releases, full snapshot, recession signals, and search. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
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.
