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

Similar days

similar_days

Read-onlyIdempotent

Find the finished SPX sessions whose state at the same time of day was nearest to one moment, and what the rest of each of those days did. The state is eight volume-book measurements: distance from the zero-gamma flip, move since the open, distance from the session mean, net-gamma percentile, 0DTE ATM IV and its change since the open, the range so far, and the time spent above the flip. Returns the nearest days (one moment each, with a replay link), their shares (rest of day up, mean move to the close, closed above the flip) and the SAME shares over every archived moment in the same quarter-hours: a matched share close to the archive's is a base rate, not a pattern. Use when: 'what happened on days like this', 'days that looked like 2026-10-14 at 11:00'. Not for: filtering by named conditions such as FOMC or a percentile band (screen_sessions), or testing a rule out of sample (the Lab). Limits: finished sessions from 09:45 to 15:30 ET, SPX only. Similar on these eight numbers and nothing else; history, not a forecast and not investment advice.

Input Schema

Name	Required	Description
`k`	No	How many similar days to return (default 15)
`day`	Yes	The trading day of the moment, YYYY-MM-DD
`lanes`	No	Only for a session still running, which the archive does not hold yet: the day's minute series from 09:30, one entry per minute (volume-book flip and percentile). FirmTape's own terminal sends these.
`minute`	No	The ET minute, HH:MM; default the last minute with a full state (the close for a finished day)

Output Schema

Name	Required	Description
`day`	Yes
`days`	Yes
`state`	Yes	The moment's eight measurements
`minute`	Yes
`window`	No	The time of day compared
`archive`	Yes	The same shares over every archived moment in the same quarter-hours; n counts days
`matched`	Yes
`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.
`features`	No	What each measurement is
`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

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnly/idempotent/non-destructive, and the description adds substantive context beyond them: what is being matched (eight named measurements), the base-rate caveat about the archive comparison, that similarity is on these eight numbers only, and the history-not-forecast disclaimer. 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.

Conciseness4/5

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

Front-loads purpose, then use/not-for, then limits and disclaimers — a sensible order. The enumeration of eight measurements is dense but justifies itself for matching semantics; a few clauses (advice disclaimer, replay link) could be trimmed.

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 annotations and an output schema already covering safety and return shape, the description still delivers purpose, sibling routing, hard limits, the base-rate interpretation caveat, and the similarity basis. Nothing an agent needs to call it correctly appears 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 description coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: it names the eight state measurements that the unlabeled lanes arrays (flip, vwap, gpct, etc.) encode, and clarifies the moment-of-day matching semantics behind day/minute.

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: find finished SPX sessions whose eight-measurement state at the same time of day was nearest a given moment, plus what those days did afterwards. It enumerates the state vector and distinguishes itself from screen_sessions and the Lab by name.

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' examples ('what happened on days like this', 'days that looked like 2026-10-14 at 11:00') and explicit 'Not for' routing to screen_sessions (named conditions) and the Lab (out-of-sample testing). Limits (finished sessions 09:45–15:30 ET, SPX only) further bound usage.

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

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

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?