FirmTape - SPX dealer positioning, 100+ symbols

Minutes that moved the tape

get_market_moving_minutes

Read-onlyIdempotent

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 and walls 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.

Input Schema

TableJSON 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 11, 2026

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

AddedSep 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare the safe read-only/idempotent profile, so the description correctly focuses on non-obvious traits: the live day is excluded (it sits behind the paid live stream), coverage starts 2022-04, and timestamps are ET. It also discloses what a null headline means rather than leaving it ambiguous. No rate-limit or pagination behavior is mentioned, keeping it 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.

Conciseness4/5

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

Front-loads the payload, then usage, then limits in a clear order. Some phrasing is expository rather than functional ('the honest reading that no headline existed and the dealer book moved on its own'), which costs a little density but does explain an ambiguous output case.

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 description is not required, yet the description still summarizes the per-minute fields. Combined with the explicit data-availability window, clock, and default session, 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%, so the default baseline applies. The description reinforces the meaning of the tape filter (minutes 'the tape itself marked as market-moving' vs. headline-less moves), which loosely illuminates tape_only, but adds no syntax or format detail beyond the schema.

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 resource — the minutes of one finished SPX session that the tape flagged as market-moving — along with the payload each minute carries (scheduled event, news-desk cluster timing, index move over 5/15 min, flip and walls). It explicitly distinguishes itself from get_events and get_levels by name, so an agent can route 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?

Gives concrete 'Use when' exemplars ('what moved SPX at 14:25 on 2026-09-10', 'were there news-driven minutes yesterday') plus a 'Not for' clause naming the two alternatives (get_events, get_levels). Hard constraints (finished sessions only, data from 2022-04, ET clock) are stated outright.

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, 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?