Stock Market MCP Server With Point-in-Time Data

A stock market MCP server needs observation-time contracts, not only current quotes, when an agent is building a historical universe or evaluating a strategy.

A stock market MCP server with point-in-time data lets an agent ask what was knowable on a historical date. For example, it can retrieve market cap and shares outstanding recorded for June 28, 2024, then intersect those rows with the optionable universe available at that time. A server that exposes only today's company snapshot cannot answer that backtest question without leaking later information.

Alphanume exposes 25 tools through MCP, including historical market cap, its ticker coverage map, historical optionable tickers, event datasets, volatility measures, and market signals. The MCP layer returns the same API records as REST. It helps the agent discover and call the right tool, but the researcher remains responsible for the cutoff time, joins, missing coverage, and forward-return measurement.

Define point-in-time before asking for data

A row with date, ticker, market_cap, and shares_outstanding is a dated observation. It is not a restatement of every past date using the newest share count. The earlier point-in-time market cap explainer covers why this matters at the field level. The MCP workflow must carry the same rule into universe construction.

Ask for a fixed historical universe

Fix a decision date and require the model to retain each source date. Historical Market Cap supports one market-wide date and keyset pagination. Optionable Tickers supplies monthly snapshots through date ranges, so a June 28 decision should select the latest returned snapshot on or before June 28 rather than demand a nonexistent daily row. MCP may cut either wide result to 500 rows after receiving the REST envelope, so the agent must stop when it sees truncated_to_max_rows and hand the complete extraction to REST.

Use Alphanume MCP tools to build a historical universe for 2024-06-28.

1. Call get_historical_market_cap with date="2024-06-28".
2. Call get_optionable_tickers with date_gte="2024-06-01"
   and date_lte="2024-06-28", then select the latest returned snapshot.
3. Report truncated_to_max_rows, has_more, and next_cursor for both calls.
4. If truncated_to_max_rows appears, stop and label the MCP cohort incomplete regardless of has_more. Write REST requests and cursor loops for both complete pulls.
5. Only after the REST pulls are complete, join on ticker and retain market_cap_date="2024-06-28" plus the separate option_snapshot_date.
6. Keep rows with market_cap from 500000000 through 5000000000.
7. Return market_cap_date, option_snapshot_date, ticker, market_cap, shares_outstanding,
   avg_days_between, and has_weeklies.
8. Report unmatched tickers and first-available coverage separately.
9. Do not attach returns or call the cohort a strategy.

The instruction to save unmatched names is important. A missing row can mean no source coverage, no optionable snapshot, a ticker transition, or an incorrect date assumption. It does not mean market cap was zero. It also must not be inferred from a capped MCP table. Complete both REST inputs first, then use list_market_cap_tickers to distinguish a never-covered symbol from a symbol whose history begins later.

Move the validated call into code

The Hosted MCP documentation explains connection and shared response conventions. After the agent returns a correct cohort, record the tool arguments and implement the same query through REST. This removes tool-selection variability from a scheduled backfill while leaving the data contract unchanged.

import os
import requests

session = requests.Session()
session.headers["X-API-Key"] = os.environ["ALPHANUME_API_KEY"]

params = {"date": "2024-06-28"}
rows = []
while True:
    response = session.get(
        "https://api.alphanume.com/v1/historical-market-cap",
        params=params,
        timeout=30,
    )
    response.raise_for_status()
    payload = response.json()
    rows.extend(payload["data"])
    if not payload.get("has_more"):
        break
    cursor = payload["next_cursor"]
    params.update({
        "cursor_date": cursor["date"],
        "cursor_ticker": cursor["ticker"],
    })

assert all(row["date"] == "2024-06-28" for row in rows)

Historical Market Cap requires a ticker or a date filter, and a market-wide date range is capped at seven calendar days. One exact date is therefore the cleanest starting point. Keep the raw response for every page, not only the final filtered frame, so a later audit can distinguish source data from screening logic.

Know what point-in-time does not solve

• Dated market cap does not repair a price series with incorrect corporate-action adjustments.
• Historical optionability does not supply option quotes, spreads, borrow, or execution costs.
• Ticker identifiers can change, so a symbol alone may not provide entity continuity through mergers or reorganizations.
• The current ticker-classification tool has no date dimension and must be documented as a current mapping if used.
• An agent can still leak future data by choosing the wrong date or filling a missing row from a later observation.

Free access exposes a trailing 20-session delayed window, which is sufficient for checking the mechanics but not for a 2024 universe. Confirm the historical tier on the pricing page. Then save the raw market-cap pages, raw optionability pages, unmatched-symbol report, and final cohort for one date. Only after those four artifacts reproduce should the workflow attach next-period returns.