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

Server Details

SPX, ES, NQ and RTY futures gamma levels (GEX), 1,000+ SPX sessions, plus 100+ ETFs and stocks

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 42 days
Last Tested: 2026-10-13 10:33
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.4/5.0

Scored 2026-10-03 13:40 across 12 tools

Disambiguation4/5

Most tools have clearly separate roles (calendar get_events, archive listing list_sessions, screening screen_sessions, cross-day history get_level_history), and the descriptions explicitly cross-reference siblings to steer selection. The main friction is the deliberate overlap among get_levels (an admitted 'strict subset of get_session'), get_session and get_gex_profile, plus get_symbol_gamma vs get_gex_profile split by 'latest snapshot' vs 'past session' — distinct once read carefully, but easy to mispick.

Naming Consistency4/5

A predictable get_/list_/screen_ verb_noun convention dominates (get_session, get_levels, get_level_history, get_gex_profile, get_symbol_gamma, list_sessions, screen_sessions). The only deviations are the bare verbs fetch and search, which are conventional and pair naturally as a document-retrieval duo, so consistency stays high.

Tool Count5/5

Twelve tools is well-scoped for a market-data research server: each tool maps to a distinct query pattern (single day, level set, cross-day trend, intraday ladder, events, coverage, ticker snapshot, session list, screening, document search/fetch). Nothing appears redundant enough to drop, and no obvious missing category inflates the count.

Completeness4/5

The surface covers the full read-only research lifecycle: discover (list_sessions, get_coverage, search), measure a day (get_session, get_levels), go intraday (get_gex_profile, get_market_moving_minutes), go cross-day (get_level_history), screen (screen_sessions), and cover other tickers (get_symbol_gamma), with calendar context (get_events). Gaps are minor and intentional (live data behind the paid stream, no signals, no non-SPX/futures history), which agents can work around.

Available Tools

12 tools

fetchFetch a FirmTape documentA

Read-onlyIdempotent

Inspect

Retrieve the full text of one FirmTape document by the id search returned: session:YYYY-MM-DD for a finished trading session, page:/path for an explainer or research page. A FirmTape URL or a bare YYYY-MM-DD trading day is accepted too. Use when: you hold an id from search, or a client that only speaks search/fetch (ChatGPT). Not for: structured numbers — get_session and get_levels answer the same day with fields instead of prose. Limits: public FirmTape documents only; long pages are truncated with a link to the rest.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	An id from `search`, a FirmTape URL, or a YYYY-MM-DD trading day

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false). The description adds real behavioral context beyond them: only public FirmTape documents are reachable, and long pages are truncated with a link to the remainder. It does not mention auth requirements or rate limits, so it falls short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then compactly sequenced as accepted inputs, use-when, not-for, and limits. Every clause carries routing or constraint information; there is no filler.

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?

For a single-parameter read tool with no output schema, the description covers the return nature (full text prose), the truncation edge case, the input formats, and the routing decision against siblings. Nothing needed to call it correctly 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% and the schema already names the three accepted id kinds, so baseline is 3. The description goes further by explaining the prefix conventions (`session:YYYY-MM-DD`, `page:/path`) and that a bare date or URL also works, giving the agent format-level meaning the schema does not.

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 ('Retrieve the full text of one FirmTape document') and immediately names the id namespace that identifies the document. It explicitly distinguishes itself from get_session and get_levels, so an agent can route without opening any schema.

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 explicit 'Use when' (you hold an id from `search`, or a client that only speaks search/fetch) and 'Not for' clauses naming the alternative tools that return structured numbers instead of prose. Both the selecting condition and the exclusion are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_coverageArchive coverageA

Read-onlyIdempotent

Inspect

What the free FirmTape SPX archive holds: the first and last finished session, how many sessions, and the NYSE trading days in that span that are MISSING from it (weekdays minus US market holidays; early closes count as trading days), optionally inside a from/to window. Use when: 'is 2024-03-15 in the archive', 'how complete is 2023', 'which days are missing' before a study that needs every session. Not for: the newest days themselves (list_sessions) or any measurement (get_session). Limits: the trading calendar covers 2022 to 2026; missing days are reported, never filled in.

ParametersJSON Schema

Name	Required	Description	Default
`to`	No	Last day of the window, YYYY-MM-DD (default: the archive's last session)
`from`	No	First day of the window, YYYY-MM-DD (default: the archive's first session)

Output Schema

ParametersJSON Schema

Name	Required	Description
`window`	Yes	The from/to filter as applied (null when not given)
`missing`	Yes	NYSE trading days in that span the archive does not hold, oldest first
`summary`	Yes	One sentence carrying this answer's numbers, its trading day and its source, written to be quoted verbatim to a reader rather than paraphrased.
`calendar`	Yes	Which trading calendar the missing days were computed against
`sessions`	Yes	Sessions the archive holds in the window
`unchecked`	No	Archived sessions outside the calendar's years, so not checked for gaps
`data_as_of`	Yes	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.
`last_session`	Yes	Newest session the archive holds in the window, YYYY-MM-DD
`trading_days`	Yes	NYSE trading days from first_session to last_session, inclusive
`first_session`	Yes	Oldest session the archive holds in the window, YYYY-MM-DD
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses operationally important behavior: the missing-day computation rule (weekdays minus US market holidays, early closes count), the calendar's 2022-2026 coverage limit, and the guarantee that missing days are reported and never filled. These are substantive traits the annotations cannot convey.

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 dense but front-loads the resource and return shape before usage and limits. Every clause carries information, though the single packed opening sentence is slightly heavy; structure is good but not maximally scannable.

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 values need no prose, yet the description still frames the exact fields returned and the semantics of 'missing'. Combined with the limits and routing guidance, nothing an agent needs to call this correctly is absent.

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%; both from/to parameters are documented with format, pattern, examples, and defaults in the schema itself. The description only restates that they form an optional window, adding little beyond the structured fields, so the baseline of 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?

The description names a specific resource (the SPX archive's coverage) and precisely enumerates what it returns: first/last finished session, session count, and missing NYSE trading days. It clearly distinguishes itself from list_sessions and get_session, so an agent can identify the tool without opening a schema.

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 gives explicit 'Use when' examples ('is 2024-03-15 in the archive', 'which days are missing') and an explicit 'Not for' clause naming the two sibling alternatives (list_sessions, get_session) with the condition that selects them. This is textbook when/when-not/alternatives guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_eventsMarket calendarA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`to`	No	Last day, YYYY-MM-DD (default from + 6 days; at most 31 days)
`from`	No	First day, YYYY-MM-DD (default today, ET)
`impact`	No	Lowest impact to include (default med: high and medium)

Output Schema

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Trading day, YYYY-MM-DD
`from`	Yes	Trading day, YYYY-MM-DD
`events`	Yes	Scheduled US market events in the window, in date and time order
`summary`	Yes	One 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_of`	Yes	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.
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer

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.

get_gex_profileGamma by strike

Read-onlyIdempotent

Inspect

The SPX dealer gamma LADDER for one minute of a finished session: gamma by strike around spot, the level set, and the heaviest strikes. Read by default as the VOLUME book, the one the terminal's chart draws; also as the MEASURED book (signed off the trade tape, FirmTape's own read) or the OPEN_INTEREST convention every other public GEX chart draws — the same minute through three lenses. The level set is the volume book's whichever ladder is read. Use when: the question is about SHAPE — where gamma sits, how heavy a wall is, how far the three conventions disagree — or about one moment inside a session rather than the day as a whole. Not for: a day's headline numbers (get_session), the level set alone (get_levels), or movement across days (get_level_history). ES: pass symbol ES (or MES) for ES strikes, the SPX ladder moved by the ES basis at the frame's minute. Limits: finished sessions only, one frame every 5 minutes (a requested minute snaps back to the frame at or before it), published window ±2.5% of spot; the three books are not comparable in magnitude. Measurements only, no buy/sell signals.

ParametersJSON Schema

Name	Required	Description
`day`	Yes	A finished trading day, YYYY-MM-DD. Call list_sessions if unsure which days exist.
`book`	No	Which book's ladder to read (default volume, the chart's book). open_interest is the convention rival tools print.
`minute`	No	ET minute HH:MM inside 09:30-16:00. Snaps back to the frame at or before it, so quote the minute the answer returns. Default: the last frame of the session.
`symbol`	No	SPX (default), or ES / MES: every strike, spot and level moved by the ES basis at the frame's minute. A day without a measured basis answers with SPX strikes and says so.
`contract`	No	Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.
`expiry_scope`	No	all = every expiry the session's book was pulled with (default); 0dte = the same-day slice alone
`strikes_around_spot`	No	How many strikes to return each side of spot (default 20). Raise it for the whole published window, which is +/-2.5% of spot.

Output Schema

ParametersJSON Schema

Name	Required	Description
`day`	Yes	Trading day, YYYY-MM-DD
`book`	Yes	Which book was read: measured, open_interest or volume
`note`	No	Present when a future was asked and its basis is not measured for the day
`spot`	Yes	SPX at that minute
`unit`	Yes	Unit of every gamma number below
`basis`	No	Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's
`levels`	Yes	Dealer-positioning levels in SPX index points (in ES points when `symbol` is ES or MES); null when the session did not produce one
`minute`	Yes	The ET minute (HH:MM) this profile actually belongs to. The archive keeps a frame every 5 minutes, so a requested minute snaps back to the frame at or before it — quote the minute returned here, not the one asked for.
`replay`	Yes	Free minute-by-minute replay of the session on FirmTape
`symbol`	No	What the prices are in: SPX, or ES / MES when asked and the day's basis is measured
`strikes`	Yes	Dealer gamma by strike at that minute, lowest strike first
`summary`	Yes	One sentence carrying this answer's numbers, its trading day and its source, written to be quoted verbatim to a reader rather than paraphrased.
`heaviest`	Yes	The largest strikes by absolute gamma inside the window, heaviest first
`book_note`	No	How this book is built, and what it can and cannot be compared with
`data_as_of`	Yes	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.
`expiry_scope`	Yes	all = every expiry this session's book was pulled with; 0dte = the same-day slice alone
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer
`requested_symbol`	No	Present when a future was asked but the day has no measured basis, so the answer is SPX's
`strikes_returned`	Yes	How many strikes the window actually held
`net_gamma_in_window`	Yes	Sum of the returned strikes — a window total, not the session's net gamma

get_level_historyLevel history

Read-onlyIdempotent

Inspect

How the SPX dealer-positioning levels MOVED across recent finished sessions: the zero-gamma flip, call wall and put wall day by day, each session's change from the one before, and summary statistics for the window (flip range, net drift, mean daily movement, how often price closed above the flip). Use when: the question is about a trend or a window — has the flip been climbing, how far does it travel in a week — instead of calling get_levels once per day. Not for: one day (get_levels / get_session) or anything inside a session (get_gex_profile). ES: pass symbol ES (or MES) for the same series in E-mini prices, each session moved by its own ES basis. Limits: finished sessions only, max 40 per call; days absent from the archive are reported in missing, never interpolated. Measurements only — no buy/sell signals, no forecast.

ParametersJSON Schema

Name	Required	Description
`to`	No	End of an explicit window, YYYY-MM-DD (inclusive). Defaults to the newest finished session.
`days`	No	How many of the most recent finished sessions to read (default 20, max 40). Ignored when `from` is given.
`from`	No	Start of an explicit window, YYYY-MM-DD (inclusive). Overrides `days`.
`symbol`	No	SPX (default), or ES / MES: each session's levels and close moved by that session's ES basis at its close. Sessions without a measured basis are left out and listed in no_basis; with fewer than two measured, the answer is SPX's and says so.
`contract`	No	Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.

Output Schema

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Trading day, YYYY-MM-DD
`from`	Yes	Trading day, YYYY-MM-DD
`note`	No	Present when a future was asked and its basis is not measured for the day
`basis`	No	Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's
`symbol`	No	What the prices are in: SPX, or ES / MES when asked and the day's basis is measured
`missing`	Yes	Days in the requested window with no payload in the archive; the window is reported over what was actually read
`summary`	Yes	One sentence carrying this answer's numbers, its trading day and its source, written to be quoted verbatim to a reader rather than paraphrased.
`movement`	Yes	How the level set travelled across the window. Descriptive statistics, not a forecast.
`no_basis`	No	ES only: sessions in the window with no measured basis, left out of the ES series rather than shown at SPX prices
`sessions`	Yes	One entry per finished session, NEWEST FIRST, same order as list_sessions
`data_as_of`	Yes	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.
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer
`requested_symbol`	No	Present when a future was asked but the day has no measured basis, so the answer is SPX's

get_levelsLevel set

Read-onlyIdempotent

Inspect

Only the dealer-positioning level set for one finished SPX session: zero-gamma flip, call wall, put wall, plus where the session closed relative to them. A strict subset of get_session. Use when: the levels are the whole question and the rest of the session would be noise. Not for: OHLC, flip crossings, net-gamma percentile or ATM IV (get_session); more than one day (get_level_history); gamma by strike (get_gex_profile). ES: pass symbol ES (or MES) for ES gamma levels, the SPX levels moved by the day's ES basis (future minus index from put-call parity; no CME data); NQ levels come from get_symbol_gamma. Limits: finished sessions only, one day per call.

ParametersJSON Schema

Name	Required	Description
`day`	Yes	A finished trading day, YYYY-MM-DD. Weekends, holidays and days before coverage return an error — call list_sessions to see which days exist.
`symbol`	No	SPX (default), or ES / MES for the E-mini: the SPX book moved by the day's ES basis (future minus index from put-call parity). A day without a measured basis answers with SPX index levels and says so.
`contract`	No	Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.

Output Schema

ParametersJSON Schema

Name	Required	Description
`day`	Yes	Trading day, YYYY-MM-DD
`note`	No	Present when a future was asked and its basis is not measured for the day
`basis`	No	Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's
`close`	Yes	Session close
`levels`	Yes	Dealer-positioning levels in SPX index points (in ES points when `symbol` is ES or MES); null when the session did not produce one
`replay`	Yes	Free minute-by-minute replay of the session on FirmTape
`symbol`	No	What the prices are in: SPX, or ES / MES when asked and the day's basis is measured
`summary`	Yes	One 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_of`	Yes	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.
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer
`close_minus_flip`	Yes	Close minus zero-gamma flip, index points; positive = closed above the flip
`requested_symbol`	No	Present when a future was asked but the day has no measured basis, so the answer is SPX's

get_market_moving_minutesMinutes that moved the tapeA

Read-onlyIdempotent

Inspect

The minutes of one finished SPX session that the tape itself marked as market-moving, with what stood beside each: the scheduled event that owned the minute, the moment two or more public news desks carried an item (timed to the second, labelled by class, never the headline's text), or the honest reading that no headline existed and the dealer book moved on its own. Each minute carries the index move over the next 5 and 15 minutes and the flip at that minute. Use when: 'what moved SPX at 14:25 on 2026-09-10', 'were there news-driven minutes yesterday', 'which afternoon moves had no headline'. Not for: the scheduled calendar itself (get_events) or the day's levels (get_levels). Limits: finished sessions only (the live day is part of the paid live stream), sessions from 2022-04 on, ET clock.

ParametersJSON Schema

Name	Required	Description	Default
`day`	No	The session, YYYY-MM-DD (default: the last finished session)
`tape_only`	No	Only minutes the tape confirmed (default true; false adds the flashes the tape ignored and the calendar events it did not react to)

Output Schema

ParametersJSON Schema

Name	Required	Description
`day`	Yes	Trading day, YYYY-MM-DD
`minutes`	Yes	The marked minutes of the session in clock order
`summary`	Yes	One 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_of`	Yes	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.
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious constraints beyond that: finished sessions only, the live day belonging to the paid live stream, coverage starting 2022-04, and an ET clock. It does not discuss result size or rate limits, but the freshness/entitlement limits are the material ones and they are stated.

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?

The 'Use when / Not for / Limits' scaffolding is well organized and front-loads the essentials, but the opening sentence is a sprawling, heavily clause-laden construction whose decorative phrasing ('what stood beside each', 'the honest reading that no headline existed') costs more than it returns.

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?

With an output schema handling return values, a 100%-covered input schema, idempotent/readOnly annotations, and a description that covers scope, use cases, exclusions, coverage start date, and entitlements, an agent has everything needed to call 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%, with both 'day' (format, default) and 'tape_only' (default true, what false adds) fully documented in the schema. The description reinforces the tape-vs-headline distinction prose-wise but adds no new parameter syntax or semantics. Baseline 3 is correct when the schema does the heavy lifting.

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?

The description names a concrete resource and scope: the market-moving minutes of one finished SPX session, plus the three kinds of annotations each minute carries (scheduled event, news-desk item, or no headline at all). It also distinguishes itself from siblings by name in the 'Not for' clause. The ornate phrasing ('what stood beside each', 'the honest reading') slightly obscures an otherwise precise statement of purpose.

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?

Explicit when-to-use examples are given ('what moved SPX at 14:25 on 2026-09-10', 'were there news-driven minutes yesterday', 'which afternoon moves had no headline'), and alternatives are named with the condition that routes away from this tool: the scheduled calendar (get_events) and the day's levels (get_levels). Nothing 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.

get_sessionSession summary

Read-onlyIdempotent

Inspect

Everything FirmTape measured for ONE finished SPX session: OHLC and VWAP, the zero-gamma flip and how often price crossed it, call/put walls, net-gamma percentile, ATM IV at the open. Use when: you want a whole day in a single call. Not for: the level set alone (get_levels returns the same day, narrower), how the levels moved across days (get_level_history), or gamma by strike (get_gex_profile). ES: pass symbol ES (or MES) for the same day in E-mini prices, the SPX book moved by the day's ES basis. Limits: finished sessions only, one day per call. Measurements only — FirmTape deliberately publishes no buy/sell signals.

ParametersJSON Schema

Name	Required	Description
`day`	Yes	A finished trading day, YYYY-MM-DD. Weekends, holidays and days before coverage return an error — call list_sessions to see which days exist.
`symbol`	No	SPX (default), or ES / MES for the E-mini: the SPX book moved by the day's ES basis (future minus index from put-call parity). A day without a measured basis answers with SPX index levels and says so.
`contract`	No	Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.

Output Schema

ParametersJSON Schema

Name	Required	Description
`day`	Yes	Trading day, YYYY-MM-DD
`note`	No	Present when a future was asked and its basis is not measured for the day
`basis`	No	Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's
`events`	No	The day's scheduled market events (high and medium impact), each with its minute in ET, its source, the release's prints when known, and, for an event inside the session, what the book did in the 15 minutes after it
`replay`	Yes	Free minute-by-minute replay of the session on FirmTape
`symbol`	No	What the prices are in: SPX, or ES / MES when asked and the day's basis is measured
`session`	Yes	SPX price facts for the session
`summary`	Yes	One 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_of`	Yes	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.
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer
`requested_symbol`	No	Present when a future was asked but the day has no measured basis, so the answer is SPX's
`dealer_positioning`	Yes

get_symbol_gammaGamma for another symbol, ES, NQ or RTY

Read-onlyIdempotent

Inspect

The latest dealer gamma picture for a symbol OTHER than the SPX archive: index, ETF and stock option chains (for example QQQ, SPY, IWM, NDX, RUT, NVDA, TSLA, GLD, TLT), and the E-mini futures ES, NQ and RTY (MES, MNQ, M2K): ES/NQ/RTY are the SPX/NDX/RUT books moved by the day's basis (future minus index, from put-call parity on the index options; no CME data). Returns spot, the zero-gamma flip, call and put walls and net gamma for the VOLUME book and the OPEN_INTEREST book, the heaviest strikes, a per-expiry table and a trust grade. Use when: the question is about a ticker's gamma exposure, flip or walls right now or at the last close, including ES, NQ or RTY gamma levels. Not for: SPX or ES history or a past date (get_session, get_levels, get_gex_profile, which take symbol ES for past days); anything inside a past session. Limits: latest snapshot only (rebuilt every few minutes in session hours); calls count as dealer-long and puts as dealer-short, which is a convention, not a measurement, and on single stocks it is an approximation (see trust.grade: A and B are indices and ETFs, C and D single stocks). Units: US dollars of dealer delta per 1% move.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	The ticker, or ES / MES / NQ / MNQ / RTY / M2K (a dated code such as ESZ26 or RTYZ26 works too). Carried symbols are listed at https://firmtape.com/gex; an unknown ticker returns an error naming that page.
`contract`	No	Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.

list_sessionsList sessionsA

Read-onlyIdempotent

Inspect

List the finished SPX trading sessions in the free FirmTape archive, newest first, with the total count and how far back coverage runs. Every listed day can be fetched with get_session / get_levels and replayed free at FirmTape. Use when: you need to know which days exist, or the size and span of the archive, before asking about one. Not for: any measurement about a day — call get_session with that date instead. Limits: finished sessions only (today's session appears after the close), max 50 days per call.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many days to return (default 10, max 50)

Output Schema

ParametersJSON Schema

Name	Required	Description
`newest`	Yes	Trading days, newest first
`summary`	Yes	One 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_of`	Yes	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.
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer
`total_sessions`	Yes	How many finished sessions the free archive holds

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description goes further by disclosing that only finished sessions appear (today's shows after the close) and that each call is capped at 50 days — real behavioral constraints an agent would otherwise have to discover by failing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what the tool returns, then the when/not-for routing, then the limits. Every clause carries distinct information — scope, ordering, routing, freshness, cap — with no filler or repetition.

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 detail is not required, yet the description still summarizes the key payload (total count, coverage span). Combined with the freshness and cap caveats, an agent has everything needed to call this correctly and interpret the result.

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?

Only one optional parameter and schema description coverage is 100%, so the schema already documents limit, its default of 10 and its max of 50. The description restates the max-50 cap but adds no format or semantics beyond the schema; the baseline of 3 applies when the schema does the heavy lifting.

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 (list) and resource (finished SPX trading sessions in the FirmTape archive), plus ordering (newest first) and what comes back (total count, coverage span). This cleanly separates it from get_session and get_levels, which fetch a single day's data.

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?

Explicit 'Use when' (discovering which days exist, or the archive size/span, before querying a day) and an explicit 'Not for' that routes measurement questions to get_session with a date. The alternative tool is named and the selecting condition is stated, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screen_sessionsScreen sessionsA

Read-onlyIdempotent

Inspect

Filter the finished SPX sessions in the FirmTape archive by their closing measurements and count them: regime at the close and at the open, zero-gamma flip crossings, direction and size of the move, net-gamma percentile, 0DTE ATM IV at the open, the calendar event, weekday and year. Returns how many sessions match, two shares over them (closed above the flip, mean absolute move) printed next to the same shares over the whole archive, and the matched days. A matched share close to the archive's share is a base rate, not a pattern. Use when: 'how often did FOMC days close in negative gamma', 'the days that closed below the flip with the percentile under 20', 'largest moves on CPI days since 2024'. Not for: one day's numbers (get_session), gamma by strike (get_gex_profile), or testing a rule with out-of-sample statistics (the Lab). Limits: counts over finished sessions' closing measurements only, no per-strike data; at most 50 sessions listed per call. Counts, not investment advice.

ParametersJSON Schema

Name	Required	Description
`iv`	No	0DTE ATM implied vol at the open: under 10%, 10-15%, 15-20%, 20% and above
`dir`	No	Direction of the open-to-close move
`dow`	No	Day of the week
`gpct`	No	Net-gamma percentile at the close: under 20, 20 to 50, 50 to 80, 80 and above
`move`	No	Size of the open-to-close move: under 0.5%, 0.5% or more, 1% or more, 2% or more
`open`	No	Regime at the open: pos = opened above the flip, neg = below
`sort`	No	Order of the sessions list: newest (default), oldest, move (largest absolute move first), gpct (highest percentile first)
`year`	No	Calendar year, e.g. 2025; a year outside the archive is dropped
`cross`	No	Flip crossings in the session: 0 = none, 1 = exactly one, 2 = two or more
`event`	No	Event the day carried: fomc (decision days), cpi, nfp (payrolls), pce, ppi, gdp, retail (retail sales), jolts, ism, claims, auctions (Treasury), fed (speeches, Beige Book), opex (expiration), vix (VIX settlement), umich, confidence, eia, halts (halt in a top name), housing (housing and durables), refunding, rebalances (index), none (no event of these kinds)
`limit`	No	How many matched sessions to list (default 20, max 50); the counts always cover every match
`regime`	No	Regime at the close: pos = closed above the zero-gamma flip, neg = below

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The /screener page that shows the same result to a person
`label`	Yes	The filters in words
`shares`	Yes	The same three shares over the matched sessions and over the whole archive; a matched share close to the archive's is a base rate, not a pattern
`source`	No
`filters`	No	The filters the screener accepted; a value outside the vocabulary is dropped, not an error
`matched`	Yes	Sessions matching every filter
`summary`	Yes	One sentence carrying this answer's numbers, its trading day and its source, written to be quoted verbatim to a reader rather than paraphrased.
`archived`	Yes	Finished sessions in the archive
`screened`	Yes	Sessions whose closing measurements were available to screen
`sessions`	Yes	Matched sessions in the requested order (default newest first), at most `limit`
`truncated`	Yes	True when more sessions matched than `sessions` carries
`data_as_of`	Yes	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.
`question_url`	No	When the filters are one of the screener's common questions, that question's own page (e.g. /screener/negative-gamma-closes), the address to cite
`server_version`	Yes	Version of the FirmTape MCP server that produced this answer

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, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds crucial context beyond annotations: it returns counts plus two shares compared against archive-wide shares, lists at most 50 matched sessions, and warns that a matched share close to the archive's share is a base rate rather than a pattern. It also restricts counting to finished sessions' closing measurements with no per-strike data.

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 dense but front-loads the core purpose before moving into returns, usage, exclusions, and limits. The labeled 'Use when', 'Not for', and 'Limits' sections make it easy to scan. It is slightly long and the initial filter enumeration partly repeats the schema, but every section serves a distinct purpose.

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 a 12-parameter filtering tool with an output schema, the description supplies what an agent needs: counts and shares semantics, a 50-session listing cap, the fact that counts cover all matches, and clear routing to sibling tools. Output schema existence means return format details are not required, and the description still adds useful output context.

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 each of the 12 parameters already has a clear enum or format description. The description enumerates the filters in prose but adds no syntax, default, or interpretation detail beyond what the schema already provides. The baseline score of 3 is appropriate when the schema carries the parameter 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 and resource: filter finished SPX sessions in the FirmTape archive by closing measurements and count them. It distinguishes itself from siblings by naming get_session, get_gex_profile, and the Lab as alternatives for other tasks. An agent can tell exactly what this tool does and does not do without opening the schema.

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 explicit 'Use when' examples ('how often did FOMC days close in negative gamma', 'the days that closed below the flip with the percentile under 20') and an explicit 'Not for' section routing to get_session, get_gex_profile, and the Lab. This is textbook when/when-not/alternatives guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchSearch FirmTapeA

Read-onlyIdempotent

Inspect

Search FirmTape for documents about SPX dealer positioning: the explainer pages, the dated research measurements, and the archive of finished trading sessions. Returns ids to pass to fetch. A date in the query ("2026-08-24", "August 24 2026", "August 2026") finds the session or sessions for it. Clients that can call the specific tools should prefer list_sessions / get_session / get_levels / get_level_history / screen_sessions instead — those return structured numbers rather than documents. Not for: fetching a document you already have the id for (fetch) or any measurement you can name a date for. Limits: FirmTape's own public pages and finished sessions only, ranked by keyword — it searches no other site.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	A topic, a question, or a trading date

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: it returns ids intended for `fetch`, it only searches FirmTape's own public pages and finished sessions, and results are keyword-ranked rather than exhaustive. It stops short of describing result volume or pagination.

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 critical scoping and routing information is front-loaded, and the sentence about preferring structured sibling tools is the highest-value line. It runs long at five sentences with some overlap between the "prefer the specific tools" and "Not for" clauses, so it is slightly denser than necessary.

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?

With no output schema, the description correctly explains the return contract (ids to pass to `fetch`) and the corpus limits, ranking method, and date handling. The remaining gap is operational detail such as result counts or pagination, which an agent might want for a ranked keyword search.

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% but the schema's own parameter note is thin ("A topic, a question, or a trading date"). The description compensates by giving concrete accepted date forms ("2026-08-24", "August 24 2026", "August 2026") and explaining that a date resolves to that session or sessions, which the schema alone does not convey.

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 description opens with a specific verb+resource ("Search FirmTape") and narrows the corpus to documents about SPX dealer positioning: explainer pages, dated research measurements, and finished session archives. It distinguishes itself from the sibling tools by naming them and stating what they return instead (structured numbers vs. documents).

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 gives explicit routing guidance: clients able to call specific tools should prefer list_sessions / get_session / get_levels / get_level_history / screen_sessions, and it adds a dedicated "Not for" clause covering fetch and nameable-date measurements. Both when-to-use and when-not-to-use are stated with the alternative named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesOct 11, 2026

Changedget_gex_profile2 fields changed

changedOutput schema / properties / basis / description

Previous value: -"Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"New value: +"Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"

changedOutput schema / properties / basis / properties / index / description

Previous value: -"The index whose book was moved: SPX or NDX"New value: +"The index whose book was moved: SPX, NDX or RUT"

Changedget_level_history2 fields changed

changedOutput schema / properties / basis / description

Previous value: -"Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"New value: +"Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"

changedOutput schema / properties / basis / properties / index / description

Previous value: -"The index whose book was moved: SPX or NDX"New value: +"The index whose book was moved: SPX, NDX or RUT"

Changedget_levels2 fields changed

changedOutput schema / properties / basis / description

Previous value: -"Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"New value: +"Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"

changedOutput schema / properties / basis / properties / index / description

Previous value: -"The index whose book was moved: SPX or NDX"New value: +"The index whose book was moved: SPX, NDX or RUT"

Changedget_session2 fields changed

changedOutput schema / properties / basis / description

Previous value: -"Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"New value: +"Present when an ES/MES (or NQ/MNQ, RTY/M2K) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's"

changedOutput schema / properties / basis / properties / index / description

Previous value: -"The index whose book was moved: SPX or NDX"New value: +"The index whose book was moved: SPX, NDX or RUT"

Changedget_symbol_gamma5 fields changed

changedInput schema / properties / contract / examples

Previous value: -[
-  "ESZ26",
-  "NQH27"
-]New value: +[
+  "ESZ26",
+  "NQH27",
+  "RTYZ26"
+]

changedInput schema / properties / contract / pattern

Previous value: -"^M?(ES|NQ)[FGHJKMNQUVXZ]\\d{1,2}$"New value: +"^(M?ES|M?NQ|RTY|M2K)[FGHJKMNQUVXZ]\\d{1,2}$"

changedInput schema / properties / symbol / description

Previous value: -"The ticker, or ES / MES / NQ / MNQ (a dated code such as ESZ26 works too). Carried symbols are listed at https://firmtape.com/gex; an unknown ticker returns an error naming that page."New value: +"The ticker, or ES / MES / NQ / MNQ / RTY / M2K (a dated code such as ESZ26 or RTYZ26 works too). Carried symbols are listed at https://firmtape.com/gex; an unknown ticker returns an error naming that page."

changedInput schema / properties / symbol / examples

Previous value: -[
-  "QQQ",
-  "NVDA",
-  "ES",
-  "NQ"
-]New value: +[
+  "QQQ",
+  "NVDA",
+  "ES",
+  "NQ",
+  "RTY"
+]

changedInput schema / properties / symbol / pattern

Previous value: -"^\\$?[A-Za-z]{1,5}(\\d{1,2})?$"New value: +"^\\$?([A-Za-z]{1,5}|[Mm]2[Kk][A-Za-z]?)(\\d{1,2})?$"

10 tool updatesOct 3, 2026

Addedget_coverage

Changedget_events4 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"
+]

Changedget_gex_profile5 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"
+  ]
+}

removedOutput schema / properties / levels / properties / hold_band

Removed value: -{
-  "description": "[low, high] band where dealer hedging tends to pin price",
-  "items": {
-    "type": [
-      "number",
-      "null"
-    ]
-  },
-  "maxItems": 2,
-  "minItems": 2,
-  "type": "array"
-}

changedOutput schema / properties / levels / required

Previous value: -[
-  "zero_gamma_flip",
-  "call_resistance",
-  "put_support",
-  "hold_band"
-]New value: +[
+  "zero_gamma_flip",
+  "call_resistance",
+  "put_support"
+]

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",
-  "day",
-  "minute",
-  "book",
-  "expiry_scope",
-  "unit",
-  "spot",
-  "levels",
-  "strikes",
-  "strikes_returned",
-  "net_gamma_in_window",
-  "heaviest",
-  "replay"
-]New value: +[
+  "summary",
+  "day",
+  "minute",
+  "book",
+  "expiry_scope",
+  "unit",
+  "spot",
+  "levels",
+  "strikes",
+  "strikes_returned",
+  "net_gamma_in_window",
+  "heaviest",
+  "replay",
+  "data_as_of",
+  "server_version"
+]

Changedget_level_history5 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"
+  ]
+}

addedOutput schema / properties / server_version

Added value: +{
+  "description": "Version of the FirmTape MCP server that produced this answer",
+  "type": "string"
+}

removedOutput schema / properties / sessions / items / properties / levels / properties / hold_band

Removed value: -{
-  "description": "[low, high] band where dealer hedging tends to pin price",
-  "items": {
-    "type": [
-      "number",
-      "null"
-    ]
-  },
-  "maxItems": 2,
-  "minItems": 2,
-  "type": "array"
-}

changedOutput schema / properties / sessions / items / properties / levels / required

Previous value: -[
-  "zero_gamma_flip",
-  "call_resistance",
-  "put_support",
-  "hold_band"
-]New value: +[
+  "zero_gamma_flip",
+  "call_resistance",
+  "put_support"
+]

changedOutput schema / required

Previous value: -[
-  "summary",
-  "from",
-  "to",
-  "sessions",
-  "movement",
-  "missing"
-]New value: +[
+  "summary",
+  "from",
+  "to",
+  "sessions",
+  "movement",
+  "missing",
+  "data_as_of",
+  "server_version"
+]

Changedget_levels5 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"
+  ]
+}

removedOutput schema / properties / levels / properties / hold_band

Removed value: -{
-  "description": "[low, high] band where dealer hedging tends to pin price",
-  "items": {
-    "type": [
-      "number",
-      "null"
-    ]
-  },
-  "maxItems": 2,
-  "minItems": 2,
-  "type": "array"
-}

changedOutput schema / properties / levels / required

Previous value: -[
-  "zero_gamma_flip",
-  "call_resistance",
-  "put_support",
-  "hold_band"
-]New value: +[
+  "zero_gamma_flip",
+  "call_resistance",
+  "put_support"
+]

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",
-  "day",
-  "levels",
-  "close",
-  "close_minus_flip",
-  "replay"
-]New value: +[
+  "summary",
+  "day",
+  "levels",
+  "close",
+  "close_minus_flip",
+  "replay",
+  "data_as_of",
+  "server_version"
+]

Changedget_market_moving_minutes4 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"
+  ]
+}

removedOutput schema / properties / minutes / items / properties / hold_band

Removed value: -{
-  "description": "The expected-hold band at the minute, 'lo / hi': the corridor of spot over which the measured book's gamma stays positive. Not the walls. (Was misnamed `walls` before 0.2.4.)",
-  "type": [
-    "string",
-    "null"
-  ]
-}

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",
-  "day",
-  "minutes"
-]New value: +[
+  "summary",
+  "day",
+  "minutes",
+  "data_as_of",
+  "server_version"
+]

Changedget_session6 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"
+  ]
+}

removedOutput schema / properties / dealer_positioning / properties / levels / properties / hold_band

Removed value: -{
-  "description": "[low, high] band where dealer hedging tends to pin price",
-  "items": {
-    "type": [
-      "number",
-      "null"
-    ]
-  },
-  "maxItems": 2,
-  "minItems": 2,
-  "type": "array"
-}

changedOutput schema / properties / dealer_positioning / properties / levels / required

Previous value: -[
-  "zero_gamma_flip",
-  "call_resistance",
-  "put_support",
-  "hold_band"
-]New value: +[
+  "zero_gamma_flip",
+  "call_resistance",
+  "put_support"
+]

changedOutput schema / properties / events / items / properties / after / description

Previous value: -"spot over the 15 minutes after the event, the flip and the expected-hold band before and after, the net gamma sign; only for events inside the session"New value: +"spot over the 15 minutes after the event, the flip before and after, the net gamma sign; only for events inside the session"

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",
-  "day",
-  "session",
-  "dealer_positioning",
-  "replay"
-]New value: +[
+  "summary",
+  "day",
+  "session",
+  "dealer_positioning",
+  "replay",
+  "data_as_of",
+  "server_version"
+]

Changedlist_sessions3 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"
+  ]
+}

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",
-  "total_sessions",
-  "newest"
-]New value: +[
+  "summary",
+  "total_sessions",
+  "newest",
+  "data_as_of",
+  "server_version"
+]

Removedoptions_strategy_test

Changedscreen_sessions7 fields changed

removedInput schema / properties / band

Removed value: -{
-  "description": "Whether the expected-hold band held all session",
-  "enum": [
-    "held",
-    "broke"
-  ],
-  "type": "string"
-}

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"
+  ]
+}

addedOutput schema / properties / server_version

Added value: +{
+  "description": "Version of the FirmTape MCP server that produced this answer",
+  "type": "string"
+}

removedOutput schema / properties / sessions / items / properties / hold_band_held
```
Removed value: -{
-  "type": [
-    "boolean",
-    "null"
-  ]
-}
```

removedOutput schema / properties / shares / properties / archive / properties / band_held_pct

Removed value: -{
-  "description": "Percent of them whose expected-hold band held all session",
-  "type": [
-    "number",
-    "null"
-  ]
-}

removedOutput schema / properties / shares / properties / matched / properties / band_held_pct

Removed value: -{
-  "description": "Percent of them whose expected-hold band held all session",
-  "type": [
-    "number",
-    "null"
-  ]
-}

changedOutput schema / required

Previous value: -[
-  "summary",
-  "label",
-  "url",
-  "matched",
-  "screened",
-  "archived",
-  "shares",
-  "truncated",
-  "sessions"
-]New value: +[
+  "summary",
+  "label",
+  "url",
+  "matched",
+  "screened",
+  "archived",
+  "shares",
+  "truncated",
+  "sessions",
+  "data_as_of",
+  "server_version"
+]

1 tool updateOct 2, 2026

Changedget_gex_profile1 field changed

changedInput schema / properties / book / description

Previous value: -"Which book to read (default measured). open_interest is the convention rival tools print."New value: +"Which book's ladder to read (default volume, the chart's book). open_interest is the convention rival tools print."

5 tool updatesSep 30, 2026

Changedget_gex_profile7 fields changed

addedInput schema / properties / contract

Added value: +{
+  "description": "Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.",
+  "examples": [
+    "ESZ26",
+    "ESH27"
+  ],
+  "pattern": "^M?(ES|NQ)[FGHJKMNQUVXZ]\\d{1,2}$",
+  "type": "string"
+}

addedInput schema / properties / symbol

Added value: +{
+  "description": "SPX (default), or ES / MES: every strike, spot and level moved by the ES basis at the frame's minute. A day without a measured basis answers with SPX strikes and says so.",
+  "examples": [
+    "SPX",
+    "ES",
+    "MES"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / basis

Added value: +{
+  "description": "Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's",
+  "properties": {
+    "at": {
+      "description": "ET minute the basis belongs to",
+      "type": "string"
+    },
+    "contract": {
+      "description": "The quarterly contract, e.g. ESZ26",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "contracts": {
+      "description": "History only: the contracts the window's sessions were priced as",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "expiry": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "future": {
+      "type": "string"
+    },
+    "index": {
+      "description": "The index whose book was moved: SPX or NDX",
+      "type": "string"
+    },
+    "method": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "passes": {
+      "description": "Basis passes measured that day",
+      "type": "integer"
+    },
+    "points": {
+      "description": "Future minus index, index points, added to every level, strike and spot",
+      "type": "number"
+    },
+    "source": {
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / levels / description

Previous value: -"Dealer-positioning levels in SPX index points; null when the session did not produce one"New value: +"Dealer-positioning levels in SPX index points (in ES points when `symbol` is ES or MES); null when the session did not produce one"

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when a future was asked and its basis is not measured for the day",
+  "type": "string"
+}

addedOutput schema / properties / requested_symbol

Added value: +{
+  "description": "Present when a future was asked but the day has no measured basis, so the answer is SPX's",
+  "type": "string"
+}

addedOutput schema / properties / symbol

Added value: +{
+  "description": "What the prices are in: SPX, or ES / MES when asked and the day's basis is measured",
+  "type": "string"
+}

Changedget_level_history9 fields changed

addedInput schema / properties / contract

Added value: +{
+  "description": "Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.",
+  "examples": [
+    "ESZ26",
+    "ESH27"
+  ],
+  "pattern": "^M?(ES|NQ)[FGHJKMNQUVXZ]\\d{1,2}$",
+  "type": "string"
+}

addedInput schema / properties / symbol

Added value: +{
+  "description": "SPX (default), or ES / MES: each session's levels and close moved by that session's ES basis at its close. Sessions without a measured basis are left out and listed in no_basis; with fewer than two measured, the answer is SPX's and says so.",
+  "examples": [
+    "SPX",
+    "ES",
+    "MES"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / basis

Added value: +{
+  "description": "Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's",
+  "properties": {
+    "at": {
+      "description": "ET minute the basis belongs to",
+      "type": "string"
+    },
+    "contract": {
+      "description": "The quarterly contract, e.g. ESZ26",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "contracts": {
+      "description": "History only: the contracts the window's sessions were priced as",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "expiry": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "future": {
+      "type": "string"
+    },
+    "index": {
+      "description": "The index whose book was moved: SPX or NDX",
+      "type": "string"
+    },
+    "method": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "passes": {
+      "description": "Basis passes measured that day",
+      "type": "integer"
+    },
+    "points": {
+      "description": "Future minus index, index points, added to every level, strike and spot",
+      "type": "number"
+    },
+    "source": {
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / no_basis

Added value: +{
+  "description": "ES only: sessions in the window with no measured basis, left out of the ES series rather than shown at SPX prices",
+  "items": {
+    "description": "Trading day, YYYY-MM-DD",
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when a future was asked and its basis is not measured for the day",
+  "type": "string"
+}

addedOutput schema / properties / requested_symbol

Added value: +{
+  "description": "Present when a future was asked but the day has no measured basis, so the answer is SPX's",
+  "type": "string"
+}

addedOutput schema / properties / sessions / items / properties / basis

Added value: +{
+  "description": "ES only: the session's basis at its close, index points, added to its levels and close",
+  "type": "number"
+}

changedOutput schema / properties / sessions / items / properties / levels / description

Previous value: -"Dealer-positioning levels in SPX index points; null when the session did not produce one"New value: +"Dealer-positioning levels in SPX index points (in ES points when `symbol` is ES or MES); null when the session did not produce one"

addedOutput schema / properties / symbol

Added value: +{
+  "description": "What the prices are in: SPX, or ES / MES when asked and the day's basis is measured",
+  "type": "string"
+}

Changedget_levels7 fields changed

addedInput schema / properties / contract

Added value: +{
+  "description": "Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.",
+  "examples": [
+    "ESZ26",
+    "ESH27"
+  ],
+  "pattern": "^M?(ES|NQ)[FGHJKMNQUVXZ]\\d{1,2}$",
+  "type": "string"
+}

addedInput schema / properties / symbol

Added value: +{
+  "description": "SPX (default), or ES / MES for the E-mini: the SPX book moved by the day's ES basis (future minus index from put-call parity). A day without a measured basis answers with SPX index levels and says so.",
+  "examples": [
+    "SPX",
+    "ES",
+    "MES"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / basis

Added value: +{
+  "description": "Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's",
+  "properties": {
+    "at": {
+      "description": "ET minute the basis belongs to",
+      "type": "string"
+    },
+    "contract": {
+      "description": "The quarterly contract, e.g. ESZ26",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "contracts": {
+      "description": "History only: the contracts the window's sessions were priced as",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "expiry": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "future": {
+      "type": "string"
+    },
+    "index": {
+      "description": "The index whose book was moved: SPX or NDX",
+      "type": "string"
+    },
+    "method": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "passes": {
+      "description": "Basis passes measured that day",
+      "type": "integer"
+    },
+    "points": {
+      "description": "Future minus index, index points, added to every level, strike and spot",
+      "type": "number"
+    },
+    "source": {
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / levels / description

Previous value: -"Dealer-positioning levels in SPX index points; null when the session did not produce one"New value: +"Dealer-positioning levels in SPX index points (in ES points when `symbol` is ES or MES); null when the session did not produce one"

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when a future was asked and its basis is not measured for the day",
+  "type": "string"
+}

addedOutput schema / properties / requested_symbol

Added value: +{
+  "description": "Present when a future was asked but the day has no measured basis, so the answer is SPX's",
+  "type": "string"
+}

addedOutput schema / properties / symbol

Added value: +{
+  "description": "What the prices are in: SPX, or ES / MES when asked and the day's basis is measured",
+  "type": "string"
+}

Changedget_session7 fields changed

addedInput schema / properties / contract

Added value: +{
+  "description": "Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.",
+  "examples": [
+    "ESZ26",
+    "ESH27"
+  ],
+  "pattern": "^M?(ES|NQ)[FGHJKMNQUVXZ]\\d{1,2}$",
+  "type": "string"
+}

addedInput schema / properties / symbol

Added value: +{
+  "description": "SPX (default), or ES / MES for the E-mini: the SPX book moved by the day's ES basis (future minus index from put-call parity). A day without a measured basis answers with SPX index levels and says so.",
+  "examples": [
+    "SPX",
+    "ES",
+    "MES"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / basis

Added value: +{
+  "description": "Present when an ES/MES (or NQ/MNQ) symbol was asked: the futures basis every price here was moved by; null when the day has no measured basis and the answer is the index's",
+  "properties": {
+    "at": {
+      "description": "ET minute the basis belongs to",
+      "type": "string"
+    },
+    "contract": {
+      "description": "The quarterly contract, e.g. ESZ26",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "contracts": {
+      "description": "History only: the contracts the window's sessions were priced as",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "expiry": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "future": {
+      "type": "string"
+    },
+    "index": {
+      "description": "The index whose book was moved: SPX or NDX",
+      "type": "string"
+    },
+    "method": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "passes": {
+      "description": "Basis passes measured that day",
+      "type": "integer"
+    },
+    "points": {
+      "description": "Future minus index, index points, added to every level, strike and spot",
+      "type": "number"
+    },
+    "source": {
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / dealer_positioning / properties / levels / description

Previous value: -"Dealer-positioning levels in SPX index points; null when the session did not produce one"New value: +"Dealer-positioning levels in SPX index points (in ES points when `symbol` is ES or MES); null when the session did not produce one"

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when a future was asked and its basis is not measured for the day",
+  "type": "string"
+}

addedOutput schema / properties / requested_symbol

Added value: +{
+  "description": "Present when a future was asked but the day has no measured basis, so the answer is SPX's",
+  "type": "string"
+}

addedOutput schema / properties / symbol

Added value: +{
+  "description": "What the prices are in: SPX, or ES / MES when asked and the day's basis is measured",
+  "type": "string"
+}

Changedget_symbol_gamma4 fields changed

addedInput schema / properties / contract

Added value: +{
+  "description": "Optional dated contract for a future symbol. Default is the front contract; in the two weeks before a roll the next one is measured too.",
+  "examples": [
+    "ESZ26",
+    "NQH27"
+  ],
+  "pattern": "^M?(ES|NQ)[FGHJKMNQUVXZ]\\d{1,2}$",
+  "type": "string"
+}

changedInput schema / properties / symbol / description

Previous value: -"The ticker. Carried symbols are listed at https://firmtape.com/gex; an unknown ticker returns an error naming that page."New value: +"The ticker, or ES / MES / NQ / MNQ (a dated code such as ESZ26 works too). Carried symbols are listed at https://firmtape.com/gex; an unknown ticker returns an error naming that page."

changedInput schema / properties / symbol / examples

Previous value: -[
-  "QQQ",
-  "NVDA"
-]New value: +[
+  "QQQ",
+  "NVDA",
+  "ES",
+  "NQ"
+]

changedInput schema / properties / symbol / pattern

Previous value: -"^[A-Za-z]{1,5}$"New value: +"^\\$?[A-Za-z]{1,5}(\\d{1,2})?$"

3 tool updatesSep 25, 2026

Changedget_events1 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"

Changedget_market_moving_minutes2 fields changed

addedOutput schema / properties / minutes / items / properties / hold_band

Added value: +{
+  "description": "The expected-hold band at the minute, 'lo / hi': the corridor of spot over which the measured book's gamma stays positive. Not the walls. (Was misnamed `walls` before 0.2.4.)",
+  "type": [
+    "string",
+    "null"
+  ]
+}

removedOutput schema / properties / minutes / items / properties / walls

Removed value: -{
-  "description": "The put and call walls at the minute, 'lo / hi'",
-  "type": [
-    "string",
-    "null"
-  ]
-}

Changedget_session1 field changed

changedOutput schema / properties / events / items / properties / after / description

Previous value: -"spot over the 15 minutes after the event, the flip and the walls before and after, the net gamma sign; only for events inside the session"New value: +"spot over the 15 minutes after the event, the flip and the expected-hold band before and after, the net gamma sign; only for events inside the session"

1 tool updateSep 18, 2026
- Addedget_symbol_gamma
1 tool updateSep 15, 2026
- Addedscreen_sessions

1 tool updateSep 11, 2026

Changedget_market_moving_minutes1 field changed

addedOutput schema / properties / minutes / items / properties / usually

Added value: +{
+  "description": "What usually followed this class of minute across every session measured: count, median 15-minute move, share that continued the 5-minute move",
+  "type": "string"
+}

1 tool updateSep 11, 2026
- Addedget_market_moving_minutes

1 tool updateSep 4, 2026

Changedget_session1 field changed

addedOutput schema / properties / events

Added value: +{
+  "description": "The day's scheduled market events (high and medium impact), each with its minute in ET, its source, the release's prints when known, and, for an event inside the session, what the book did in the 15 minutes after it",
+  "items": {
+    "properties": {
+      "after": {
+        "description": "spot over the 15 minutes after the event, the flip and the walls before and after, the net gamma sign; only for events inside the session",
+        "type": "string"
+      },
+      "impact": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "prints": {
+        "items": {
+          "properties": {
+            "actual": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "forecast": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "label": {
+              "type": "string"
+            },
+            "prior": {
+              "type": [
+                "string",
+                "null"
+              ]
+            }
+          },
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "time": {
+        "description": "HH:MM ET; empty for an all-day item",
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "time",
+      "name",
+      "impact"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

1 tool updateSep 4, 2026

Changedget_events2 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"
+}

1 tool updateSep 3, 2026
- Addedget_events
8 tool updatesSep 1, 2026
- First observedfetch
- First observedget_gex_profile
- First observedget_level_history
- First observedget_levels
- First observedget_session
- First observedlist_sessions
- First observedoptions_strategy_test
- First observedsearch

Related MCP Connectors

flashalpha A
io.github.tdobrowolski1
Real-time & historical options analytics: GEX, dealer positioning, vol, VRP, 0DTE, CME futures
Finance Search Research & Data
21
Nightwatch
com.yehangshe
Dealer gamma exposure (GEX) levels and dealer positioning heatmaps for US equity options.
Finance Data Visualization
1
zdte.ai SPX Market Structure A
ai.zdte
SPX 0DTE dealer market structure: GEX, walls, gamma flip, regime, flow. Free preview; pay per read.
Finance Data Platforms
131
Sharpnel Trading — Dealer Gamma Levels A
com.sharpnel-trading
Free dealer-gamma call walls, put walls and gamma flip for ES, NQ, SPX and QQQ, graded daily.
Finance Research & Data
51

Related MCP Servers

traders-edge-mcp
Finance Research & Data
jsconiers
A
license
Not graded
quality
B
maintenance
Provides a consolidated 0DTE options cockpit for SPX/SPXW, including chain, Greeks, dealer exposure, volatility term structure, and economic events, using free delayed market data.
Updated 14 days ago (2026-09-29 13:33 UTC)
2
MIT
QuantData MCP Server
Finance Search AI & Machine Learning
zzulanas
A
license
Not graded
quality
F
maintenance
Provides AI agents with access to real-time and historical SPX 0DTE options market data from QuantData. It enables analysis of market indicators like gamma exposure walls, net drift, max pain, and trade side statistics through natural language.
Updated 5 months ago (2026-05-09 19:05 UTC)
9
MIT
agent-gamma (AgentGamma)
Blockchain Finance
Longfortv5
F
license
Not graded
quality
D
maintenance
Here is a brief description of what our MCP server does: Description Project Tollbooth is a real-time market microstructure and options analytics gateway. It exposes quantitative Gamma Verdicts (hedging effects, dealer exposure aggregates, and volatility regimes) and 0DTE Verdicts (real-time pinning magnets, pin scores, and target probabilities) for major instruments (\*\*SPX,
Updated 4 months ago (2026-06-12 20:14 UTC)
-
options-analysis
Finance Research & Data
mrsoto
A
license
B
quality
C
maintenance
Enables querying options chains and estimating gamma exposure for ETFs and liquid underlyings, including proxy gamma calculations and historical gamma snapshots.
Updated a month ago (2026-09-05 17:30 UTC)
9
GPL 3.0

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?