Insights

What a Quantitative Trading MCP Server Should Return

Alphanume Team · August 16, 2026

A quantitative trading MCP server should return dated rows, explicit field meanings, stable filters, pagination state, nulls, source caveats, and enough execution detail to reproduce the call.

That is the direct standard. A tool response becomes useful for backtesting when a researcher can tell what was known, when it was known, what remains missing, and whether the response is complete. A ticker and a confident paragraph are not a data contract.

Alphanume's hosted MCP server exposes 25 tools backed by the same deterministic point-in-time data as its REST API. MCP lets a compatible client discover a tool and its input schema, then lets a model choose arguments. The returned dataset remains structured JSON. The model's selection and interpretation are separate steps that require their own audit record.

Seven things the response needs

Contract element	What to preserve	Failure it prevents
Observation key	date and ticker, plus dataset-specific identifiers	Joining unrelated rows
Clock definition	Selection time, filing time, or publication rule	Lookahead from an ambiguous date
Typed fields	Numbers, booleans, strings, and nulls	Parsing display text as data
Filters	Exact tool arguments	A later rerun silently changing the cohort
Completeness	count, has_more, next_cursor, truncation flag	Treating one response as the whole dataset
Access state	Tier and restricted-range errors	Calling unavailable history an empty sample
Caveats	Outcome timing and dataset limitations	Presenting a screen as validated performance

The official MCP tools specification defines tools as server capabilities with schemas that clients can discover and invoke. That protocol boundary is useful, but it cannot supply dataset semantics by itself. The server has to explain what each field and timestamp means.

Next-Day Movers makes the timing visible

Next-Day Movers is a clean test of the contract because its input and outcome live on different clocks. New selections are generated daily at 3:30 PM America/New_York. Each row has date, ticker, return, and absolute_move. The last two fields measure the following trading session, so they remain null until that session has completed and are populated afterward.

Field	Observation-time rule	Backtest treatment
date	Day the name entered the model-ranked list	Use as the selection date
ticker	Security symbol on that record	Retain even if later inactive
return	Signed following-session return	Outcome only, never a selection filter
absolute_move	Unsigned following-session move	Score after the next session closes

A current row with null outcomes is incomplete by design, not malformed. A historical row with populated outcomes can score the selection, but the research process should retain the original pre-outcome snapshot. Otherwise the presence of a filled outcome can accidentally become a filter on which observations survive.

Ask the tool to state its contract

Use the Alphanume get_next_day_movers tool for 2026-08-03.

Before interpreting any row, return:
1. The exact tool name and arguments.
2. The response fields and their types.
3. The observation-time meaning of date.
4. When return and absolute_move become knowable.
5. Whether null outcomes were preserved.
6. The response count and any truncation marker.
7. A machine-readable table with no inferred fields.

Label the output a model-ranked research cohort, not a trade recommendation.

This prompt forces the timing rule into the result instead of leaving it in documentation that may never reach the analysis. The MCP documentation describes the common response conventions, while the individual dataset reference defines its fields. Both are needed.

Pagination and caps are different

Every Alphanume data tool accepts max_rows, which defaults to 500 at the MCP layer. If that cap shortens a response, the proxy adds truncated_to_max_rows. Some underlying REST datasets also use keyset pagination and return has_more plus next_cursor. These mechanisms solve different problems.

MCP response cap. Controls how much data enters the assistant context. Narrow the query when it appears.
REST cursor. Advances through a deterministic dataset page. Pass every required cursor component back to the next request.
Dataset without pagination. A date range can still exceed the MCP cap even when the REST endpoint returns all matching rows at once.
Restricted history. A 403 DATE_RANGE_RESTRICTED response is access information, not a zero-row result.

Next-Day Movers returns its matching rows without REST pagination. A broad history can still be shortened by max_rows through MCP, so query smaller windows, save every raw response, and verify date-level counts before grading performance.

The server cannot validate the strategy

A correct data contract removes several preventable research errors. It does not prove that the ranking has economic value after spreads, option pricing, borrow, capacity, or multiple testing. It also does not stop a model from choosing the wrong tool or misreading a null unless the prompt and review process enforce those rules.

Run the fixed-date prompt above and export two artifacts: the untouched JSON response and a contract record containing tool, arguments, field definitions, timing rule, tier, count, and truncation state. Then compare the result against the quant research workflow explainer. Confirm historical access on the pricing page before expanding the test across years.