There is a quiet assumption baked into most "AI + market data" tools: that if you give a capable model enough raw data, it will produce the right answer. In practice, that assumption is exactly where latency, inconsistency, and compliance risk creep in.
When an AI connector hands the model a raw data series, the model becomes a calculator. It has to pull the data, decide how to interpret it, run the math in its head, and format a result -- every single time, in every conversation. Ask the same question on Monday and again on Thursday and you can get two different methodologies: one counts calendar days, the other counts trading days; one adjusts for dividends, the other does not; one quietly includes a market holiday, the other does not. The number changes, and you are left wondering which one to trust.
For a casual question, that is tolerable. For an option trader sizing a position, or an analyst whose model has to be repeatable and auditable, it is not.
We took a different path -- one that comes directly from ten years of building for this exact audience.
A decade of primitives, not a pile of data
Over the last ten years we have talked to thousands of MarketXLS users. Those conversations turned into something more valuable than any single dataset: a library of financial primitives -- the functions our users actually reach for, expressed the way practitioners think.
Not "here is a price series, go compute." Instead:
- The return of a stock over the last year -- using trading days, not calendar days, and skipping holidays.
- A technical indicator that knows the difference between a calendar window and a trading window.
- The highest price a stock reached over the last 60 trading days.
- An option chain filtered to strikes between two prices, for a chosen expiry, with greeks.
- The same filter applied across a basket of symbols at once.
There are thousands of these functions, and because they compose, there are effectively millions of combinations. Each one encodes a single, standardized, battle-tested way of calculating and presenting an answer -- the accumulated judgment of a decade of real users who told us how they actually work.
From raw data to executable primitives
Figure 1 -- From raw data to executable primitives.
What the MCP actually does
With our MCP connector, we exposed those same primitives to the AI.
That one design choice flips the model's job. Instead of fetching data and interpreting it, the AI selects and executes a function. The calculation already exists. The methodology is already fixed. The model's role shrinks to the thing models are good at -- understanding intent and choosing the right tool -- while the thing models are unreliable at -- ad-hoc math under time pressure -- is removed from the loop entirely.
The consequences are concrete.
1. Lower latency
A raw-data connector runs a loop: fetch, reason, compute, format. A function-grounded connector does one thing: execute and return a finished answer. There is no multi-step reasoning chain standing between the question and the result, because the result is what the primitive produces.
We pushed this further at the protocol level. When a workflow needs the same metric across many tickers, our connector batches the work -- collapsing what would be a hundred separate round trips into a handful of grouped calls. The AI asks once; the heavy lifting happens server-side in our execution layer.
Execution path comparison
Figure 2 -- Two architectures, two latency profiles.
2. Determinism and consistency
Because every answer comes from the same standardized primitive, the same question returns the same method every time -- across conversations, across users, across days. No silently shifting assumptions about trading days, dividend adjustment, or holidays.
For anyone who has to defend a number -- to a client, a committee, or a regulator -- this is the difference between "the AI said so" and "this is the firm's standard calculation, and here is the function that produced it." Repeatability and compliance stop being a hope and become a property of the system.
3. Speed where it matters most: the option-trader workflow
This is where the architecture earns its keep. An options workflow built on raw data is a fragile chain of dozens of steps -- pull the chain, parse it, filter by moneyness, align expiries, recompute greeks, repeat per symbol. Each step is a chance for the model to drift or stall.
With MarketXLS, that workflow is already a set of primitives. Your AI has direct access to:
- a full option chain, and a filtered one (by strike range, expiry, or moneyness),
- greeks alongside the contracts,
- the ability to filter options across multiple stocks in a single motion,
- and the strike/expiry helpers traders use to build a position.
What was a brittle, many-step exercise becomes a few function calls that return clean, standardized results -- fast enough to keep up with the way a trader actually thinks.
Option-trader workflow
Figure 3 -- An option-trader workflow as composable primitives.
One methodology, in your spreadsheet and your AI
There is a second payoff that matters to professionals: the same primitives that power the MCP also power reusable MarketXLS spreadsheets. You implement your methodology once -- your screen, your option strategy, your valuation model -- and your workbook stays updated automatically. Now your AI draws on the same functions, so the number you see in your template and the number your AI returns come from one source of truth, not two diverging interpretations.
Build it once. Use it in Excel. Ask about it in your AI. Get the same answer.
Data you can put your name on
None of this matters if the underlying data is fragile. Ours isn't. MarketXLS runs on fully licensed, enterprise-grade market data -- the same reliable feed that has stood behind our spreadsheets for years, now available inside your AI workflow. The result you get from a function call is grounded in data you can actually build on.
Where we think this leaves us
We will not pretend to have a leaderboard we have not run. But we will say this plainly:
We believe MarketXLS may be the most responsive market-data MCP connector available today for OpenAI and Claude -- not because of a faster pipe, but because the architecture does less work at query time. Execution beats interpretation on latency, and it beats it on trust.
If you are an option trader, a professional investor, or a finance professional, the question worth asking of any AI connector is simple: is it handing my model raw data to interpret, or proven primitives to execute? The first is a calculator that changes its mind. The second is an analyst that does the same thing every time, quickly, on data you can defend.
That is the category we are building for -- and the one we think serious users will care about most.
