Skip to main content
Glama

FirmTape - SPX, ES, NQ, RTY gamma levels, 100+ symbols

Market calendar

get_events
Read-onlyIdempotent

The scheduled US market events for a window of days, from the same calendar the FirmTape terminal draws: FOMC decisions, press conferences and minutes, CPI, payrolls, PCE, PPI, GDP, retail sales, JOLTS, ISM, the Fed Chair's speeches, the Beige Book, 10/20/30-year Treasury auctions, mega-cap earnings, monthly and quarterly expiration and early closes. Each event carries its minute in ET, a link to its source, and, where the archive has measured it, what usually follows, what the dealer book did, and for the releases the forecast, the prior and the actual print. Use when: 'what is on the calendar this week', 'when is the next FOMC', 'is there anything at 14:00 today'. Not for: session measurements (get_session) or levels (get_levels). Limits: US only, 2019 to about a year ahead, at most 31 days per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoLast day, YYYY-MM-DD (default from + 6 days; at most 31 days)
fromNoFirst day, YYYY-MM-DD (default today, ET)
impactNoLowest impact to include (default med: high and medium)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesTrading day, YYYY-MM-DD
fromYesTrading day, YYYY-MM-DD
eventsYesScheduled US market events in the window, in date and time order
summaryYesOne sentence carrying this answer's numbers, its trading day and its source, written to be quoted verbatim to a reader rather than paraphrased.
data_as_ofYesThe time this answer's data is true as of, ISO 8601 with the ET offset: a finished session's close (13:00 on an early close), the minute a ladder was read at, or the source's own build stamp. Null when the source states none.
server_versionYesVersion of the FirmTape MCP server that produced this answer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / data_as_of
      Added value: +{
      +  "description": "The time this answer's data is true as of, ISO 8601 with the ET offset: a finished session's close (13:00 on an early close), the minute a ladder was read at, or the source's own build stamp. Null when the source states none.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / events / items / properties / book / description
      Previous value: -"What the dealer book did around this kind of event, from the archive, when measured: the flip, the gamma sign at the start of the window, the expected-hold band"New value: +"What the dealer book did around this kind of event, from the archive, when measured: the flip and the gamma sign at the start of the window"
    • addedOutput schema / properties / server_version
      Added value: +{
      +  "description": "Version of the FirmTape MCP server that produced this answer",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "summary",
      -  "from",
      -  "to",
      -  "events"
      -]New value: +[
      +  "summary",
      +  "from",
      +  "to",
      +  "events",
      +  "data_as_of",
      +  "server_version"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / properties / events / items / properties / book / description
      Previous value: -"What the dealer book did around this kind of event, from the archive, when measured: the flip, the gamma sign at the start of the window, the walls"New value: +"What the dealer book did around this kind of event, from the archive, when measured: the flip, the gamma sign at the start of the window, the expected-hold band"
  3. Changed2 schema fields changed
    • addedOutput schema / properties / events / items / properties / book
      Added value: +{
      +  "description": "What the dealer book did around this kind of event, from the archive, when measured: the flip, the gamma sign at the start of the window, the walls",
      +  "type": "string"
      +}
    • addedOutput schema / properties / events / items / properties / prints
      Added value: +{
      +  "description": "The release's numbers, when known: label, forecast, prior and (after the print) actual, as the release quotes them",
      +  "items": {
      +    "properties": {
      +      "actual": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "forecast": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "label": {
      +        "type": "string"
      +      },
      +      "prior": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      }
      +    },
      +    "required": [
      +      "label"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantive context beyond them: coverage limits (US only, 2019 to about a year ahead, at most 31 days per call) and what each event payload contains (ET minute, source link, measured follow-on behavior, dealer book reaction, forecast/prior/actual). These are real operational constraints an agent cannot derive from the annotations.

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 purpose, then 'Use when', 'Not for', and 'Limits' in a clear progression that is easy to scan. The long enumeration of event types is informative but somewhat list-heavy and could be trimmed without losing routing value.

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 return-value documentation is not required, and the description still supplies coverage bounds, timezone for the returned minutes, and default behavior context. Combined with full schema coverage and rich annotations, an agent has everything needed to invoke this correctly.

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 description coverage is 100%, so defaults, date patterns, the 31-day cap and the impact enum are already fully documented in the schema. The description only echoes the window and limit concepts generically without adding per-parameter meaning, so the baseline 3 applies.

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 (scheduled US market events over a day window) and enumerates the event classes it returns, so an agent knows exactly what domain this covers. It explicitly contrasts itself with get_session and get_levels, making sibling disambiguation unambiguous.

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?

Provides literal 'Use when' trigger phrasings ('what is on the calendar this week', 'when is the next FOMC') and an explicit 'Not for' clause routing to get_session and get_levels. Nothing about when to reach for this tool versus alternatives is left to inference.

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