Skip to main content
Glama

backtest_condition

Read-onlyIdempotent

What happened AFTER a condition in the past, on one symbol and timeframe — "how did BTC do after RSI dropped below 30 on 4h", "is a golden cross on ETH daily actually bullish", "what usually follows a −5% day on SOL". Runs an event study over the whole stored tape (up to 1000 candles: ~41 days on 1h, ~166 days on 4h, ~3 years on 1d): occurrences, average / median forward return, win rate, average best and worst excursion per horizon, the unconditional baseline over the same tape and the EDGE the condition adds over it, the last five episodes, and whether the condition is active on the latest bar. Same condition vocabulary as screen_symbols. Quote the edge and the sample size together — a 3-sample stat is an anecdote.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYesTrading pair, e.g. BTCUSDT (a bare "BTC" is read as its USDT perpetual)
horizonsNoBars ahead to measure returns over (≤ 4). Default per interval ≈ 4h / 1d / 3d: 1h → [4, 24, 72], 4h → [6, 18, 42], 1d → [1, 3, 7].
intervalNoCandle timeframe4h
conditionsYesUp to 3 conditions, AND-ed. Examples: RSI oversold = {"metric":"rsi","op":"lt","value":30}; above the 200 EMA = {"metric":"priceVsEma","op":"gt","value":0,"period":200}; golden cross = {"metric":"emaSpread","op":"crossAbove","value":0,"period":50,"period2":200}; MACD bullish cross = {"metric":"macdHistogram","op":"crossAbove","value":0}; dumped 5% in a day = {"metric":"changePct","op":"lt","value":-5,"period":24}.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
barsNoCandles the study ran on (the whole stored tape)
fromNo
recentNoNewest episodes first: { openTime, barsAgo, price, returnsPct { "<bars>": pct } }
symbolNo
horizonsNoPer look-ahead: { bars, samples, avgReturnPct, medianReturnPct, winRatePct, avgMaxUpPct, avgMaxDownPct, bestPct, worstPct, baselineAvgReturnPct, edgePct } — edge = avg − unconditional baseline
intervalNo
warningsNo
activeNowNoConditions hold on the latest closed bar
conditionsNo
occurrencesNoEpisodes — the FIRST bar of each run where the conditions held
horizonHoursNo
coverageHoursNo
currentValuesNoLatest value of every metric involved
evaluableBarsNo
lastOccurrenceNo{ openTime, barsAgo, price }

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral context: it runs over the entire stored tape (up to 1000 candles), computes specific statistics (average/median forward return, win rate, best/worst excursion, baseline, edge), and includes a critical caveat about quoting edge with sample size (a 3-sample stat is an anecdote). This goes beyond annotations and is useful for proper interpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but each sentence earns its place. It front-loads the core question and examples, then details the analysis output and caveat. It is not overly verbose; the length is justified by the complexity of the tool. However, it could be slightly more concise by trimming some redundant phrasing, but overall it is well-structured and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive for a complex tool. It covers what the tool does, what it returns (occurrences, forward returns, win rate, excursions, baseline, edge, last five episodes, active status), the sample size limitation, and gives usage examples. It even mentions the output includes an unconditional baseline and the edge, which are crucial for interpretation. With an output schema present, it doesn't need to detail return format, but the description gives a full conceptual overview. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with detailed parameter descriptions, so baseline is 3. The tool description adds value by explaining default horizons per interval, the concept of 'edge' over the baseline, and providing concrete condition examples (RSI oversold, golden cross, etc.) that clarify how to structure conditions. It also clarifies the meaning of the edge statistic, which is not in the schema. This is meaningful added semantic context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: it runs an event study on historical data to answer 'what happened AFTER a condition in the past' for a given symbol and timeframe. It uses a specific verb (backtest), a resource (condition on a symbol/timeframe), and provides concrete examples (RSI, golden cross, -5% day) that distinguish it from siblings like screen_symbols, which is implied to be for current screening. The phrasing 'Same condition vocabulary as screen_symbols' further clarifies its relationship.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: for historical performance analysis of a condition, contrasting with screening current conditions via screen_symbols (implied by the vocabulary mention). It gives examples of questions it answers, but it does not explicitly state 'use screen_symbols for current screening' or list when not to use this tool. The guidance is clear from context but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources