FirmTape - SPX dealer positioning

Level history

get_level_history

Read-onlyIdempotent

How the SPX dealer-positioning levels MOVED across recent finished sessions: the zero-gamma flip, call resistance and put support 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). 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.

Input Schema

TableJSON 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`.

Output Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Trading day, YYYY-MM-DD
`from`	Yes	Trading day, YYYY-MM-DD
`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.
`sessions`	Yes	One entry per finished session, NEWEST FIRST, same order as list_sessions

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), and the description adds genuinely useful behavioral context beyond them: finished-sessions-only scope, hard 40-call limit, missing archive days reported in `missing` rather than interpolated, and the explicit boundary that it provides measurements only — no signals or forecasts. No contradiction with annotations.

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?

Dense but well-organized: the core function is front-loaded, followed by labeled sections ('Use when', 'Not for', 'Limits') that make the routing logic scannable for an agent. Every sentence earns its place, including the summary-statistics inventory and the 'no forecast' disclaimer.

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?

Complete for a read-only windowed-historical tool. The output schema covers return values; the description summarizes what the output contains (flip range, net drift, mean daily movement, close-above-flip frequency) and names the `missing` field. Nothing an agent needs to decide or invoke 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%, so the baseline is 3 — each parameter already has defaults, constraints, examples, and precedence semantics ('from overrides days'). The description adds only marginal context (finished-sessions scope reinforced, max 40 restated) but does not materially compensate beyond what the schema already documents.

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 states a specific verb+resource+scope: how SPX dealer-positioning levels (zero-gamma flip, call resistance, put support) MOVED across finished sessions, including per-session deltas and window summary statistics. It explicitly names the siblings it is not (get_levels, get_session, get_gex_profile), so an agent can distinguish it from alternatives without inspecting their schemas.

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' conditions (trend/window questions like 'has the flip been climbing') and explicit 'Not for' exclusions (single day → get_levels/get_session; intra-session → get_gex_profile). This gives the agent a complete routing decision tree for when this tool beats calling get_levels repeatedly.

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

All FirmTape - SPX dealer positioning tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Every tool targets a distinct resource and granularity: documents (search/fetch), session enumeration (list_sessions), day-level measurements (get_session/get_levels), intraday shape (get_gex_profile), multi-day trends (get_level_history), and strategy backtesting (options_strategy_test). The descriptions go further than usual, using explicit 'Not for' cross-references so even get_levels vs get_session — a deliberate strict subset — reads unambiguously.

Naming Consistency4/5

The measurement tools follow a clean get_<nouon> convention (get_session, get_levels, get_level_history, get_gex_profile) and list_sessions fits the verb_nouon pattern. fetch and search are bare single-word verbs that break the pattern slightly — fetch_document / search_documents would be more uniform — and options_strategy_test is a compressed compound, but the overall snake_case style and semantic grouping are predictable.

Tool Count5/5

Eight tools is well within the 3-15 sweet spot for a specialized data server. Each tool carries a clearly differentiated job: two document access, one enumeration, four measurement surfaces (single-day full, single-day levels, intraday ladder, multi-day history), and one analysis operation. Nothing feels like filler and nothing essential is missing.

Completeness4/5

The domain is well covered: session discovery (list_sessions), document retrieval (search/fetch), full daily readings (get_session), subset views (get_levels), intraday gamma shape (get_gex_profile), and cross-day movement (get_level_history) — plus a strategy tester. Minor gaps exist, such as no way to compare gamma-ladder shape across multiple days without repeated get_gex_profile calls, but no workflow dead-ends for the stated purpose.

Resources

Need Help?