Skip to main content
Glama
K4L-EL

pyon-mcp

by K4L-EL
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Run backtest

run_backtest

Backtest a trading strategy over historical data to evaluate performance and set a baseline for optimization.

Instructions

Backtest a strategy over a historical window and wait up to 180s for it to finish. Use this after create_strategy or edit_strategy to measure real performance, and before optimize_strategy to establish a baseline. Parameters: strategyId (UUID, required); startDate and endDate (YYYY-MM-DD, optional, must be real past dates with endDate after startDate and at least 7 days between them - default is the last 365 days); timeframe: one of 1m, 5m, 15m, 1h, 1d - defaults to the strategy's native timeframe, fetched automatically; initialCapital in USD (number 100 to 100000000, default 50000). Returns metrics (totalTrades, totalOrders, totalReturnPct, sharpeRatio, maxDrawdownPct, winRate) plus up to 8 diagnostic messages verbatim - read these, they carry gate pass-rate evidence explaining WHY the strategy did or did not trade - and an explicit note when 0 trades closed but orders were opened (the strategy entered and is still holding, which is not the same as a dead strategy). A warning is added when a 1d strategy is tested over fewer than 300 days, since that is too few bars to judge it. On timeout the error names the backtest id, which get_job_status accepts as a fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endDateNoWindow end, YYYY-MM-DD. Must be a real calendar date no later than today, after startDate, and at least 7 days from it. Defaults to today.
startDateNoWindow start, YYYY-MM-DD (2000-01-01 or later). Defaults to 365 days before endDate.
timeframeNoBar timeframe: one of 1m, 5m, 15m, 1h, 1d (lowercase). Defaults to the strategy's native timeframe, fetched automatically.
strategyIdYesStrategy UUID. Find it with list_strategies (it is also returned by create_strategy). Not a strategy name.
initialCapitalNoStarting cash for the backtest. Number between 100 and 100000000; defaults to 50000.

Tool Definition Quality

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden. It discloses the 180-second wait, timeout behavior, diagnostic message contents, zero-trade nuance, short-window warning, and automatic timeframe fetching—all non-obvious behavioral traits beyond the schema.

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 long but logically structured: action, workflow placement, parameters, return values, diagnostics, timeout fallback. While dense, every sentence carries useful information; only a slight trimming could improve directness.

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?

There is no output schema, so the description fully enumerates return metrics, diagnostic messages, edge cases like holding positions, and timeout fallback. It also accounts for all 5 parameters and their defaults, making it complete for safe invocation.

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% and each parameter already has a rich description. The description adds modest extra context like 'not a strategy name', 'fetched automatically', and the 7-day minimum gap, reinforcing but not dramatically extending schema info. This justifies a 4 above the 3 baseline.

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—'Backtest a strategy over a historical window and wait up to 180s'—clearly naming the verb and resource. It is distinguished from siblings like optimize_strategy and diagnose_strategy by focusing on strategy performance measurement over historical data.

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 explicitly states when to use the tool: 'after create_strategy or edit_strategy to measure real performance, and before optimize_strategy to establish a baseline.' It also names get_job_status as a fallback on timeout, providing clear workflow context and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/K4L-EL/pyon-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server