Skip to main content
Glama

Backtest360

by com.backtest360

run_backtest

Run a historical backtest against the engine.

    Quota-counted and compute-bound. Validate the
    strategy first (validate_strategy is far cheaper). On a 504 compute
    timeout, do NOT retry the same request — reduce the date range, use a
    coarser frequency, or simplify the strategy. On 429/503, wait for the
    advertised Retry-After before retrying.

    Args:
        data_source: Either inline OHLCV ({"ohlcv": {dates, open, high,
            low, close, volume?}} as parallel arrays, ISO-8601 dates) or a
            server-side fetch ({"symbol", "start", "end", "frequency"} —
            requires a paid plan).
        strategy: Strategy document (indicators[] + condition_tree).
            Mutually exclusive with signals.
        signals: Precomputed signal series ({"dates": [...], "values":
            [-1|0|1, ...]}). Mutually exclusive with strategy.
        execution: Execution/cost/risk/sizing settings. Use values from
            get_catalog('execution-modes'/'stop-types'/'sizing-methods');
            omit for engine defaults.
        benchmark: Optional benchmark data source (same shape as
            data_source) — when given, the result also carries
            benchmark-relative metrics (beta, alpha, information ratio,
            tracking error, up/down capture) and bar-alignment info.
        data_inputs: Optional custom time-series the strategy references
            (name -> {dates, values}).
        response_detail: 'summary' (default — headline metrics, smallest),
            'stats' (every metric), 'full' (plus trades and series
            downsampled to a fixed, server-controlled number of points).
        include: Optional add-on blocks at any detail level: 'trades',
            'equity_curve', 'monthly_returns', 'yearly_returns',
            'signal_diagnostics' (which per-bar entry/exit conditions
            fired, as capped fire-date lists — {"available": false, ...}
            if the run has none, e.g. precomputed signals).
        trades_limit: Max trades returned when trades are included.

    Returns:
        The shaped result at the requested detail (including
        ``benchmark_relative``/``alignment`` when a benchmark was given);
        an oversized result is thinned and marked ``truncated_by_mcp``. If
        the engine rejects the request as invalid (400/422), returns
        {"accepted": false, "error": ...} so you can fix the named
        field(s) and retry. Capacity, timeout, and permission failures
        (e.g. 429/503/504/401/403) raise a tool error carrying explicit
        recovery guidance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
includeNo
signalsNo
strategyNo
benchmarkNo
executionNo
data_inputsNo
data_sourceYes
trades_limitNo
response_detailNosummary

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: quota-counted and compute-bound, error handling details (400/422 return accepted:false, other errors raise tool error with recovery guidance), response truncation (truncated_by_mcp), and benchmark-relative metrics when benchmark is provided.

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 thorough but somewhat lengthy. However, it is well-structured with clear sections (core action, usage guidance, parameter details, return info), front-loaded with key points, and uses formatting effectively. Minor reduction possible but every sentence adds value.

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?

Despite no annotations and 0% schema coverage, the description provides complete context for using this complex tool: explains return values (including benchmark_relative/alignment, truncation), error handling, parameter options, and interactions with sibling tools. The output schema exists, but description still adds value on return shape.

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

Parameters5/5

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

Schema coverage is 0%, but the description compensates fully by explaining each parameter in depth: data_source formats, strategy/signals structure, execution defaults via get_catalog, benchmark shape, data_inputs format, response_detail enum meanings, include options (including signal_diagnostics behavior), and trades_limit. This adds significant semantic meaning beyond the schema.

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 action: 'Run a historical backtest against the engine.' It uses a specific verb and resource, and distinguishes itself from siblings like validate_strategy by mentioning it's compute-bound and quota-counted.

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?

The description provides explicit guidance: validate the strategy first with validate_strategy (cheaper), avoid retrying 504 timeouts by reducing date range/coarsening frequency/simplifying strategy, wait for Retry-After on 429/503, and notes that server-side data_source requires a paid plan. It also clarifies mutual exclusivity of strategy and signals.

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

All Backtest360 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Every tool targets a distinct operation or resource: backtesting, comparison, macro data, reference catalogs, etc. Even similar tools like run_backtest and compare_backtests are clearly differentiated by purpose and inputs.

Naming Consistency4/5

Overall consistent verb_noun pattern in snake_case, with a few exceptions like engine_info (noun_noun) and export_backtest (verb_noun but less common verb). The pattern is predictable and aids agent selection.

Tool Count4/5

20 tools is slightly above the ideal range but justified by the breadth of the platform (backtesting, data retrieval, reference, export). Each tool serves a clear purpose without redundancy.

Completeness4/5

Covers the full backtesting lifecycle: strategy validation, data sourcing, backtesting, comparison, export, and reference lookups. Minor gaps exist (e.g., no explicit strategy persistence), but the core workflow is complete.

Resources