Insights

Point-in-Time Market Data Through MCP

Alphanume Team · August 16, 2026

Point-in-time market data through MCP lets an agent query what a research universe looked like on a past observation date, as long as the prompt fixes that date and preserves the returned records.

The direct answer is simple: a point-in-time MCP workflow should start with a dated universe, save the exact tool arguments, and attach outcomes only after membership is frozen. Alphanume's hosted MCP server exposes the same deterministic API data as REST through 25 read-only tools. That gives an agent a convenient way to discover and combine datasets without turning the agent's narrative into the source of truth.

This matters whenever today's ticker list differs from the set available on the day being studied. An answer-only finance assistant can tell you which stocks have options now. A backtest for 2023 needs the optionable snapshot that existed in each month of 2023. The gap between those two questions is where survivorship bias enters quietly.

Freeze the universe first

Research input	As-of field	Leak to avoid
Optionable Tickers	date plus ticker	Using the current optionable list for a historical month
Historical Market Cap	date, ticker, market_cap, shares_outstanding	Rebuilding old market cap with today's shares outstanding
Ticker Classification	retrieval timestamp	Presenting a current taxonomy as a historical one
Forward outcome	outcome window after the observation date	Filtering membership with information learned later

Historical Optionable Tickers stores a snapshot on the first trading day of each month. Its rows include date, ticker, avg_days_between, and has_weeklies. Historical Market Cap stores dated market capitalization and shares outstanding. Both are inputs to a universe decision, while future returns belong in a later step.

The earlier point-in-time market cap explainer covers the share-count problem in detail. MCP changes how the tools are called, while the underlying observation contract remains the same.

Inspect with MCP, extract with REST

A useful prompt names the dataset, the full historical interval, the required fields, and the stopping rule. Asking MCP to return every 2023 snapshot is not reliable because the assistant-facing data array is capped at 500 rows. Use MCP to inspect one snapshot and produce a fixed REST handoff, then inspect the distinct dates returned by the completed REST extraction instead of inventing month-end dates.

Use only the Alphanume get_optionable_tickers tool for inspection.

1. Query one known 2023 snapshot with equal date_gte and date_lte bounds.
2. Report has_more, next_cursor, and truncated_to_max_rows.
3. Preserve date, ticker, avg_days_between, and has_weeklies.
4. If truncated_to_max_rows is present, stop and label the result incomplete regardless of has_more.
5. Write the equivalent REST request and cursor loop for date_gte="2023-01-01" and date_lte="2023-12-31".
6. Require the REST job to group by returned date and report the row count for every snapshot.
7. Save unmatched or missing months separately and never replace a missing historical row with a current ticker.

The tool returns at most 500 data rows. A truncated_to_max_rows field means MCP discarded rows after receiving the REST response envelope. It does not mean the historical dataset ends there, and inherited has_more or cursor values do not recover the discarded portion. The complete year must be paginated directly through REST.

Keep an as-of ledger

I treat the agent transcript as a research note and the ledger as the reproducibility record. The ledger carries facts that a later run can compare directly: connection, tool, arguments, tier, returned dates, cursor state, row count, and a digest of the saved rows. An eloquent summary cannot substitute for those fields.

Ledger field	Example	Reason
tool	get_optionable_tickers	Fixes which contract supplied the rows
requested_window	2023-01-01 through 2023-12-31	Makes the historical cutoff explicit
observed_dates	Distinct dates from the response	Uses source snapshots rather than assumed dates
rest_cursor_complete	true	Shows whether all REST pages were collected
row_digest	Hash of normalized JSON	Detects a changed local artifact

The Hosted Alphanume MCP server documentation lists the connection methods and shared response behavior. Supported clients can use browser OAuth at the hosted endpoint. API-key clients should keep credentials outside prompts and committed configuration. The server still enforces the account's access tier.

Point-in-time still has failure modes

Monthly resolution. Optionability can change between snapshots, so the data cannot prove that a contract existed on every intervening session.
Identifier continuity. A ticker change, merger, or reorganization can break a join that treats the symbol as a permanent company identifier.
Coverage gaps. A missing market-cap row means missing coverage or a date mismatch, not a zero-dollar company.
Current metadata. Ticker Classification has no historical date dimension, so record when that mapping was retrieved.
Agent variability. MCP does not independently validate a strategy, select a correct cutoff, or guarantee a profitable result.

Free access covers a trailing 20-trading-session window delayed by one trading session. A 2023 pull therefore requires historical access. Check the pricing and access page before treating a restricted response as missing data.

Run one month before the year

Start with one MCP-inspected 2023 snapshot, fail if it is capped, and execute the generated REST pull for that snapshot. Save every raw REST page, cursor record, and universe count, then join dated market cap on date plus ticker. Export matched and unmatched names separately. Once that slice reproduces, expand the REST procedure to the full year and attach forward returns in a new table rather than modifying the frozen cohort.

That is the practical advantage of point-in-time market data through MCP: the agent helps assemble a dated query, while the dates, fields, pages, and saved artifacts keep the research honest.