Skip to main content
Glama

Get indicator history

get_indicator_history
Read-only

Any card of the Jawz Dashboard (get_dashboard), or one of its rows, over time, each at its own print dates: the weekly reads for the weekly cards, the release dates of the series behind a row for the rest. With no arguments it returns the catalogue: every card and indicator key with its kind, cadence, unit, source and the earliest date it reaches. card alone returns that card's badge (indicator defaults to 'badge'); card plus indicator returns that row. from and to (YYYY-MM-DD) set the window: to defaults to today and from to one year before to; the history reaches back 365 days (store of value starts 84 days later), and a clamped window is echoed as requested_from and effective_from. Every point carries Jawz's word for that date and point_in_time. What Jawz computes (the six badges, the four-bank money total, the dollar effect, US money, the growth vote) also carries the value and its display at every point. Published series that Jawz passes through unchanged (mood, jobs, BEA investment, prices, rates, credit, the dollar, gold, bitcoin, data centres, chips, builders' capex, power) carry Jawz's word per print plus the source (provider, series, link and, for FRED series, the ALFRED vintage link), because the full numbers stay with the publisher. The answer adds the rule in one sentence, transitions (every change of word), runs, and the current word with the date it has held since (for a badge, the card's own held_since). History applies today's rules to what was published by each date (rules: 'today'): method_events lists rule changes in the window that moved the card, and published_differs lists, for the regime and business-cycle badges, the dates where what Jawz published that day differs. The four-bank money rows add the coverage basis, a constant three-bank total and coverage and PBoC-statement events. An unknown card or indicator, a malformed or future date, or a date before the window returns an error naming the valid keys or range. A cold window that runs out of compute time returns the points ready with partial: true and pending_from; the same call again continues from the points already kept. Read-only, no account needed. Information, not investment advice.

Input Schema

NameRequiredDescriptionDefault
toNoWindow end, YYYY-MM-DD. Defaults to today (UTC).
cardNoCard key: regime, money, business_cycle, financial_conditions, store_of_value or investment. Omit card and indicator for the catalogue.
fromNoWindow start, YYYY-MM-DD. Defaults to one year before `to`; clamped to the 365-day window.
indicatorNoIndicator key within the card (the catalogue lists them), or 'badge'. Defaults to 'badge' when a card is given.

Output Schema

NameRequiredDescriptionDefault
toNo
cardNo
fromNo
kindNo
ruleNo
unitNo
cardsNo
labelNo
rulesNo
statsNo
eventsNo
pointsNo
sourceNo
cadenceNo
partialNo
versionNo
indicatorNo
transitionsNo
pending_fromNo
method_eventsNo
effective_fromNo
requested_fromNo
published_differsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already establish readOnly=true, destructive=false and closed-world, and the description layers on substantial extra behavior: 365-day reach (store of value 84 days later), clamping echoed as requested_from/effective_from, partial:true with pending_from on a cold window plus resumability, and error naming of valid keys. These are exactly the operational traits annotations cannot express.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a dense run-on wall of text with repeated phrasing ('Jawz's word' three times) and substantial output-shape detail that an existing output schema would already carry. It is informative but not tight; several clauses could be cut or deferred to the output schema.

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?

For a zero-required-parameter, query-style tool with an output schema, this covers everything an agent needs: catalogue mode, parameter defaults and clamping, error conditions, partial-result/resume semantics, and the special handling for computed badges versus passed-through published series. Nothing decision-relevant is missing.

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

Parameters4/5

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

Schema coverage is already 100%, but the description adds genuine meaning beyond the schema: 'to' defaults to today and 'from' to one year prior, the window is clamped to 365 days, and the badge/indicator interaction governs whether a card badge or a specific row is returned. This goes past the baseline 3 by supplying defaulting and clamping semantics the schema only sketches.

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

Purpose4/5

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

The opening clause states a specific verb+resource: any card of the Jawz Dashboard or one of its rows, over time, plus the no-argument catalogue mode. This is far more than a restatement of the name, but it never reconciles itself against closely overlapping siblings such as get_regime_history, get_conditions_history and get_liquidity_history, so an agent cannot tell from the text why it should pick this generic tool versus those per-domain ones.

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 gives explicit conditional behavior for argument combinations: no args returns the catalogue, card alone returns the badge, card plus indicator returns the row, and it explains that unknown keys or out-of-window/future dates produce an error naming valid keys or range. It stops short of naming alternatives or stating when this tool should be preferred over the domain-specific history siblings.

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