Skip to main content
Glama

Helious market intelligence

Economic calendar

get_economic_calendar
Read-onlyIdempotent

Economic releases with forecasts, prior values and the actual once it prints, plus Fed speakers and auction times. Defaults to yesterday through the next 7 days; widen days_back and days_ahead to see more, or filter to one country like US, EU, GB or JP. Pass event to read one release's consensus record instead: for each past print the consensus that stood, the first actual, the previous and the revised prior, with its surprise, newest first. Across the US, the euro area, the UK, Japan and Germany; how far back a call reads is the plan's history window (12 months on Starter, 24 on Pro, 10 years on Ultimate).

Input Schema

NameRequiredDescriptionDefault
eventNoOne release whose consensus record to read: a series slug like cpi, or a release name as the calendar prints it, like Consumer Price Index (MoM) or GB: Retail Sales (MoM).
freshNoSet true to ask for the live view of this one call, for 5 credits, where the connected account otherwise receives it an hour behind. Accepted and free where the account is already live. No effect without a key.
limitNoMost events to return. Default 100. With event, most rows, up to 520.
sinceNoWith event: the oldest release date to include, like 2018-01-01. How far back you can go depends on your plan.
countryNoTwo-letter country or bloc, like US, EU, GB, JP. Empty means everywhere.
days_backNoHow many days of already-printed events to include. Default 1, up to 90.
days_aheadNoHow many days ahead to include. Default 7, up to 365.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / event
      Added value: +{
      +  "description": "One release whose consensus record to read: a series slug like cpi, or a release name as the calendar prints it, like Consumer Price Index (MoM) or GB: Retail Sales (MoM).",
      +  "type": "string"
      +}
    • changedInput schema / properties / limit / description
      Previous value: -"Most events to return. Default 100."New value: +"Most events to return. Default 100. With event, most rows, up to 520."
    • addedInput schema / properties / since
      Added value: +{
      +  "description": "With event: the oldest release date to include, like 2018-01-01. How far back you can go depends on your plan.",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / fresh / description
      Previous value: -"Not on Pro or Ultimate? Set this to true and this one call answers live for 5 credits. Left out, Free, Squawk and Starter get the answer an hour behind for 1 credit. Pro and Ultimate are live already, so it costs nothing extra there. No effect without a key."New value: +"Set true to ask for the live view of this one call, for 5 credits, where the connected account otherwise receives it an hour behind. Accepted and free where the account is already live. No effect without a key."
  3. Changed1 schema field changed
    • addedInput schema / properties / fresh
      Added value: +{
      +  "description": "Not on Pro or Ultimate? Set this to true and this one call answers live for 5 credits. Left out, Free, Squawk and Starter get the answer an hour behind for 1 credit. Pro and Ultimate are live already, so it costs nothing extra there. No effect without a key.",
      +  "type": "boolean"
      +}
  4. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantive operational context: plan-dependent history windows (12 months Starter, 24 Pro, 10 years Ultimate), an hour of latency for non-live accounts, and a 5-credit cost for the `fresh` live view.

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-loads what the tool returns, then defaults, then the alternate mode, then plan limits. Dense but each clause carries information; the pricing/latency sentence for `fresh` is slightly buried mid-description.

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?

For a 7-parameter, no-output-schema tool it explains both return shapes (aggregate calendar rows and per-release consensus records), caps, and plan constraints. Ordering of calendar-mode results and whether results are paginated beyond `limit` are not stated.

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 100%, so the baseline is 3, but the description adds cross-parameter meaning: `event` converts the call into a per-release consensus history where `since` sets the floor and `limit` caps rows at 520, and `country` filters the calendar mode. This goes beyond the per-parameter schema text.

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?

States a concrete resource (economic releases with forecasts, prior and actual) and names the extra content types included (Fed speakers, auction times). It also describes a second mode selected by the `event` parameter. It does not explicitly distinguish itself from siblings like get_auctions or get_fed_roster, whose data it partly overlaps.

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?

Explains the default window (yesterday through 7 days) and how to widen it via days_back/days_ahead, how to narrow to a country, and when to switch to the `event` mode to read a single release's consensus record instead. No guidance about when to prefer sibling tools for auctions or Fed speakers.

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