Signal8 MCP Server

Official

by signal8ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Get RVOL History

get_rvol_history

Read-only

Retrieve per-day relative-volume (RVOL) series for any ticker by session, comparing each session's volume to its own trailing baseline to spot unusual volume surges.

Instructions

Get the per-day relative-volume (RVOL) time series for a ticker, bucketed by trading session (premarket 04:00–09:30 ET, regular 09:30–16:00, afterhours 16:00–20:00, or all four). Each day's RVOL compares that session's volume to a trailing same-session baseline (30 trading days by default — configurable via "baselineDays"), so premarket volume is judged against premarket history (not a stale full-day figure). Use for spotting unusual premarket / session volume surges over the last N days. Each point also carries "baselineState" — "ready" (rvol is populated), "warming" (baseline not yet warm), "no-cutoff-history" (established ticker that never traded at this session/cutoff before) or "no-history" (new listing, no prior trading history at all) — so a null rvol is explained rather than silent. Points additionally carry "advRatio" (that day's volume ÷ the trailing 30-session average FULL-DAY volume, null when no full-day denominator exists) and "advDays" (its sample size), which give a magnitude to points RVOL cannot rate. advRatio is NOT an RVOL — it compares a partial session to a whole day, so it is typically well under 1 and must not be compared to rvol. Charged per your API tier.

Input Schema

TableJSON Schema

Name	Required	Description
`days`	No	Number of trailing calendar days of history (1–90, default 30).
`ticker`	Yes	Stock ticker symbol (e.g., "AAPL", "TSLA")
`session`	No	Restrict to one session bucket; omit to return all four sessions.
`asOfTime`	No	Optional TRUE time-of-day premarket basis. Any HH:MM ET premarket time; snapped to the nearest 15-minute grid cutoff (04:00–09:15, ties resolve to the earlier cutoff). When set, the series is the PREMARKET as-of RVOL: cumulative volume known BY that cutoff ÷ the trailing baselineDays (default 30) average of the SAME cutoff (not the full 04:00–09:30 session). Forces the premarket session — any "session" argument is ignored. Each point carries a "basis" field: the snapped cutoff actually used ("asof-0700"), or "full-session" for dates with no precomputed as-of row. Omit for the standard full-session series.
`baselineDays`	No	Rolling RVOL baseline window, in trading rows (same-session days). Default 30; values outside 20-250 are clamped. This is the DENOMINATOR window: every RVOL in the response is that period's volume divided by the average of the trailing N same-session (or same-cutoff) days, excluding the day itself. A SHORTER window tracks recent regime changes faster and is noisier; a LONGER one is smoother and slower to react. The warm-up lookback scales with it automatically, so a wide window is never under-filled into an inflated ratio; the minimum-warm-days gate (20 prior sessions) does NOT scale down, so at the 30-row default a ticker needs 20 of its last 30 sessions populated before rvol is non-null. Omit for the standard 30-day baseline; pass 90 for the pre-2026-09 window.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.2Sep 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark it read-only, but the description adds substantial behavioral detail: how RVOL is computed, the baselineState values that explain nulls, the warning that advRatio is NOT an RVOL and must not be compared to rvol, the asOfTime cutoff snapping and its effect on session, and the baselineDays warm-up behavior. This far exceeds the annotation and gives an agent complete understanding of what the output means and how calls behave.

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 long but every sentence adds functional value. It front-loads the core purpose, then explains state fields and parameter nuances. There is minimal redundancy; the only slight criticism is that it could be tightened, but given the tool's complexity, the length is justified.

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?

The description fully explains all parameters, the output's state fields, the meaning of advRatio, and the asOfTime edge cases. With a rich output schema also present, an agent has everything needed to call the tool correctly and interpret results without guessing. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds significant extra meaning for every parameter. For asOfTime it explains the snapping grid, the 'basis' field, and that it forces premarket. For baselineDays it explains clamping, the denominator window, warm-up scaling, and the minimum-warm-days gate. For session it clarifies that asOfTime overrides it. The description compensates richly beyond 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?

The description clearly states the tool returns a per-day relative-volume (RVOL) time series for a ticker, bucketed by trading session. It uses a specific verb and resource, and explicitly lists the session buckets and the key purpose ('spotting unusual premarket / session volume surges'). It distinguishes this tool from generic price or volume tools by the RVOL and session-bucketing concept.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use case ('Use for spotting unusual premarket / session volume surges over the last N days.') and explains the rolling baseline and session-specific comparison. It does not explicitly name alternatives or say when not to use it, but for this niche tool the guidance is strong enough for an agent to decide when it is appropriate.

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

Deploy Server