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 error:"no_releases_in_window" with a widen-the-window hint rather than an empty array — 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
as_ofNo
notesNo
windowNo
releasesNo
categoriesNo
release_countNo
releases_with_matched_marketsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool read-only, idempotent, and non-destructive, but the description adds far more: ≤60s TTL caching, no push/webhook, empty-window error behavior, court category always empty with unsupported:true, and the honesty contract that releases with zero matched markets are returned rather than dropped. Match labels (true/likely/unclear) and matched_by are disclosed so callers can judge match quality.

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?

The description is long but well-organized into labeled sections (CATEGORIES, MATCHING AND ITS HONESTY CONTRACT) and front-loads the core purpose. Some clauses are defensive or verbose, such as 'which is an accurate answer, not a bug', but they prevent false bug reports; the density is justified for a multi-source tool with several behavioral caveats.

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?

Covers every behavioral edge case a caller needs: category semantics, empty-window error behavior, match confidence labels, timestamp conventions, and how to verify a match before trusting it. Even with an output schema present, the description adds return-value semantics (markets:[], resolves_on_this_release, matched_by, scheduled_at) and is complete for a complex tool.

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

Parameters5/5

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

Although the schema covers both parameters at 100%, the description adds rich semantic context: what each category means and which underlying source feeds it (fred_release_dates, fomc_calendar, pdufa_catalysts, federal-register), the hours cap and default, and the clock-time conventions for econ vs fed vs FDA/SEC dates. This transforms how an agent should set categories and hours.

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: JOIN of the official release calendar (econ, FOMC, FDA, SEC) against live Polymarket/Kalshi markets, returning scheduled releases in the next N hours and which live markets resolve on them. The 'POSITIONING tool, not a speed product' framing further distinguishes it from arbitrage/spread tools among the siblings.

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?

Explicitly says when not to use it ('do not use this to try to beat a release') and names concrete alternatives: call resolution_audit / resolution_diff before sizing anything. It also gives category-selection guidance and warns that a short window should be widened rather than assumed empty.

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.