Idea
Give an LLM live access to the streaming feed without piping it the raw firehose, using the materialized-view-over-a-stream pattern: the stream runs continuously while the model cherry-picks the current state on demand.
How it works
A background subscription keeps a queryable live state per watched contract, updated O(1) as each tick lands. The model does point-in-time pull queries against that pre-computed state and gets an answer in milliseconds, no matter how much data flowed. The stream is the river; the pull query is the cherry-pick. Prior art: ksqlDB pull queries over materialized views, Tinybird's MCP server, RisingWave stateful stream processing.
Bundle into the existing MCP, not a separate server
These are just more tools on thetadatadx-mcp: same package, same npx -y thetadatadx-mcp install, same credentials and contract identity. The server becomes a stateful long-lived process holding a background streaming subscription alongside the historical query tools. No second server, no second install.
Caveat: streaming uses the account's single FPSS session, so watch must be opt-in and the operator should know it consumes that session.
Tool scope — raw primitives only, no pre-built analytics
Expose raw live state plus the minimum commodity shaping so the model gets a summary instead of a firehose:
watch(contract) — start maintaining live state for a contract.latest(contract) — the latest tick.bars(contract, interval) — downsampled OHLCV (commodity aggregation; the minimum that avoids flooding the model).window(contract, seconds) — the raw ticks in a bounded window, for callers that compute their own shaping.
Explicitly NOT pre-built here: VWAP, order-flow imbalance, VPIN, Lee-Ready, Greeks, or any derived signal. Those are the valuable analytics and stay in the analytics layer (Kairos) or the caller's own code. The data plane serves raw live state; the signals are the moat and are not given away in the free MCP.
Open design question
Where exactly is the line? latest and the raw window are unambiguously raw. bars (OHLCV) is borderline — basic, but still an aggregation. Decide whether even OHLCV bars belong here, or whether the MCP ships only latest + raw window and the caller does all shaping. The tradeoff: more shaping in the MCP is friendlier to the model but creeps toward giving away analytics.
Idea
Give an LLM live access to the streaming feed without piping it the raw firehose, using the materialized-view-over-a-stream pattern: the stream runs continuously while the model cherry-picks the current state on demand.
How it works
A background subscription keeps a queryable live state per watched contract, updated O(1) as each tick lands. The model does point-in-time pull queries against that pre-computed state and gets an answer in milliseconds, no matter how much data flowed. The stream is the river; the pull query is the cherry-pick. Prior art: ksqlDB pull queries over materialized views, Tinybird's MCP server, RisingWave stateful stream processing.
Bundle into the existing MCP, not a separate server
These are just more tools on
thetadatadx-mcp: same package, samenpx -y thetadatadx-mcpinstall, same credentials and contract identity. The server becomes a stateful long-lived process holding a background streaming subscription alongside the historical query tools. No second server, no second install.Caveat: streaming uses the account's single FPSS session, so
watchmust be opt-in and the operator should know it consumes that session.Tool scope — raw primitives only, no pre-built analytics
Expose raw live state plus the minimum commodity shaping so the model gets a summary instead of a firehose:
watch(contract)— start maintaining live state for a contract.latest(contract)— the latest tick.bars(contract, interval)— downsampled OHLCV (commodity aggregation; the minimum that avoids flooding the model).window(contract, seconds)— the raw ticks in a bounded window, for callers that compute their own shaping.Explicitly NOT pre-built here: VWAP, order-flow imbalance, VPIN, Lee-Ready, Greeks, or any derived signal. Those are the valuable analytics and stay in the analytics layer (Kairos) or the caller's own code. The data plane serves raw live state; the signals are the moat and are not given away in the free MCP.
Open design question
Where exactly is the line?
latestand the rawwindoware unambiguously raw.bars(OHLCV) is borderline — basic, but still an aggregation. Decide whether even OHLCV bars belong here, or whether the MCP ships onlylatest+ rawwindowand the caller does all shaping. The tradeoff: more shaping in the MCP is friendlier to the model but creeps toward giving away analytics.