Skip to main content
Glama

get_release_tables

Read-onlyIdempotent

Fetch a FRED release's table hierarchy: sections, tables, and series rows. Optionally include observation values for a specific date.

Instructions

Fetch a FRED release's table tree — the nested layout (sections, tables, and the series rows beneath them) it uses to present its series. Optionally scope to the subtree rooted at one element id, and optionally fold each series row's observation value (at observation_date, or FRED's latest) into the tree via include_observation_values. Returns the tree as structured JSON, with each element's children nested under it. Note: element_id takes precedence over release_id — FRED resolves the element by its own id, so an element from another release yields that release's subtree. Note: each returned row's observation_date is FRED's display label (e.g. "Jun 2026"), not an ISO YYYY-MM-DD date like the inputs — it is not round-trippable back into any date parameter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
element_idNoReturn only the subtree rooted at this element id (omit for the whole tree). Takes precedence over `release_id`: FRED resolves the element by its own id, so if it belongs to a different release you get *that* release's subtree and `release_id` is effectively ignored. Pass an element that belongs to `release_id`.
release_idYesThe FRED release id, e.g. 10 (Consumer Price Index).
observation_dateNoObservation value as of this date, `YYYY-MM-DD`. Implies `include_observation_values`.
include_observation_valuesNoFold each series row's observation value into the tree (structure-only otherwise). FRED returns its latest value unless `observation_date` is set.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe name of the requested element, when a subtree was requested.
rootsYesThe root elements of the tree, ordered by element id. (FRED's redundant top-level `release_id` — a string, unlike the numeric one on each element — is dropped; the caller already knows it.) On the wire FRED names this `elements` (a flattened object keyed by id); we read that, keep only the tree's true roots, and re-serialize as a `roots` array (see `roots_from_map`).
element_idYesThe id of the requested element, when a subtree was requested.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint, idempotentHint, non-destructive), the description adds valuable behavioral details: element_id overrides release_id, returned observation_date is a display label not ISO, and the date is not round-trippable. This fully informs the agent of non-obvious behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet comprehensive, using a few well-structured sentences. It front-loads the primary purpose, then covers options and caveats without unnecessary words. The two notes are placed appropriately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (hierarchical tree, optional subtrees, observation inclusion, date caveat), the description fully covers what an agent needs to invoke it correctly. The output schema exists, so return value details are not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the baseline is 3. The description adds significant extra meaning: element_id precedence and cross-release behavior, release_id example, observation_date format and implication, and include_observation_values default logic. This greatly aids correct parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Fetch a FRED release's table tree' with a specific verb and resource, and elaborates on the nested layout. It distinguishes itself from sibling tools like get_release_series by focusing on the hierarchical tree structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains optional scoping and observation value inclusion, and provides important notes about element_id precedence and date format. However, it does not explicitly contrast with sibling tools or state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ojhermann-org/ferric-fred'

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