Skip to main content
Glama

Get regime history

get_regime_history
Read-only

Macro regime read-history — a timeseries of how the regime and its drivers have moved over recent weeks. Returns one row per sample date (regime color, business-cycle quadrant, growth + inflation class, consumer sentiment, global liquidity, dominant risk, confidence) plus the transitions between them (e.g. SUMMER → FALL). Provides the observed history behind a 'what changed since …' question, rather than a comparison of two separate point reads. Rule changes that moved the published colour or season without the market moving are listed in data.events as method events (kind 'method'), each dated the first day the new rule was live, with what changed and why: for example the money condition waiting for two consecutive weekly reads (2026-09-25) and the growth vote with two prints to change the season (2026-09-30). Observed rows keep what Jawz published that day under the rules then in force. Reading note, enforced by the artifact: the Liquidity column steps for two reasons that are NOT the market, and both are listed as first-class events in summary.liquidity_events — a g4↔g3 coverage flip (the whole PBoC component entering or leaving the sum: not a liquidity move at all), and a China-leg publication step (PBoC publishes monthly ~15d in arrears, so the day a new statement is recorded the column absorbs a whole month of change: real change, wrong date). get_liquidity_history carries a constant-basis G3 series that is immune to both. The response includes a 'presentation' object whose 'display_markdown' is a pre-formatted table; 'data.rows' and 'summary' carry the same values structured. Each row is provenance-tagged: 'observed' (captured live that day — true vintage) or 'reconstructed' (computed point-in-time from vintage data — each series as it was published on that date, so later revisions are excluded; depth-limited). Defaults to the last 12 weeks, weekly. get_indicator_history covers any card or row of get_dashboard over a year, at its own print dates.

Input Schema

NameRequiredDescriptionDefault
intervalNoSample cadence (default weekly)
lookback_weeksNoHow many weeks of history to cover (default 12, clamped 1–52)

Output Schema

NameRequiredDescriptionDefault
dataNo
toolNo
statusNo
summaryNo
warningsNo
generated_atNo
presentationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +true
  2. 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 safety profile (readOnly, non-destructive, closed-world), and the description goes well beyond them: provenance tagging of 'observed' vs 'reconstructed' rows with the reconstruction depth limit, method events in data.events, liquidity_events that explain non-market column steps, and the shape of the returned presentation/data/summary objects. This is exactly the extra context annotations cannot carry.

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 scope and return shape are front-loaded, but the body runs long for a 2-parameter tool. Dated illustrative examples (the 2026-09-25 money-condition rule, the 2026-09-30 growth vote) and the extended liquidity digression could be trimmed without losing selection-relevant information.

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?

An output schema exists, so the description is not obligated to explain return values, yet it still maps the response objects and provenance semantics thoroughly. Nothing an agent needs to call this correctly — cadence, lookback, provenance caveats, alternatives — is missing.

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 100% and the schema already documents both parameters including their defaults and the 1–52 clamp, so the baseline is 3. The description restates the defaults ('last 12 weeks, weekly') but adds no new syntax or constraint beyond what the schema already says.

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?

States a specific verb and resource (a regime read-history timeseries) and enumerates exactly what each row contains (colour, quadrant, growth/inflation class, sentiment, liquidity, risk, confidence) plus transitions. It actively distinguishes itself from the two nearest siblings, get_liquidity_history and get_indicator_history, so an agent can route without opening any 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?

Gives a clear selection condition — use this for the observed history behind a 'what changed since …' question, not for comparing two point reads — and names get_liquidity_history as the alternative when a constant-basis G3 series is needed. It stops short of a crisp when-not rule (e.g. when to prefer get_macro_regime or get_conditions_history), so a 4 rather than a 5.

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