Skip to main content
Glama

Get series data

get_series
Read-only

Fetch one series' data: timeseries, tabular, or COMPOUND:: all work.

Returns title, units, frequency, notes and data points, with source metadata. transform="yoy_pct" (percent change) or "yoy_diff" (difference, for rates) adds a column with the change versus the same period one year earlier, matched by calendar date — use it for inflation or growth from one series instead of a LAG(value, 12) query, which goes wrong after any missing month. The cell is null where the prior-year period is absent, and transform.periods_without_prior lists those periods. The transformed value is rounded to 4 decimal places; round it once more only when you write the final figure, at the precision you report. If the result carries a coverage_note, the series has periods with no observation (listed in missing_periods): say so in the answer, leave them blank rather than interpolating, and label any aggregate that spans them as partial. SEC-backed results include row_sources keyed by result_index; each entry identifies the supporting filing, accession/form/publication date, whether the observation is reported or derived, and its standardized source_link. Cite that row's source URL beside any figure and label derived observations as derived. A document-precision link does not open an exact passage. IMF (imf schema) results also carry projections_start_after (the last year the IMF counts as actual; later years are IMF staff projections), release_label (the IMF publication, e.g. "Fiscal Monitor (October 2026)") and, when either is known, a projection_note. Say which years are projections when you use them. Both fields are null when the IMF gives no such fact for the series. At most 50 points come back; if the series is longer the result is flagged "truncated": true — narrow it with from_year/to_year, or pull the series through run_sql with an aggregation (e.g. monthly/quarterly via date_trunc) rather than trying to fetch every point.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "schema": "<schema>",
      "series_id": "<series_id>"
    },
    "name": "get_series"
  }
}

Input Schema

NameRequiredDescriptionDefault
schemaYes
to_yearNo
from_yearNo
series_idYes
transformNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only cover the read-only/safe profile, and the description layers substantial operational detail on top: a hard 50-point cap with a `truncated` flag, null cells where prior-year data is absent, a `transform.periods_without_prior` list, 4-decimal rounding, and mandatory disclosure behavior when `coverage_note`/`missing_periods` appear. It further documents SEC `row_sources` provenance and IMF projection semantics with citation obligations — far beyond what the annotations provide.

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

Conciseness4/5

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

Front-loaded with purpose and the transform rationale before edge cases, and nearly every paragraph carries actionable instruction. It is on the long side and the rounding sentence ("round it once more only when you write the final figure") is slightly convoluted, but no block is filler.

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

Completeness4/5

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

An output schema exists, yet the description still explains the fields that change agent behavior (truncation, coverage notes, provenance, projections) rather than restating the shape. The remaining gap is the allowed `schema` values and series_id discovery, which forces the agent to consult search_series or the catalog.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry parameter meaning. It does this well for `transform` (both enum values, purpose, null behavior, rounding) and adequately for `from_year`/`to_year` (narrowing a truncated range), but `series_id` and `schema` are barely specified — only `imf` is named as a schema value, with no enumeration of the rest or any hint of series_id format.

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?

Opens with a specific verb and resource ("Fetch one series' data") and scopes the accepted series shapes (timeseries, tabular, COMPOUND). It also enumerates the returned payload (title, units, frequency, notes, data points, source metadata), so an agent can distinguish it from search_series and run_sql without opening a schema.

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?

Explicit routing for the two decisions that matter: use `transform="yoy_pct"`/`"yoy_diff"` instead of a `LAG(value, 12)` query, and use `from_year`/`to_year` or `run_sql` with `date_trunc` when the 50-point cap truncates. What it does not state is when to reach for this versus sibling retrievers like search_series, get_market_data, or get_geo_data.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources