btmcp

Overview Schema Source Related Servers Discussions Admin

validate_strategy

Validate a strategy spec before running it: check schema and warm-up fit against available history, and get actionable issues. Use when a spec is rejected or before an expensive backtest.

Instructions

Dry-run a strategy spec without executing it: checks the schema, the warm-up against available history, and reports actionable issues. Cheap. Call it when a spec has been rejected, or before an expensive run. Worked specs: {'primitive':'buy_and_hold','params':{}}; {'primitive':'sma_cross','params':{'fast':10,'slow':30}}; {'primitive':'threshold','params':{'lookback':15,'entry_pct':1.5,'exit_pct':0.25}}. A spec also carries optional top-level fields beside primitive and params, e.g. {'primitive':'sma_cross','params':{'fast':10,'slow':30},'warmup_bars':60,'rebalance':'weekly','sizing':'fixed_fraction','fraction':0.25}. Unknown fields are rejected rather than ignored. Examples: validate_strategy(spec={'primitive':'sma_cross','params':{'fast':10,'slow':30}}, symbol='SYN-02', as_of='2021-12-31'); validate_strategy(spec={'primitive':'buy_and_hold','params':{}}, symbol='SYN-09', as_of='2021-12-31'). as_of is required on this tool and the call fails without it.

Input Schema

TableJSON Schema

Name	Required	Description
`spec`	Yes	A strategy spec object. See the strategy-primitives resource.
`as_of`	Yes	REQUIRED point-in-time cutoff. There is no default and no safe guess. No bar dated after this is returned, ever. Set it to the decision date you are simulating, not to today: using a later as_of than the evaluation window is how a backtest accidentally sees the future.
`symbol`	Yes	Symbol the spec would run against.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool does not execute, that unknown spec fields are rejected rather than ignored, and that as_of is mandatory or the call fails. It doesn't describe the output structure, but an output schema is available.

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?

Core purpose and usage are front-loaded in the first two sentences, and later sentences provide concrete examples and edge-case rules. The description is long, but every section (examples, optional fields, unknown-field handling, as_of requirement) contributes operational value.

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?

For a tool with no annotations and a nested spec object, the description covers the purpose, usage triggers, spec structure, optional fields, unknown-field rejection, and required as_of behavior. Return-value details are reasonably left to the output schema, so the description is sufficiently complete.

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 coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: worked spec examples, optional top-level fields (warmup_bars, rebalance, sizing, fraction), and the rejection of unknown fields. This compensates for the spec parameter's vague schema description.

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 opens with a specific action, 'Dry-run a strategy spec without executing it', and names the exact checks performed (schema, warm-up against history, actionable issues). It clearly distinguishes the tool from execution-oriented siblings like run_backtest.

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

Usage Guidelines5/5

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

Explicitly states when to call it: 'Call it when a spec has been rejected, or before an expensive run.' The phrase 'without executing it' also makes it clear this is a preflight alternative to run_backtest, not a replacement for actual runs.

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

Deploy Server