Skip to main content
Glama

Get macro regime

get_macro_regime
Read-only

The current macro regime (GREEN / YELLOW / RED) and business cycle (SPRING / SUMMER / FALL / WINTER) with the evidence behind them: the detail behind the Regime and Business cycle cards of get_dashboard. The regime combines consumer mood (U Michigan sentiment) with money (the global-liquidity condition), and the money condition changes only after two consecutive weekly reads agree: data.details.liquidity_condition shows this week's raw read, the held class, how many agreeing reads are still needed, and the margin to the line. The business cycle crosses growth with prices. Growth is a vote of factory output (IPMAN trend), jobs (initial claims) and investment (BEA real investment in information-processing equipment and software), two of three deciding, and the season changes only when two prints in a row agree: data.cycle carries the vote, the dated prints and held_since. The response opens with the Jawz Dashboard card: the six-reading card as markdown at the top of presentation.display_markdown (above a horizontal rule), the same object at data.read, and the card as a PNG image content block after the text. Below the card, display_markdown carries the regime write-up and its tables (regime inputs, the growth vote, the growth and inflation composites, asset-class tilts); 'tables' is their structured form and 'data' holds the raw values. A 'provenance' block lists each input with its as-of date and age in days. get_indicator_history gives the regime, the cycle or any of their rows over time.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
dataNo
toolNo
statusNo
tablesNo
pillarsNo
summaryNo
warningsNo
generated_atNo
presentationNo
staleness_flagsNo

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.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly), so the bar is lower, and the description far exceeds it: it discloses the hysteresis rules (regime changes only after two consecutive agreeing weekly reads, cycle after two agreeing prints), which fields carry raw reads vs. held state, and the exact response shape including a PNG image block after the text.

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 the core answer (what the regime is) before the mechanics. The single dense paragraph is long but each clause carries real information (hysteresis rules, field mappings, presentation layout), with only mild redundancy between the display_markdown/tables/data enumeration.

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?

Output schema exists, yet the description goes further and maps the response layout (card markdown, data.read, PNG content block, below-card write-up and tables, provenance block). Nothing an agent needs to interpret or invoke this zero-arg tool 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?

Zero parameters, so the baseline is 4. The schema is empty and the description correctly spends no effort on arguments, focusing instead on output semantics.

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+resource (get the macro regime) and immediately defines its outputs (GREEN/YELLOW/RED regime, SPRING/SUMMER/FALL/WINTER cycle). It explicitly distinguishes itself from siblings by calling itself the detail behind get_dashboard's Regime/Business cycle cards and by routing time-series questions to get_indicator_history.

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?

Names the related siblings and their boundary: this tool is the detail behind get_dashboard's cards, while get_indicator_history gives the regime/cycle or their rows over time. It stops short of an explicit 'use this when X, not Y' conditional, but the routing context is clear enough for correct selection.

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