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-economic-intelligence-mcp What is the current 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 open-source, MCP-native economic intelligence server built on the Federal Reserve Economic Data API. The project combines deterministic FRED tools with a curated economic knowledge graph, graph-enhanced retrieval, explainability, an Economic Digital Twin, scenario simulation, and a LangGraph-compatible multi-agent workflow.
FRED series search, metadata, observations, comparison, snapshots, and calendar-aware growth calculations
MCP tools for economic graph queries and evidence retrieval
Curated macroeconomic knowledge graph with transparent edges and confidence metadata
Lightweight GraphRAG using graph traversal plus local evidence retrieval
Economic Digital Twin with growth, inflation, labor, policy, housing, and financial-condition states
Directional scenario simulation with propagation traces and explicit limitations
Explainability through data provenance, domain attribution, graph paths, and citations
Supervisor-led multi-agent workflow compatible with LangGraph
Deterministic fallback mode that does not require an LLM API key
Related MCP server: mcp-fred
This is a research-grade decision-support project. The digital twin and scenario engine are transparent directional models, not validated causal macroeconomic forecasts or investment advice.
uv syncCreate a .env file locally:
FRED_API_KEY=your_fred_api_keyNever commit the .env file.
uv run python -m fred_economic_intelligence_mcp.serverOr:
uv run fred-economic-intelligence-mcphealth_check
search_series
get_series_metadata
get_series_observations
compare_series
latest_snapshot
calculate_growth_rate
query_economic_graph
retrieve_economic_evidence
build_economic_digital_twin
simulate_economic_scenario
explain_economic_signal
run_agent_workflow
Digital-twin inputs use values from -1.0 to 1.0:
positive: indicator increased or strengthened
negative: indicator decreased or weakened
zero: neutral or unavailable
The twin applies indicator-specific interpretation. For example, increases in unemployment or initial claims contribute negatively to labor-market strength.
Example:
{
"CPIAUCSL": 0.25,
"UNRATE": 0.40,
"PAYEMS": -0.10,
"HOUST": -0.30,
"T10Y2Y": -0.50
}Supported MVP shocks:
policy_rate_change
unemployment_change
inflation_change
Example:
{
"policy_rate_change": -0.5
}uv run pytest -v --cov=fred_economic_intelligence_mcp --cov-report=term-missingBefore publishing, ensure .env, .venv, .coverage, caches, and Git internals are excluded from the archive and repository.
Build an explainable economic-state digital twin from normalized signals.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes | ||
| as_of_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It fails to mention important aspects such as statefulness, side effects, cost, rate limits, or any requirements (e.g., prior setup). The term 'explainable' hints at output nature but is insufficient.
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, concise sentence that front-loads the key action. However, it may sacrifice clarity for brevity, leaving important gaps in parameter and behavior details.
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 with two parameters (one nested object) and an output schema, the description is insufficient. It does not clarify what 'normalized signals' entails, how 'as_of_date' affects the result, or provide any context about the output. The existence of an output schema partially mitigates the need for return value explanation, but overall the description lacks completeness.
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 has 0% description coverage, so the description must compensate. It only hints at the 'signals' parameter via 'from normalized signals' but provides no detail on format, meaning, or the optional 'as_of_date' parameter. The description adds minimal value 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 the tool's purpose: building an explainable economic-state digital twin from normalized signals. The verb 'build' and resource 'economic-state digital twin' are specific. The description effectively distinguishes this tool from siblings like 'simulate_economic_scenario' and 'explain_economic_signal'.
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 constructing digital twins from signals but does not provide explicit when-to-use or when-not-to-use guidance. No mention of prerequisites or alternatives among siblings, leaving the agent to infer context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate absolute and percentage change for a FRED series.
The comparison observation is selected by calendar date rather
than only by list position, which avoids off-by-one errors when
observations contain missing values.
Examples:
CPIAUCSL with periods=12 for year-over-year change.
GDP with periods=1 for quarter-over-quarter change.
UNRATE with periods=1 for month-over-month change.
| Name | Required | Description | Default |
|---|---|---|---|
| periods | No | ||
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the key behavioral trait: selecting comparison by calendar date rather than list position, which prevents off-by-one errors with missing values. This is a valuable behavioral detail.
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: three sentences and a list of examples. Every sentence adds value, and the examples are clearly formatted. 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 complexity (growth rate calculation with date-based comparison) and the existence of an output schema, the description covers the main behavioral aspects and usage. Could be more explicit about the output format, but the output schema handles 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?
Schema description coverage is 0%, so description must add meaning. It does not describe parameters individually, but the examples clarify that 'periods' controls the lag (e.g., periods=12 for year-over-year). This partially compensates for lack of schema descriptions.
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 calculates absolute and percentage change for a FRED series, with examples showing usage. It distinguishes from sibling tools like 'compare_series' and 'get_series_observations' by focusing on growth rates.
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 explains the date-based comparison method to avoid off-by-one errors, and provides examples for common use cases (year-over-year, quarter-over-quarter). It does not explicitly state when not to use, but the examples imply appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve and compare multiple FRED economic series.
This tool fetches metadata and observations for each requested
series concurrently.
Example series IDs:
["GDP", "UNRATE", "CPIAUCSL", "FEDFUNDS"]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| series_ids | Yes | ||
| observation_end | No | ||
| observation_start | 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 full burden. It discloses concurrent fetching, which is a behavioral trait beyond the schema. However, it lacks details on rate limits, authentication needs, error handling, or idempotency. This is adequate but not rich for a tool with no 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 highly concise with three sentences: first states purpose, second adds concurrency detail, third provides example. It is front-loaded and efficient, 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 has 4 parameters and an output schema exists, the description does not need to cover return values. However, it partially explains the 'series_ids' parameter via example but omits others. The core purpose is clear, but param details are inadequate, making it average in completeness.
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 provides example series IDs, giving context for the 'series_ids' parameter, but does not explain 'limit', 'observation_start', or 'observation_end'. The example helps but leaves most parameters undefined, which is insufficient given the lack of schema descriptions.
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 retrieves and compares multiple FRED economic series, specifying the verb ('Retrieve and compare') and resource ('multiple FRED economic series'). It also mentions concurrent fetching of metadata and observations, which differentiates it from sibling tools like get_series_metadata and get_series_observations that likely handle single series.
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 this tool is for comparing multiple series by fetching metadata and observations concurrently. While it does not explicitly state when not to use it or mention alternatives, the sibling context (e.g., get_series_metadata, get_series_observations) provides differentiation. A clearer exclusion or alternative mention would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain domain scores, series contributions, uncertainty, and methodology.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether the tool fetches data, is read-only, or has side effects. It only describes what is explained, not how the tool behaves.
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 sentence, which is concise, but it is under-specified and fails to provide necessary information. It does not effectively communicate the tool's purpose or usage.
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?
Despite having an output schema, the description lacks context for usage and parameter handling. With no annotations and 0% schema coverage, the description is incomplete for a tool with a complex parameter.
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 does not explain the required 'signals' parameter. The parameter is an object with additional properties, but no guidance on its structure or usage is provided.
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 it explains domain scores, series contributions, uncertainty, and methodology, but it is vague and does not specify what kind of output or action is performed. It lacks differentiation from sibling tools like compare_series or get_series_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?
No guidance on when to use this tool versus alternatives. No prerequisites, context, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata for a FRED economic series.
Examples of series IDs:
GDP, CPIAUCSL, UNRATE, FEDFUNDS.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It only says 'metadata' without specifying what fields are returned (e.g., title, frequency, units) or any side effects, authentication needs, or rate limits.
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?
One concise sentence plus a list of examples. No superfluous words; every element serves a 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?
Though the tool is simple and an output schema exists, the description does not clarify what 'metadata' includes. For an agent, more context on the returned structure would be helpful.
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 one parameter 'series_id' with 0% schema description coverage, so description must compensate. The examples of series IDs add semantic context but lack format constraints or allowed values, so baseline 3 is appropriate.
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 'Retrieve metadata for a FRED economic series' with specific verb and resource. Examples of series IDs like GDP and UNRATE help distinguish from sibling tools such as get_series_observations or search_series.
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 retrieving metadata but provides no explicit when-to-use or when-not-to-use guidance, nor references to alternative tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve observations for a FRED economic series.
Examples of series IDs:
GDP, CPIAUCSL, UNRATE, FEDFUNDS.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| series_id | Yes | ||
| observation_end | No | ||
| observation_start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose behavioral traits such as read-only nature, rate limits, or parameter constraints. Only states retrieval without any side-effect or permission detail.
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 short (one sentence plus example list), but it sacrifices necessary detail for conciseness. It is not structured to highlight key 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 4 parameters, an output schema, and no annotations, the description lacks details about input semantics, return format, and behavioral context. The examples are useful but insufficient.
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 any parameter. It only gives example series IDs but does not explain 'limit', 'observation_start', 'observation_end', or their format.
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 'Retrieve observations for a FRED economic series', which is a specific verb and resource. Examples of series IDs further clarify. Distinguishes from siblings like 'search_series' and 'get_series_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?
No explicit guidance on when to use this tool versus alternatives. No prerequisites or context provided. Agent is left to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the FRED MCP server is running.
| 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, and the description only mentions the purpose without detailing return values or error conditions. However, an output schema exists, reducing the burden.
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 concise sentence that is front-loaded and contains no superfluous 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?
For a simple health check with no parameters and an output schema, the description is complete and adequate for an agent to understand its purpose.
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, so the description adds no parametric detail. With zero parameters, the baseline 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 action (check) and the resource (FRED MCP server), distinguishing it from sibling tools that retrieve economic 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?
The description implies usage for verifying server availability but does not explicitly state when or when not to use it, nor does it mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the latest valid observation for multiple FRED series.
| Name | Required | Description | Default |
|---|---|---|---|
| series_ids | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'valid' observation but does not define what constitutes valid (e.g., non-null, latest by date). No mention of error handling, rate limits, or data source freshness.
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, clear sentence with no extraneous content. It is front-loaded and efficient.
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?
Despite the presence of an output schema, the description lacks crucial context: usage guidelines, parameter details, and behavioral transparency. For a tool with one parameter and no annotations, the description is too minimal to be considered complete.
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 adds no meaning beyond the schema; it simply says 'multiple FRED series' without explaining input format, limits, or behavior for invalid series IDs. The schema already defines the parameter, so the description adds no value.
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 purpose: returning the latest valid observation for multiple FRED series. It uses a specific verb and resource, and distinguishes from siblings like 'get_series_observations' which likely returns 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?
No guidance is provided on when to use this tool versus alternatives such as 'get_series_observations' or 'compare_series'. The description does not mention conditions for use or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the curated macroeconomic knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_depth | 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 bears full burden for behavioral disclosure. It only states 'query the graph' without revealing any traits (e.g., read-only, rate limits, pagination, or what the output represents). The existence of an output schema helps but the description adds no behavioral context.
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 sentence, which is concise but severely underspecified. The brevity comes at the cost of completeness; it does not earn its place because it provides almost no actionable information beyond the tool name.
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 moderate complexity (2 parameters, many siblings, and an output schema), the description is extremely inadequate. It fails to explain what the knowledge graph contains, how to craft queries, or what the response looks like, leaving the agent with minimal guidance for correct invocation.
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%, meaning no parameter descriptions exist, and the tool description adds no meaning to the two parameters. It does not explain what format the 'query' string should take or what 'max_depth' controls, leaving the agent without essential usage details.
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 action 'query' and the resource 'curated macroeconomic knowledge graph', which is clear in a general sense. However, it does not specify the scope of queries or differentiate from sibling tools like search_series or get_series_metadata, making it somewhat vague.
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 no guidance on when to use this tool versus alternatives. There is no mention of what types of queries are appropriate or when the tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the supervisor-led multi-agent economic intelligence workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| shocks | No | ||
| signals | No | ||
| question | Yes |
| 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 full burden. It only states 'run... workflow' without disclosing whether it is long-running, mutates data, requires authentication, or has side effects. Critical behavioral traits are missing.
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 sentence with no redundancy, but it sacrifices crucial information for brevity. It is concise but not appropriately sized given the tool's complexity.
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?
Despite having an output schema, the description lacks parameter guidance, usage context, and behavioral notes. For a tool with three parameters (one required) and no annotations, the description is insufficient for correct invocation.
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 information about the three parameters (question, shocks, signals). The AI agent cannot infer roles or constraints from the description alone.
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 runs a 'supervisor-led multi-agent economic intelligence workflow', specifying the verb and resource. It distinguishes from sibling tools (e.g., compare_series, simulate_economic_scenario) by characterizing it as a multi-agent workflow rather than a single function.
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. The description does not contextualize that this is an aggregator workflow that might replace multiple sibling calls, nor does it specify prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FRED for economic data series using keywords.
Examples:
unemployment rate, inflation, consumer price index,
mortgage rates, housing starts, retail sales.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search_text | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It does not mention that the tool is read-only, rate limits, or what the response contains. The examples imply a search but lack detail on output 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 very short and front-loaded, but lacks sufficient detail. The examples are helpful but do not compensate for missing parameter 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 tool has two parameters, no annotations, and an output schema not described, the description is incomplete. The agent lacks key information 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 coverage is 0%. The description does not mention the 'search_text' or 'limit' parameters, nor how to use them effectively. No guidance on query syntax or defaults 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 the tool searches for economic data series using keywords, and provides relevant examples. It distinguishes this tool from sibling tools like get_series_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?
No explicit guidance on when to use this tool versus alternatives (e.g., get_series_metadata for known series IDs). No mentions of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propagate transparent directional shocks through the economic digital twin.
| Name | Required | Description | Default |
|---|---|---|---|
| shocks | Yes | ||
| signals | 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 carries full burden. It mentions propagation of shocks but does not disclose whether this is read-only or modifies state, or any side effects, rate limits, or permissions needed. The term 'propagate' could imply mutation, but this is not clarified.
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 sentence (17 words), which is concise. However, it lacks essential details that would justify its brevity; it is under-specified rather than efficiently informative.
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 2 required parameters with nested objects and an output schema, the description is incomplete. It does not clarify how shocks are applied, what 'directional' means, or what the output represents. The existence of an output schema partially compensates, but the description still fails to provide sufficient 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?
Schema description coverage is 0% for the 2 parameters ('shocks' and 'signals'), both being objects with number values. The description adds no explanation of their meaning, expected structure, or relationship. With no annotations, this is a significant 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 uses specific verb 'Propagate' and resource 'economic digital twin', indicating simulation of shocks. It is distinguishable from sibling tools like 'compare_series' or 'query_economic_graph', but the phrase 'transparent directional shocks' is somewhat jargon-heavy and could be clearer.
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 'explain_economic_signal' or 'run_agent_workflow'. The description does not specify prerequisites, typical use cases, or exclusions.
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. Dates show when Glama detected each change.
v0.1.0build_economic_digital_twincalculate_growth_ratecompare_seriesexplain_economic_signalget_series_metadataget_series_observationshealth_checklatest_snapshotquery_economic_graphrun_agent_workflowsearch_seriessimulate_economic_scenarioMost tools have clearly distinct purposes, but there is slight potential for confusion between advanced tools like 'simulate_economic_scenario' and 'build_economic_digital_twin' or 'explain_economic_signal' and 'query_economic_graph'. Overall, an agent can differentiate them with careful description reading.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., 'search_series', 'get_series_observations', 'simulate_economic_scenario'. This makes the set predictable and easy to navigate.
With 12 tools, the server is well-scoped. It covers data retrieval, analysis, and advanced simulation without being overwhelming. Each tool contributes meaningfully to the economic intelligence domain.
The tool set is comprehensive for a FRED-based economic intelligence server. It includes search, metadata, observations, multiple series operations, growth rates, and advanced features like digital twin, scenario simulation, and agent workflows. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/prithvi1029/fred-economic-intelligence-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
