Using an MCP Server for Backtesting Research

Use MCP to inspect datasets and form a falsifiable backtest plan, then move the accepted query into deterministic code that freezes cohorts, pagination, and outcomes.

An MCP server can improve backtesting research when it is used for discovery, schema inspection, and hypothesis formation. It should not be the unrecorded loop that changes filters until a result looks attractive. Alphanume's hosted MCP server exposes the same deterministic point-in-time data as REST through 25 read-only tools. The model chooses calls and explains fields, while the underlying values remain API records.

The clean division of labor is simple: let the agent help define a research contract, use MCP to test a narrow query, save the tool arguments and response, then execute the full backtest in versioned code. That boundary preserves the speed of conversational exploration without making an agent's unstated choices part of the result.

Separate discovery from execution

The Hosted Alphanume MCP documentation defines authentication, tools, and response conventions. Each data tool accepts max_rows, defaulting to 500 at the MCP layer. A truncated_to_max_rows marker means the assistant-facing payload was capped, not that the API has no additional rows.

Form a leak-safe dilution hypothesis

Consider the hypothesis that first-known S-1 dilution filings have different forward returns among smaller issuers. The event date must come from the filing record, the size filter must use market_cap_at_filing or a separately matched as-of value, and outcomes must begin only after the filing became public. Effectiveness and withdrawal are later lifecycle facts, not inputs known at the initial filing.

Use only Alphanume MCP tools.

Design a backtest plan for S-1 dilution events.
1. Inspect get_dilution_filings and get_historical_market_cap.
2. Define the event timestamp, cohort keys, size field, inclusion rules,
   exclusion report, and 1, 5, and 20 session forward-return windows.
3. State which lifecycle fields arrive after the original filing.
4. Propose one narrow date-range pilot call for each tool.
5. Return exact tool arguments and preserve null values.
6. Do not run repeated variants or claim the hypothesis is validated.

The prompt asks for a plan and pilot, not a favorable result. Require a single primary specification before looking at returns. If the agent proposes several thresholds, record them as exploratory variants and reserve a later period for confirmation rather than choosing the best one in sample.

Record the research contract

The pilot should produce a compact manifest that can be translated into code. It needs the source tool, filters, point-in-time cutoff, cohort key, missing-data policy, and outcomes. Store the manifest beside the raw response.

{
  "hypothesis": "S-1 first disclosures differ by issuer size",
  "event_source": "get_dilution_filings",
  "event_key": "accession_number",
  "event_time": "filing_timestamp",
  "size_field": "market_cap_at_filing",
  "future_lifecycle_fields": [
    "became_effective",
    "effective_date",
    "offering_withdrawn",
    "withdrawal_date"
  ],
  "null_policy": "preserve and report",
  "outcome_windows_sessions": [1, 5, 20]
}

This manifest is not sufficient by itself. Add the data retrieval timestamp, tier, raw-response hashes, price source, corporate-action adjustment policy, trading-calendar rule, and transaction-cost assumption when the code implementation begins.

Translate accepted calls into fixed REST code

MCP tool names map to REST endpoints, but the code should implement explicit request parameters and validation rather than replay natural language. For the dilution event backfill, call GET /v1/dilution over a fixed date window, require the expected fields, save raw JSON, and only then build the cohort. Join outcomes after membership is frozen.

import os
import requests

params = {"date_gte": "2026-01-01", "date_lte": "2026-03-31"}
response = requests.get(
    "https://api.alphanume.com/v1/dilution",
    headers={"X-API-Key": os.environ["ALPHANUME_API_KEY"]},
    params=params,
    timeout=30,
)
response.raise_for_status()
events = response.json()["data"]

required = {"date", "filing_timestamp", "accession_number", "filing_url"}
assert all(required.issubset(row) for row in events)

The implementation should fail loudly on an authentication error, tier restriction, missing field, incomplete page, or changed row count outside a documented tolerance. It should not ask an agent to repair the cohort silently.

Know what MCP does not validate

• An agent can choose the wrong tool, date, or join unless the prompt requires an audit trail.
• Point-in-time event data does not repair survivorship bias in a separate price source.
• A registration filing creates possible supply and does not prove issuance or a negative return.
• Testing many thresholds and reporting only the best one is still data mining when an agent proposes the variants.
• MCP connectivity and deterministic data do not guarantee a profitable or statistically valid strategy.

Free access provides the trailing 20 trading sessions after a one-trading-session delay. Use that coverage to verify mechanics, not to support a long-horizon claim. The access reference states the available history and limits.

Run one pilot and lock the specification

Connect the server, run the plan prompt once, and save the tool schemas, arguments, raw responses, manifest, and exclusions. Convert that exact pilot into code and compare normalized MCP and REST rows field by field. When parity passes, lock the hypothesis and outcome windows before expanding history. The honest backtest checklist is the next review step after the data pipeline reproduces.