An MCP server for quantitative research

The Model Context Protocol (MCP) is an open standard that lets a language model call tools on a server instead of improvising over text pasted into its context window. An MCP server for quantitative research would expose the basic steps of a study as declared functions: build a point-in-time universe, resolve identifiers, fetch a feature table, run a validation. The model chooses the calls and writes the prose; the server does the arithmetic and returns a record of what it did. The protocol provides the plumbing for that split; reproducibility comes from how the server is built, and this page sets out what it has to do.

What MCP is, mechanically

MCP standardizes the interface between a model host, such as a chat application or a coding assistant, and a tool server. The two sides talk over JSON-RPC, a simple request-and-response message format. A server declares three kinds of things. Tools are functions the model can call, each described by a schema that names the arguments, their types, the allowed values and which ones are required. Resources are readable context, such as a data dictionary, that the host can load without the model guessing at it. Prompts are templates a user can invoke. The schema is a contract the server validates every call against. The specification defines the wire format; it says nothing about how a tool computes its answer.

A server can run locally, over standard input and output, or remotely over HTTP, which is what a hosted data platform needs.

Why a typed tool beats a pasted table

Pasting a price table into a chat fails in ways that look like model errors but are interface errors.

• Truncation is silent. A long table is cut off, and the model answers from what it can see without saying so.
• The paste has no schema. Dates arrive in several formats, thousands separators survive into arithmetic, and an empty cell is indistinguishable from a missing one.
• The model does the arithmetic. A language model summing pasted rows is generating text, not executing code, and the same question can return different answers. A tool call can run code whose output depends only on its inputs, if the server is built that way.
• There is no record. A paste leaves no evidence of which rows were read, when, or from which version of the data. A tool call has arguments, a result and a version to log.
• Nothing can be required. A tool can insist on an as-of date. A paste cannot insist on anything.

Hazards specific to market data

The model's own memory is look-ahead information. A language model trained on public text has absorbed outcomes: which companies did well, which were acquired, which collapsed. Asked to pick promising S&P 500 stocks for 2021, it answers partly from memory of what happened in 2021. Building the universe inside a point-in-time tool, and refusing free-form lists of company names, removes the most direct channel. It does not remove the rest: the model's knowledge can still shape which filters it proposes, which variant it favours and how it narrates the result. The remedy for that residue is procedural: freeze the rules before evaluation, and judge them on data the model never saw. The mechanism is the one described under look-ahead bias.

Unstated as-of dates. An answer without an as-of date cannot be reproduced and usually leaks. The as-of argument should be required, with no default, and every response should echo the as-of date and knowledge pin it used.

Runs that cannot be repeated. Sampling randomness, a rephrased prompt or a model version change all break reproduction. A sequence of calls can be replayed if every call was logged with its arguments, the data snapshot and the code version, whether the model planned it or improvised it. Reproducing the model's choices is a different problem from reproducing the computation, and only the second is the server's job.

Invented column names. Models produce plausible identifiers that do not exist, such as adj_close_pit or pe_ttm_ff. Publish the real schema as a resource, validate column arguments against it, and return an error that lists the valid names.

Survivorship by ticker. Resolving a universe through today's symbol list silently drops delisted and renamed companies. Identifier resolution has to run as of the query date, which is what point-in-time data means in practice.

Unbounded search. An agent asked for a profitable strategy can keep generating variants until one looks good. A cap on runs and a log of every trial let a reviewer see how many were tried and discount the best result accordingly. They make the search auditable; they do not make the selected result valid.

What a reproducible server has to do

Four properties do most of the work, and none comes from the protocol. The server computes and the model orchestrates. Every call is logged with its arguments, a digest of its result, the data snapshot, the server version and any random seed. A run can be replayed from the log alone and produce identical numbers. And the research note embeds that manifest, so a reviewer who doubts a result replays it and gets the same table.

A proposed interface

The workflow below is a design proposal, not a description of a served Quantverse tool, and the JSON is a sketch of a call's content rather than a literal MCP message, which wraps the tool name and arguments in a tools/call request.

Universe construction. The model should not name companies. It calls a screener with explicit filters, and the server returns the membership as it stood on the as-of date.

{
  "tool": "build_universe",
  "arguments": {
    "as_of": "2024-06-28",
    "index": "RUSSELL2000",
    "filters": {"min_median_dollar_volume": 2000000, "sectors_excluded": ["REIT"]}
  }
}

Of the pieces this needs, ticker-to-security resolution as of a date is served today through the Quantverse databank API, catalogued as CIK, CUSIP and FIGI mappings; the point-in-time screener is listed as coming soon.

Feature building. The model reads the schema resource, then requests a table by column name. The server enforces point-in-time construction, so a feature that would need tomorrow's data fails at request time rather than at review time. The catalog lists technical features and forward-return labels as coming soon.

Validation. The model supplies a strategy specification, not a set of returns. The server runs walk-forward or purged cross-validation with the fold rules fixed in advance, and returns per-fold metrics, turnover and the run identifier. The model writes the interpretation. It cannot alter the server's artifact, though it can still misquote it in prose.

What such a server should expose

A useful surface is small and typed. Universe and screener calls with a required as-of date. Identifier resolution that honours ticker changes. Corporate actions, splits and dividends, with a knowledge pin separate from the event date. Price and bar retrieval, including dollar bars, listed as coming soon and built under the bar construction rules. Feature and label tables. A validation runner that returns folds rather than a single equity curve.

Properties matter as much as endpoints. Every tool is versioned and logged, and its output depends only on its inputs. The as-of date is required and never defaulted. Compute and data access are metered and capped. Nothing touches a brokerage account or order flow without a human's approval. Pricing for the data packages is on the pricing page.