AINumbers Research · Benchmark Explainer

Does mounting an MCP change what a model gets right?

Every model in this benchmark answers the same nine frozen finance tasks three ways: alone, with the AINumbers MCP offered, and with one sentence directing it to the tools. This page walks through the three arms and what the scorer counts, then reports the verified numbers. Results below were recorded 2026-10-15 and are current as of that date.

Presenter mode shows one step per screen. Arrow keys move, A toggles autoplay, Esc exits.
Headline: of the nine models with a measured offered arm, seven scored 100% on tasks 0 to 8. Solar Mini 4 scored 77.8% and Solar Pro 4 scored 88.9%, both missing the same reserve task. Gains concentrate on the models whose bare baseline was weakest, and across the valid paired comparisons 14 of 15 favour the MCP arm (exact binomial p < 0.001).
1
Step 1

The same frozen prompt runs three ways

Each model sees the same task text three times, once per arm. Only what surrounds the prompt changes; the words of the task never do.

frozen taskidentical bytes, all arms model bare: no tools in the envelopeanswer from the weights alone offered: AINumbers MCP mountedthe model decides whether to look directed: one added sentencerun find_tool first, then call

The nine tasks are finance computations drawn from the AINumbers catalog: escrow interest, coverage ratios, op-risk capital, a reserve requirement, annuity values and their neighbours. Prompts, scorer and manifests were frozen before the cells ran, and every tool call a model makes is counted mechanically on the harness side.

2
Step 2

The bare arm answers with nothing but weights

The bare arm is the baseline. The model receives the task and nothing else, and it must reason to an answer in text.

envelope: task text onlyzero ainumbers tools exposed reason in textFINAL ANSWER: value 0 tool callsattested per run

Clean cells run one fresh session per task in an isolated working directory, so the model cannot reach the benchmark's own files. Where a harness could not isolate the working directory, the run's transcripts were audited and the run carries that disclosure with its numbers.

3
Step 3

The offered arm leaves the choice to the model

The AINumbers MCP is mounted and its tool catalogue is visible. Nothing tells the model to use it; usage here measures whether the model goes looking on its own.

catalogue visible700+ tools, find and call model's choicesearch or answer by hand usage ranged 0/9 to 9/9 rowsacross the nine measured modelscounted mechanically per row

Offered-arm usage turned out to be a property of the model, and the measured spread runs from a model that used the tools on every row to models that barely engaged the catalogue at all. That spread is why the benchmark reports usage alongside accuracy instead of assuming the tools were used.

4
Step 4

The directed arm: one sentence changes the behaviour

The directed arm keeps the mount from the offered arm and adds a single instruction: find the tool first, then call it. The task text is still untouched.

offered armplus: run find_tool first tool contact risesdirected beats offered on usage latency cost is realdirected p50 above bare p50on most models measured

On the frontier models the directed arm moved usage without moving accuracy, and on one model it added a measurable latency cost for identical answers. The benchmark treats direction as a separate experimental variable for exactly that reason.

5
Step 5

What the scorer counts

Scoring is mechanical and strict: the denominator is all nine tasks, every run. A timeout, a transport error, or an unparseable answer is a miss, because delivering a final answer is part of the task.

read FINAL ANSWERlast matching marker compare to gold valuepercent forms accepted once correct / 9 taskserrors and timeouts count as misses

The accuracy figures below use this strict full-denominator convention throughout. An earlier relaxed convention that scored only parseable answers was replaced, and every published cell was rescored under the strict rule before the numbers here were signed off.

6
Step 6 · data as of 2026-10-15

The verified matrix for tasks 0 to 8

Nine tasks per arm, nine models with a measured offered arm, recorded 2026-10-15. Cells still pending are marked as such; nothing on this page is projected.

ModelBareMCP (offered)MCPd (directed)Note
Muse Spark 1.388.9%100%100%16 recorded tool calls on offered, 29 on directed
GLM-5.3-Flash88.9%100%pending44 ainumbers calls on the offered arm
GPT-5.6 Terra88.9%100%n/a16 ainumbers calls; one sequential session
DeepSeek V4.1 (clean)77.8%100%100%bare is the clean re-run baseline
Nemotron 3 Ultra77.8%100%100%12 recorded tool calls on offered, 31 on directed
Longcat 2.577.8%100%100%15 recorded tool calls on offered, 30 on directed
MiMo V2.6 (clean)66.7%100%100%largest gain over a clean bare baseline
Solar Mini 488.9%77.8%88.9%one wrong value and one transport error on the offered arm
Solar Pro 4 (historical)66.7%88.9%88.9%route died mid-study; a dated re-run on a new route is pending and is not pooled here
Sonnet 588.9%pendingpendingoffered and directed re-runs pending
Nemotron 3 Super77.8%not runnot runbare only: the harness context wall blocked the assisted arms for this model
The seven 100% offered cells and the weaker-bare pattern: the models that gained most from the offered MCP were the ones scoring lowest bare. DeepSeek, Longcat and Nemotron Ultra each gained 22.2 points, and MiMo gained 33.3 to reach ceiling.

Absolute accuracy on a public-task corpus is always contamination-suspect, so the benchmark's claims are about the differences between arms on identical tasks, measured one day at n=9 per arm, and the per-cell disclosures from the run logs travel with any reuse. The full per-task ledger, prompt bytes and scoring manifest live in the project's research notes; a public dataset export is planned and will be published later.

🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.