Skip to main content
Glama

Release Calendar Markets

release_calendar_markets
Read-onlyIdempotent

JOIN of the official release calendar (econ data, the FOMC, FDA decisions, SEC rules) against LIVE Polymarket/Kalshi markets — which scheduled releases land in the next N hours, and which live markets resolve on them. This is a POSITIONING tool, not a speed product: results are cached like every other pack (≤ 60s TTL) and there is no push/webhook — do not use this to try to beat a release, use it to see what is coming and what is already priced. CATEGORIES: econ (CPI, Employment Situation/jobs report, GDP, PCE, PPI, retail sales, housing starts, jobless claims — via fred_release_dates per known release_id, since FRED's own cross-release calendar mostly returns recent actuals, not future dates), fed (the next FOMC meeting's rate decision, via fomc_calendar), fda (PDUFA action dates + FDA advisory-committee meetings, via pdufa_catalysts / fda_adcom_calendar), sec (SEC final rules whose own DATES clause names an effective date in the window, via federal-register recent_rules — usually finds nothing in a short window since SEC rules typically take effect 30–60 days out, which is an accurate answer, not a bug), court (ALWAYS EMPTY today — court-listener has no forward-looking scheduled-hearing calendar, only filing/termination dates, so this category returns zero releases with unsupported:true rather than fabricate one). Omit categories or pass "all" for every category. MATCHING AND ITS HONESTY CONTRACT: every release is returned even when it has ZERO matched markets — a release is never dropped just because nothing on Polymarket or Kalshi resolves on it (most FDA/SEC releases will show markets:[]; that is signal, not a gap). Every matched market carries resolves_on_this_release: "true" (the venue's own close/end date sits within ~36h of the release AND the question passed a subject filter — econ and fed only), "likely" (same subject filter, but the venue closes days away from the release date), or "unclear" (a keyword hit with no date to anchor against — always true for the fda category, which has no ladder structure to check a date against). matched_by names the mechanism (a Kalshi series ticker, a Polymarket search query, or an FDA keyword probe) so a caller can judge the match rather than trust a label. scheduled_at carries both utc and et; econ releases use the standing BLS/Census 8:30am ET convention (FRED's calendar itself has no clock time), FOMC decisions use the 2:00pm ET convention, and FDA/SEC dates are date_only:true (no reliable clock time exists for either). DO NOT treat a matched market as a real arbitrage or a settled fact on its own — a market question sharing tokens with a release name is not proof it settles on that release's own published number. Call resolution_audit / resolution_diff (fleet #1909) on a specific market before sizing anything here. An empty window (zero releases across every requested category) returns the SAME shape as a populated one — release_count:0, releases:[] — plus empty_reason:"no_releases_in_window" and a hint telling you to widen, so you never branch on the response shape and never have to guess whether zero means "nothing is scheduled" or "the lookup failed". Econ releases especially cluster on specific dates each month, so a 48h window often straddles a dead stretch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hoursNoLook-ahead window in hours from now. Default 48. Capped at 720 (30 days) — econ/fed releases are dated weeks apart, so a short window is often empty; widen rather than assume nothing is scheduled.
categoriesNoComma or space separated subset of econ|fed|fda|sec|court, or "all" (default). E.g. "econ,fed" or "fda".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNoPresent ONLY on a zero-release window: what to change (usually a wider `hours`).
as_ofNo
notesNo
windowNo
releasesNo
categoriesNo
empty_reasonNoPresent ONLY on a zero-release window: "no_releases_in_window". The window was queried and nothing is scheduled — this is an answer, not a failure.
release_countNo
releases_with_matched_marketsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / empty_reason
      Added value: +{
      +  "description": "Present ONLY on a zero-release window: \"no_releases_in_window\". The window was queried and nothing is scheduled — this is an answer, not a failure.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / hint
      Added value: +{
      +  "description": "Present ONLY on a zero-release window: what to change (usually a wider `hours`).",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the readOnly/idempotent safety profile, but the description goes far beyond: ≤60s cache TTL, no push/webhook, per-category data sources and their failure modes (SEC usually finds nothing, court ALWAYS empty with unsupported:true), the resolves_on_this_release honesty contract, matched_by mechanism disclosure, and the empty-window response shape. This is unusually rich behavioral disclosure.

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?

It is front-loaded with the core definition, but the body is an extremely long block with repeated warnings (empty windows, no arbitrage, cache limits) that could be consolidated. Most sentences earn their place, but the density and repetition hurt scannability for an agent choosing a tool.

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?

Given an output schema exists, the description needn't explain returns, and it still covers edge cases (empty window shape, zero-match releases, date-only categories) that an agent needs to call and interpret this correctly. Nothing material 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 100%, so the baseline is 3, but the CATEGORIES discussion adds real meaning the schema does not: what each category actually queries (fred_release_dates, fomc_calendar, pdufa_catalysts, federal-register recent_rules), why court is always empty, and the default semantics of omitting categories. That compensates above baseline.

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?

The first sentence names the exact operation — a JOIN of the official release calendar against live Polymarket/Kalshi markets — and states the output intent (which releases land in the next N hours and which markets resolve on them). It explicitly frames itself as a POSITIONING tool, distinguishing it from sibling speed/resolution tools like resolution_audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says when to use it ('see what is coming and what is already priced'), when NOT to use it ('do not use this to try to beat a release', no push/webhook), and routes the caller to resolution_audit / resolution_diff before sizing positions. Sibling alternatives and exclusions are both explicit.

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.