TradeMemory Protocol

Overview Schema Source Related Servers Discussions Admin

evolution_run_backtest

Idempotent

Backtest a candidate trading pattern against historical OHLCV data to measure Sharpe ratio, win rate, max drawdown, and total PnL before deploying it.

Instructions

Backtest a candidate pattern against historical OHLCV data.

Takes a pattern dict (from discover_patterns) and runs a vectorized backtest. Returns fitness metrics: Sharpe ratio, win rate, trade count, max drawdown, total PnL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pattern_dict": "<pattern_dict>"
    },
    "name": "evolution_run_backtest"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Days of history to backtest against (default 90)
`symbol`	No	Trading pair (e.g. "BTCUSDT")	BTCUSDT
`timeframe`	No	Bar timeframe — "5m", "15m", "1h", "4h", "1d"	1h
`pattern_dict`	Yes	CandidatePattern as dict (from discover_patterns output)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.4Aug 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already provide idempotentHint=true and destructiveHint=false, establishing that repeated calls are safe and non-destructive. The description adds valuable context by explaining it 'runs a vectorized backtest' and 'Returns fitness metrics: Sharpe ratio, win rate, trade count, max drawdown, total PnL,' which helps the agent understand the tool's behavior and output beyond the annotations.

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

Conciseness5/5

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

The description is concise—two short sentences that front-load the core purpose ('Backtest a candidate pattern') and then provide necessary detail about the input and output. Every sentence contributes meaningful information with no redundancy.

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

Completeness4/5

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

The description covers the tool's purpose, input origin, and output metrics, making it sufficiently complete for a backtest tool. While it doesn't elaborate on all parameters (days, symbol, timeframe), the schema fully documents those, and the description doesn't need to repeat them. The output schema exists, so detailed return documentation isn't required.

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%, so the baseline is 3. The description adds meaning by specifying that pattern_dict is 'from discover_patterns output', clarifying the expected structure and origin of the key required parameter. It doesn't repeat the schema's parameter details, but the added context about the input source is valuable.

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?

Description states a specific verb+resource: 'Backtest a candidate pattern against historical OHLCV data.' It clearly distinguishes from siblings like evolution_discover_patterns (which discovers patterns) and evolution_evolve_strategy (which evolves strategies).

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 indicates the input comes 'from discover_patterns', giving clear context for when to use this tool (after pattern discovery). It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer appropriate usage relative to sibling tools.

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