The problem with AI forex prompts is not phrasing — it is that you cannot tell a good answer from a confident invention. So every prompt below is paired with the correct answer, computed from a real archive on 17 August 2026. Run the prompt; if your model's answer does not match, it is hallucinating rather than analysing.
Give your agent access to real data first — pasting CSV works for small windows, but for these questions the practical route is an MCP server, since they all aggregate across hundreds of thousands of bars.
git clone --depth 1 --filter=blob:none --sparse https://github.com/varsansri/fxabsolute
cd fxabsolute && git sparse-checkout set mcp
cd mcp && npm install
claude mcp add fxabsolute -- node "$PWD/src/index.js"
Then run the prompts. Always require a sample size in the answer. That single instruction is the most effective hallucination detector available — a model that queried the data can state how many bars it used, and one that invented the number cannot, though it will often try.
Run these first. They have exact known answers, so they tell you whether the pipeline works before you trust anything else.
Which UTC hour has the widest average range on EURUSD,
and which is quietest? Give the figures in pips and state
the number of bars behind each.
Correct answer: busiest 14:00 UTC at 2.83 pips (80,029 bars); quietest 21:00 at 0.73 pips (76,385 bars) — a 3.9× spread, across 1,911,141 bars spanning 2021-01-03 to 2026-04-30.
Failure signature: naming "the London–New York overlap" without figures, or giving round numbers like "3 pips" with no bar count. Both mean it is reciting general knowledge rather than querying.
Rank the weekdays by average one-minute range on EURUSD.
Include the bar count for each day.
Correct answer: Friday 1.66, Thursday 1.59, Wednesday 1.59, Tuesday 1.50, Monday 1.42, Sunday 1.09 pips. Note Sunday's tiny sample — 40,696 bars against roughly 380,000 for a full weekday — which a careful answer will flag.
Compare average range across the London, New York and Tokyo
sessions on XAUUSD. State each session's window and sample size.
Correct answer: London (07:00–16:00 UTC) 108.13, New York (12:00–21:00) 106.78, Tokyo (00:00–08:00) 79.17. London and New York are much closer than most commentary suggests — a model reproducing the folk claim that New York dominates gold is not looking at data.
Once verification passes, these are the questions worth actually asking. Each is phrased to force a definition and a sample size, because that is where analysis usually goes wrong.
Compute the daily-return correlation between EURUSD and GBPUSD.
Report r, the number of overlapping days, and the share of days
they moved in the same direction.
Known answer: r = 0.77 across 1,536 overlapping days, same direction 77.72% of the time. Useful follow-up: "If I trade both, what is my real position size in a single risk factor?"
Characterise the distribution of weekend gaps on EURUSD.
Give the count, median, 90th and 99th percentiles, the largest
observed, and the share exceeding 10 pips.
Known answer: 309 gaps; median 5.4; 90th percentile 35.0; 99th percentile 127.5; largest 163.5 pips; 31.39% exceeded 10 pips. The distribution's fat tail is the point — a model reporting only the median has answered the wrong question.
How often did price touch the previous day's high and then
close below it, on EURUSD H1? Define "touch" explicitly before
computing, and report the count and the total sample.
No published answer here — this one is genuinely open. Its value is that requiring the definition first exposes the ambiguity: touch by wick or by close, exact or within a tolerance? Most disagreements between backtests come from an unstated definition rather than bad arithmetic.
I am considering a 5-pip take-profit with a 5-pip stop on
EURUSD H1. Before backtesting, tell me what could make this
result unreliable, quantitatively.
A good answer names two things. First, spread: a typical 1.5-pip spread is roughly 30% of a 5-pip target. Second, ambiguous bars — at a 5-pip bracket, 16.45% of EURUSD hourly bars touch both target and stop, and resolve close to a coin flip. The study is here. A model that just offers to run the backtest has missed the point.
| Pattern | Why it works |
|---|---|
| "State the sample size" | The single best hallucination detector |
| "Define X before computing" | Surfaces the ambiguity that causes wrong answers |
| "Show the code" | Lets you check the arithmetic rather than trust it |
| "What would make this unreliable?" | Turns the model into a critic instead of a cheerleader |
| "Give the date range" | Catches silently truncated data |
| "Compare against a null" | Distinguishes an edge from ordinary market behaviour |
The pattern running through every prompt above: let the model decide which statistic matters, and let code compute it. Language models are genuinely good at framing a question, spotting a confound and criticising a method. They are unreliable at arithmetic over thousands of rows, and confident either way.
And there is a third part neither the model nor the code can do. Recognising a setup as it forms, sitting through a drawdown, and not taking the trade you promised yourself you would skip are trained human skills. FXAbsolute replays the same archive bar by bar in a browser — free, no account — so the agent handles the statistics and you build the judgement.
Every prompt below is worthless against a model working from memory and useful against one with tool access. To give it that access:
claude mcp add fxabsolute -- npx -y fxabsolute-mcp
Then the phrasing that matters is "using the fxabsolute tools" — without it a model will often answer from training data and sound just as confident.
Note what the second and fourth ask for: the sample size and the comparison, not just the headline number. A model that has to report n alongside its answer is much harder to get a fabricated figure out of.
Give it tool access to real data and say so in the prompt. Install an MCP server — claude mcp add fxabsolute -- npx -y fxabsolute-mcp — then begin prompts with "using the fxabsolute tools". Ask for the sample size alongside every figure; that alone makes fabricated answers obvious.
Prompts that force a definition and a sample size. Ask which UTC hour has the widest average range and require the bar count; ask the model to define "touch" before computing level statistics; ask what would make a result unreliable. Vague prompts such as "is this a good setup" produce agreeable prose rather than analysis.
Require a sample size with every figure. A model that queried real data can state how many bars it used; one that invented the number gives round figures or general claims without counts. Verify against a known answer first — on EURUSD, the busiest UTC hour is 14:00 at 2.83 pips from 80,029 bars.
They analyse accurately when connected to real data and asked to compute in code, and inaccurately when asked to recall statistics or read prices from screenshots. The reliable pattern is to let the model decide which statistic matters and let code calculate it, then check the sample size and definitions in the answer.
14:00 UTC, averaging 2.83 pips of range per minute across 80,029 bars, measured over 1,911,141 one-minute bars spanning January 2021 to April 2026. The quietest is 21:00 UTC at 0.73 pips from 76,385 bars — a 3.9x difference between the busiest and quietest hours of the day.
Install an MCP server so the agent can query candles directly. The FXAbsolute server needs a sparse git clone of about 806 KB plus npm install, then registration with your client, and it exposes 28,412,683 one-minute bars across 15 instruments with no API key and no request cap.
No. The model will produce an answer because it produces answers, and that answer carries no predictive information. AI is useful for computing statistics over history, criticising a method, spotting confounds and framing questions — not for forecasting direction.
28.4 million one-minute bars over MCP with no API key — and every known answer on this page is reproducible from the same archive.
Open FXAbsolute →