GDP, unemployment, CPI, interest rates, and 800K+ economic time series from the Federal Reserve
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose with no overlap: get_category_series browses series by category, get_release_dates tracks publication dates, get_series_info provides metadata, get_series_observations retrieves data points, and search_series finds series by keyword. The descriptions reinforce these unique roles, eliminating any ambiguity.
All tools follow a consistent verb_noun pattern with 'get_' or 'search_' prefixes and descriptive nouns (e.g., get_category_series, search_series). The naming is uniform and predictable, making it easy for agents to understand the action and target resource.
With 5 tools, this server is well-scoped for accessing FRED economic data. It covers essential operations like searching, retrieving metadata, and fetching observations, without being overly sparse or bloated. Each tool serves a clear purpose in the data exploration workflow.
The tool set provides strong coverage for browsing and retrieving economic data, including search, metadata, and observations. However, it lacks direct update or manipulation tools (e.g., for user favorites or annotations), which are minor gaps but not critical for the core domain of data access.
get_category_seriesAInspectGet all FRED series within a specific category.
FRED organizes data into a hierarchy of categories. Use this to browse
available series within a topic area. Common category IDs:
- 32991: Money, Banking, & Finance
- 10: Population, Employment, & Labor Markets
- 32992: National Accounts (GDP)
- 1: Production & Business Activity
- 32455: Prices (CPI, PPI)
- 97: Housing
Args:
category_id: FRED category identifier (integer).
| Name | Required | Description | Default |
|---|---|---|---|
| category_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the action as retrieving all series within a category, which is adequate but lacks details on pagination, limits, or potential side effects. It is acceptable for a 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?
The description is concise and well-structured: a one-line purpose, brief explanation of category hierarchy, common IDs list, and the parameter definition. Every sentence adds value with no 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 simplicity (one parameter, no nested objects) and the presence of an output schema, the description provides all necessary context: purpose, usage guidance, and parameter details are sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds significant value by explaining the parameter as a 'FRED category identifier' and listing common category IDs (e.g., 32991 for Money, Banking, & Finance). This greatly aids correct usage.
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 'Get all FRED series within a specific category' with a specific verb and resource. It distinguishes from siblings like search_series by focusing on browsing by category hierarchy.
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?
It provides context on when to use (browsing series within a topic area) and common category IDs, but does not explicitly mention when not to use or direct alternatives. The context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_release_datesAInspectGet release dates for a specific FRED data release.
Returns the dates when a particular data release was published. Useful
for tracking when economic indicators are updated. Common release IDs:
- 10: Consumer Price Index
- 46: Producer Price Index
- 50: Employment Situation (jobs report)
- 53: Gross Domestic Product
- 17: Federal Reserve H.15 (interest rates)
- 21: Federal Reserve H.6 (money stock)
Args:
release_id: FRED release identifier (integer).
| Name | Required | Description | Default |
|---|---|---|---|
| release_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the output (dates of publication) but does not explicitly state non-destructive behavior or authentication needs. It is adequate but not rich.
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 brief (about 5 lines), front-loaded with purpose, and every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 1 parameter and an output schema (so return values are documented), the description covers the parameter well, provides usage examples, and explains the output. It is complete for the tool's complexity.
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, but the description fully explains the parameter 'release_id' as a FRED release identifier with integer type and provides a list of common IDs with meanings.
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 'Get' and the resource 'release dates for a specific FRED data release'. It differentiates from siblings (get_category_series, get_series_info, etc.) by focusing on release dates.
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 context (useful for tracking economic indicator updates) and lists common release IDs. While it doesn't explicitly contrast with siblings, the distinct purpose makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_series_infoAInspectGet metadata and details for a specific FRED series.
Returns comprehensive information about a series including its title,
frequency, units, seasonal adjustment, source, and date range. Use this
to understand what a series measures before pulling observations.
Args:
series_id: FRED series identifier (e.g. 'UNRATE', 'GDP', 'CPIAUCSL').
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes the return information but does not explicitly state it is read-only, safe, or mention any prerequisites like API keys. Assumes safe read operation but lacks explicit disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus an Args block. Front-loaded with main purpose. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter, no nested objects, and an existing output schema, the description is fairly complete. It covers what the tool returns and when to use it, though it could mention that it is a safe read operation.
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%, but the description provides meaningful guidance for the sole parameter series_id: 'FRED series identifier (e.g. 'UNRATE', 'GDP', 'CPIAUCSL')'. This adds valuable context beyond the raw 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 'Get metadata and details for a specific FRED series' and lists specific return fields (title, frequency, units, etc.). It distinguishes from siblings like get_series_observations (data points) and 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?
Explicitly advises 'Use this to understand what a series measures before pulling observations,' providing clear context for appropriate use. Does not explicitly exclude scenarios or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_series_observationsAInspectGet time series observations (data points) for a FRED series.
Returns the actual data values for an economic indicator over time.
Use search_series first to find the series_id, or use well-known IDs
like UNRATE, GDP, CPIAUCSL, FEDFUNDS, MORTGAGE30US.
For state unemployment, use state abbreviation + 'UR' (e.g. WAUR for
Washington, CAUR for California).
Results are sorted most-recent-first. For long series (e.g. daily data
since 1954), use start_date/end_date to narrow the window or increase
the limit up to 10000.
Args:
series_id: FRED series identifier (e.g. 'UNRATE', 'GDP', 'CPIAUCSL').
start_date: Optional start date in YYYY-MM-DD format (e.g. '2020-01-01').
end_date: Optional end date in YYYY-MM-DD format (e.g. '2024-12-31').
limit: Maximum observations to return (default 1000, max 10000).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| end_date | No | ||
| series_id | Yes | ||
| start_date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that results are sorted most-recent-first and offers performance advice for long series. It does not mention authentication or rate limits, but the description is sufficiently transparent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement, usage examples, and a clear param list. It is efficient but could be slightly more concise. Overall, it earns its sentences.
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 output schema exists (explaining return values not needed), the description covers essential context: example IDs, state URL pattern, sorting order, and handling long series. It is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds significant value by explaining each parameter: series_id with examples, date format for start_date/end_date, and limit with default and max values. This compensates fully for 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 it retrieves time series observations/data points for a FRED series. It distinguishes from sibling tools like search_series and get_series_info by specifying the tool's role in fetching 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?
The description provides explicit guidance on when to use this tool: after searching for a series ID or using well-known IDs. It also gives examples for state unemployment and suggests using date filters or limit for long series. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_seriesAInspectSearch for FRED economic data series by keyword.
Use this to find series IDs for economic indicators. For example,
search 'unemployment rate' to find UNRATE, or 'gross domestic product'
to find GDP. Returns series metadata including ID, title, frequency,
units, and date range.
Common series: UNRATE (unemployment), GDP (gross domestic product),
CPIAUCSL (consumer price index), FEDFUNDS (federal funds rate),
MORTGAGE30US (30-year mortgage rate), MEHOINUSA672N (median household income).
Args:
search_text: Keywords to search for (e.g. 'unemployment rate', 'GDP', 'inflation').
limit: Maximum number of results to return (default 10, max 1000).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search_text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys that the tool returns series metadata, supports search by keyword, and has configurable result limits (default 10, max 1000). It does not cover rate limits or authentication, but for a search tool this is sufficient.
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 somewhat verbose with a list of common series and an Args block. While front-loaded with purpose, it could be more concise without losing 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 that an output schema exists (context indicates true), the description adequately covers purpose, usage, and parameters. It provides sufficient information for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds value by explaining search_text as keywords and limit as maximum results with default and max values, which the schema lacks.
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 searches for FRED economic data series by keyword, provides examples, and specifies what metadata is returned (ID, title, frequency, units, date range). This distinguishes it from sibling tools like get_series_info or get_series_observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to find series IDs for economic indicators' and gives examples. It does not explicitly mention when not to use it or alternatives, but the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!