The backtest360-mcp server exposes the Backtest360 engine API as MCP tools, enabling AI agents to build, validate, and run trading strategy backtests conversationally. It is a thin adapter — all calculations are performed by the Backtest360 engine.
Session Setup & Health
engine_info: Check engine version, API contract, and health status
get_me: Inspect API key permissions, rate limits, usage, and feature flags
Reference & Discovery
get_catalog: Fetch reference catalogs (operators, execution modes, stop types, sizing methods, bar frequencies, metric sections)
list_indicators: Discover technical indicators and retrieve full parameter schemas
list_templates: Browse predesigned strategy templates and fetch complete strategy logic
get_strategy_schema: Retrieve the JSON Schema for strategy documents
Strategy Building & Validation
validate_strategy: Validate a strategy document without running a backtest — returns structured, actionable errors
Backtesting & Signals
run_backtest: Run a full historical backtest with customizable data source, execution settings, benchmarks, and response detail levels (summary, stats, full)
get_latest_signal: Evaluate a strategy on the most recent bar to get a current buy/sell/hold signal
compare_backtests: Run multiple strategies side-by-side on the same data for direct comparison
compute_stats: Compute performance metrics from an externally provided returns series
Asset & Market Data
search_tickers / list_tickers: Search or list available assets by name or asset class
get_data_range: Check available date range and estimated bar count for a symbol/frequency
get_ticker_info: Get identity and data coverage details for a symbol
get_quote (paid): Fetch the latest available price for a symbol
get_price_history (paid): Retrieve OHLCV price history over a date range
list_macro_series / get_macro_series: List and fetch macroeconomic data series
Workflow Prompts: Scaffold common multi-tool workflows (e.g., robustness review, build and validate).
Supports both inline OHLCV data (free tier) and server-side data fetching (paid plan). Results are shaped to fit agent context windows, with truncation markers when limits are hit.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@backtest360-mcp Run a backtest for a moving average crossover on AAPL from 2023"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Connect any MCP-capable AI client and drive real backtests conversationally: discover indicators, build and validate strategies, run backtests, and read the results — all against the deterministic Backtest360 engine. The server contains no AI and computes no numbers of its own; it is a thin, faithful adapter over the engine HTTP API. Your engine API key and its plan govern everything (permissions, rate limits, data access).
Two transports: a hosted HTTP endpoint at
https://mcp.backtest360.com/mcp (send your key as an X-API-Key header) and local
stdio (self-host — see below).
pip install backtest360-mcp # or, from a clone: pip install -e .Requires Python 3.10+ and a Backtest360 API key. Get one free, instantly at
backtest360.com/api-access — submit your email and a key
(format b360_…) is issued on the spot and emailed to you; no approval needed. Authentication
is API-key only. The free tier runs backtests on data you upload; fetching historical price
data from the engine server-side is a paid capability.
Related MCP server: FinClaw
Everything is environment-driven:
Variable | Required | Default | Purpose |
| yes | — | Engine API key, sent as |
| no |
| Engine base URL |
| no |
| Per-request timeout (seconds) |
| no |
| Hard cap on a single tool result |
Point your MCP client at the hosted endpoint over HTTP and send your key as an
X-API-Key header:
{
"mcpServers": {
"backtest360": {
"type": "streamable-http",
"url": "https://mcp.backtest360.com/mcp",
"headers": {
"X-API-Key": "b360_..."
}
}
}
}Run the server yourself and let your client launch it over stdio (the common
mcpServers shape):
{
"mcpServers": {
"backtest360": {
"command": "backtest360-mcp",
"env": {
"BACKTEST360_API_KEY": "b360_..."
}
}
}
}Prefer not to put the key in a config file? Point command at a small wrapper script
that exports the key from your secrets manager and then runs backtest360-mcp. A
minimal example config is in examples/mcp.json.
Tool | What it does |
| Engine version, API contract, health |
| What the configured key can do: permission scopes, limits, current usage, capability flags |
| Reference catalogs: operators, execution modes, stop types, sizing methods, bar frequencies, metric sections |
| Indicator discovery; per-indicator parameter schemas |
| Predesigned strategy templates — discover compactly, fetch one in full, ready to validate and run |
| JSON Schema for strategy documents |
| Validate a strategy without running it — returns structured, locatable errors |
| Run a historical backtest |
| Evaluate the most recent bar only (no P&L) |
| Run several strategies on the same data, side by side |
| Compute the metric set from an externally produced returns series |
| Asset discovery for server-side data fetch |
| Available history and bar-count estimate for a symbol |
| Symbol identity and data coverage in a single call |
| Latest available price for a symbol (paid plan) |
| OHLCV price history over a date range (paid plan; long histories downsampled to fit) |
| Macroeconomic data: list the series catalog, then fetch one series' observations |
The cheap static catalogs are also published as MCP resources
(backtest360://catalog/{name}, backtest360://schema/strategy) for clients that
support resource attachment.
Two workflow prompts scaffold the common multi-tool flows for a connected AI: each names which tools to call, in what order, and what to look at in the results. They carry no interpretation and compute nothing — the connected AI does the reasoning.
Prompt | Arguments | What it scaffolds |
|
| Review a backtested strategy for robustness: validate → run → compare against buy-and-hold → weigh the evidence base (sample size, significance/robustness statistics, warnings) → caveated summary |
|
| Turn a plain-language idea into a validated strategy: survey the catalogs → fetch the schema → construct → validate-and-fix loop → dry-run |
A full backtest result is megabytes; an agent's context is not. run_backtest and
compare_backtests take response_detail:
summary (default) — headline metrics, warnings, counts, equity endpoints
stats — every metric the plan allows
full — plus series (downsampled, endpoints preserved) and trades (paginated)
run_backtest also takes max_series_points (default 500, must be >= 2) to
override the series downsampling cap — set it higher for full-resolution
series on a long run, or leave it unset for today's default.
include=["trades", "equity_curve", "monthly_returns", "yearly_returns", "signal_diagnostics"] adds specific blocks at any detail level.
signal_diagnostics reports which per-bar entry/exit conditions fired, as a
capped list of fire dates per condition (not the raw per-bar boolean arrays,
which downsampling would corrupt) — or {"available": false, ...} when the
run has no condition tree to evaluate (e.g. precomputed signals). Results
exceeding the output cap are reduced further and explicitly marked
truncated_by_mcp — never silently cut. Shaping only ever selects and thins
what the engine returned; no value is computed or altered.
Designed for agents:
Fixable by changing the request → returned as a normal result: failed validations
arrive as {"valid": false, "errors": [...]} with machine codes and document
locations; engine rejections arrive as {"accepted": false, "error": ...} with a hint.
Not fixable that way → a tool error with explicit guidance: rate limits carry the
Retry-After value; engine-busy says retry with backoff; a compute timeout says
do not retry and reduce scope instead; permission problems name the missing
capability. Engine request ids are included for support.
pip install -e ".[dev]"
pytest # unit suite vs a mock engine — no networkQuestions or feedback? hello@backtest360.com — we read everything. backtest360-mcp is in active development, so help shape it.
Bug reports and feature requests: open an issue on GitHub.
MIT — see LICENSE.
Run several strategies on the same data and compare side by side.
One quota-counted call, but compute scales with the number of strategies. The engine enforces a wall-clock budget for the whole comparison; when it runs out mid-way the response carries "truncated": true and the remaining strategies are missing — report that to the user rather than re-running blindly.
Args: data_source: Shared data source (same shape as run_backtest). strategies: List of {"label": str, "strategy": {...}, "execution": {...}?} entries. include_benchmark: Add a buy-and-hold benchmark to the comparison. response_detail: Shaping level applied to each strategy's result. trades_limit: Max trades per strategy when detail is 'full'.
Returns: {"strategies": [{"label", "result"}, ...], "equity_curves": {...}}, each result shaped at the requested detail. Two truncation flags are distinct and may both appear: the engine's "truncated" (wall-clock budget exhausted mid-comparison — strategies are missing) and the MCP size-cap marker "truncated_by_mcp". A 400/422 rejection returns {"accepted": false, "error": ...}; capacity/timeout/permission failures raise a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| strategies | Yes | ||
| data_source | Yes | ||
| trades_limit | No | ||
| response_detail | No | summary | |
| include_benchmark | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: quota counting, compute scaling, wall-clock budget, truncation mechanisms (engine vs MCP), error response formats, and return structure. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear purpose, Args, and Returns sections. Every sentence adds necessary information without redundancy. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects, output schema), the description covers inputs, outputs, error cases, truncation, and edge conditions. It leaves no critical gap for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description includes a detailed Args section explaining each parameter's meaning and expected structure (e.g., strategies as list of objects, response_detail enum). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run several strategies on the same data and compare side by side'. It uses specific verb 'run' and resource 'strategies', and the comparison aspect differentiates it from sibling tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on quota costing and scaling, and advises against blind re-runs on truncation. However, it does not explicitly specify when to use this tool versus alternatives (e.g., run_backtest) or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the engine's performance metrics from a returns series.
Use when the returns came from somewhere other than run_backtest (an external system, a portfolio) — backtest results already include these statistics.
Args: returns: Per-bar log returns as {"dates": [...], "values": [...]} parallel arrays (ISO-8601 dates). trading_days_per_year: Required annualization factor — 252 for a daily equities calendar, 365 for 24/7 crypto. Must match the bar calendar of the returns series; a wrong value silently mis-annualizes Sharpe, volatility, and CAGR. benchmark_returns: Optional benchmark series, same shape — adds alpha/beta/capture metrics. trades: Optional trade records (entry_date, exit_date, direction, return_net, ...) — adds trade-level metrics. risk_free_rate: Annual risk-free rate as a decimal.
Returns: {"stats": {...}} — the metric set the API key's plan allows. See get_catalog('sections') for every metric's id and description.
| Name | Required | Description | Default |
|---|---|---|---|
| trades | No | ||
| returns | Yes | ||
| risk_free_rate | No | ||
| benchmark_returns | No | ||
| trading_days_per_year | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It discloses that the tool computes stats, warns about silent mis-annualization with wrong trading_days_per_year, explains optional parameters add extra metrics, and notes that return format depends on API key plan. While it doesn't explicitly state read-only nature, the computation-oriented description and lack of side effects make it sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, usage guideline, parameter list, and return type. It is informative without being overly verbose; every sentence adds value. Slightly lengthy but justified by the need to explain multiple parameters and warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary inputs, explains output format (JSON with stats key), and directs to get_catalog for metric details. Since an output schema exists, the description doesn't need to detail every return field. Adequate for a computation tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for each parameter: required format for returns, importance and warning for trading_days_per_year, effects of benchmark_returns and trades, and default for risk_free_rate. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes performance metrics from a returns series, with a specific verb and resource. Explicitly distinguishes from sibling tool run_backtest by noting that backtest results already include these statistics, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use ('Use when the returns came from somewhere other than run_backtest') and implicitly when not to (backtest results already include stats). Names the alternative tool run_backtest, giving clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Engine version, API contract number, and health.
Free (not quota-counted). Call once at the start of a session to confirm the engine is reachable and which contract it serves.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries burden. Discloses free/quota-free nature, which is helpful. Could mention side effects (none) but minimal risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise and informative sentences. Front-loaded with return fields, then usage note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and output schema present, this description sufficiently covers purpose and usage. Would be complete even without schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4 as per guidelines. Description adds no param info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states output: engine version, API contract number, health. Clear verb 'returns' not needed since it's implied. Distinguishes from siblings like compare_backtests, get_catalog, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling once at session start and notes it's free/quota-free. No alternatives mentioned, but context is clear given uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one engine reference catalog.
Catalogs (cheap, cacheable per session):
'operators' — comparison operators for condition expressions
'execution-modes' — entry/exit anchors and fill algorithms, with the validity matrix by market type
'stop-types' — stop-loss types, re-entry modes, and their parameters
'sizing-methods' — position-sizing methods and their parameters
'bar-frequencies' — supported bar frequencies and the signal x execution validity matrix (which combinations are allowed)
'sections' — the full metric catalog: every statistic's stable id, display label, section, and description
Fetch the relevant catalog BEFORE building a strategy or config; build only from values it lists — never guess parameter names or frequencies.
| Name | Required | Description | Default |
|---|---|---|---|
| catalog | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Notes catalogs are 'cheap, cacheable per session', implying a read-only, non-destructive operation. No annotations provided, but description adequately covers behavior. Lacks explicit statement of being read-only, but strong implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear list, but somewhat verbose with bullet points; still front-loaded and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a catalog retrieval tool: explains purpose, when to use, what each catalog contains, and references output schema. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 0%, the description adds detailed semantics for the 'catalog' enum values, explaining exactly what each catalog contains, far beyond the schema's minimal representation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches one engine reference catalog, enumerates each possible catalog and its content, distinguishing it from sibling tools like run_backtest or search_tickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to fetch before building a strategy, never guess parameter names or frequencies, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Available date range and estimated bar count for a symbol/frequency.
Available on paid plans. Call before a server-side fetch so the requested start/end stay inside what the provider can deliver and the bar count stays inside the key's per-run limit.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| frequency | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral context. It discloses that it is available only on paid plans and hints at its non-destructive nature by suggesting it be used for pre-fetch validation. It could mention if the tool is read-only, but the intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two efficient sentences plus a note. It front-loads the core purpose and adds actionable guidance without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers the essential context: what the tool retrieves, when to use it, and plan requirements. Minor gaps in parameter details exist but are offset by low parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely references 'symbol/frequency' without further explanation of format or constraints, leaving the agent to infer from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns available date range and estimated bar count for a given symbol/frequency. It is distinct from sibling tools like 'compare_backtests' or 'run_backtest' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises calling this tool before a server-side fetch to ensure parameters stay within provider limits, providing clear context. However, it does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate the strategy on the most recent bar only — no P&L, no stats.
Returns the latest signal (-1/0/1), which condition slots fired, and the bar timestamp. Use for "what would this strategy do right now" questions; use run_backtest for performance.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy | Yes | ||
| execution | No | ||
| data_inputs | No | ||
| data_source | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses that no P&L or stats are computed, and returns only signal, conditions, and timestamp. While it doesn't explicitly state read-only behavior, the context implies it is a query without side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and then list return values. Every sentence is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good purpose and usage guidance, the description lacks parameter explanations and does not leverage the output schema (which exists) to detail return format. Given the complexity of four object parameters, this gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 4 parameters (2 required), all objects with additionalProperties: true, and schema description coverage is 0%. The description does not explain any of these parameters (e.g., what 'strategy', 'execution', 'data_inputs', 'data_source' contain or how to use them). It fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool evaluates strategy on the most recent bar only, returning a signal (-1/0/1), condition slots, and timestamp. Distinguishes itself from run_backtest, which is for performance analysis, thus specifying the resource and action effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for 'what would this strategy do right now' questions) and when to use an alternative (use run_backtest for performance). This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The configured API key's permissions, limits, and current usage.
Cheap. Call early in a session — before planning work — to learn what this key can do instead of discovering limits through failed calls.
Returns:
scopes: the permission scopes the key carries. limits:
requests per minute and per day, max concurrent requests, and the
per-run bar cap (null when uncapped). usage: current
consumption against those limits, with reset countdowns in
seconds. capabilities: feature flags such as server-side data
fetch and the full metric set. A small fixed-shape record,
returned as the engine sent it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It does so by detailing the return shape (scopes, limits, usage, capabilities) and noting that the call is cheap and returns a fixed-shape record. No side effects or destructive actions are implied, and the description is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, a usage tip, and a bulleted list of return fields. While it is somewhat verbose, every sentence adds value, and it avoids redundancy. Slightly more conciseness could be achieved, but it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and the presence of an output schema (implied by the return description), the description is complete. It explains what the tool does, when to use it, and exactly what it returns, covering all necessary context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description adds no parameter information, which is appropriate. With zero params, a baseline of 4 is given per calibration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the configured API key's permissions, limits, and current usage. It uses a specific verb ('get') and resource ('me'), and the returned fields are enumerated. Among siblings, it uniquely provides authentication context, distinguishing it from tools like engine_info or get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling early in a session before planning work, to avoid discovering limits through failed calls. It labels the tool as 'Cheap,' suggesting low cost, which guides when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JSON Schema for the strategy document (condition_tree + indicators).
Fetch this before composing a strategy by hand; the validate_strategy tool checks against the same rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but implies a read operation, mentioning 'fetch' and no side effects. It could explicitly state it's read-only, but for a simple schema retrieval, it's adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no fluff. Every sentence earns its place by stating what the tool does and why to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, output schema present, and no complexity, the description fully covers the tool's purpose and usage context. It ties to validate_strategy for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4 per guidelines. The description does not need to add param info, and schema coverage is 100% vacuously.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a JSON schema for a strategy document, specifying condition_tree and indicators, and distinguishes from sibling validate_strategy by mentioning the shared rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to fetch this before composing a strategy manually, and references validate_strategy as a sibling that checks against the same schema, providing clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List indicators, or fetch one indicator's full schema.
Cheap, cacheable per session.
With no arguments: a compact catalog — {"indicators": [...], "count": N} — where each entry carries id, name, category, kind,
and value_dtype (no description, to keep the discovery scan small). Use
it to discover what exists. Pass name='rsi' (id or name,
case-insensitive) to get that single indicator's complete entry
including its description and params_schema — do this before adding an
indicator to a strategy so its parameters are exactly right.
Pass compact=False for full entries for everything (large; the MCP
server may cap it and set truncated_by_mcp — prefer compact or
name=).
Wire optimization: the compact discovery path asks the engine to omit
per-entry descriptions (descriptions=false) since they are stripped
locally anyway; the name= and compact=False paths request them. This is
a pure saving — if the engine ignores the param it returns full entries
and the local compact strip still yields a lean result.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| compact | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it is cheap, cacheable per session, and explains the compact strip behavior, wire optimization, and potential MCP server truncation. No annotations provided, but description compensates well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but the wire optimization paragraph is somewhat technical and could be more concise. Overall, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description explains return values for both modes, including the truncated_by_mcp flag. It adequately covers the dual behavior and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning to both parameters: name (optional, case-insensitive, example shown) and compact (default true, effects explained). Thoroughly compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists indicators or fetches one indicator's full schema, with specific mention of compact and detailed modes. However, it does not explicitly distinguish it from sibling tools like get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use compact mode for discovery and when to use name= for obtaining a full schema before adding to a strategy. Also explains wire optimization but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List predesigned strategy templates, or fetch one in full.
Cheap, cacheable per session. The engine returns the templates available to the calling key.
With no arguments: a compact catalog — {"templates": [...], "count": N} — where each entry carries id, origin, name, and
description. Use it to discover what exists. Pass name='sma-cross'
(id or name, case-insensitive) to get that single template's complete
entry: its strategy logic (condition_tree + indicators, the
same shape validate_strategy and run_backtest accept) plus parameter
metadata — defaults (starting parameter values), requires,
and locked_params (parameters that must keep their template
values). Pass compact=False for complete entries for everything
(large; the MCP server may cap it and set truncated_by_mcp —
prefer compact or name=).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| compact | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It discloses the tool is 'Cheap, cacheable per session,' explains that results are scoped to the calling key, details the return formats for both argument modes, and warns about potential truncation with truncated_by_mcp. No behavioral contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured. It leads with the core purpose, then uses sub-sections for different argument scenarios. While every sentence adds value, it could be slightly more compact without losing clarity. Overall, it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the tool's dual-mode behavior, the description is remarkably complete. It covers return shapes for both modes, parameter details, truncation warnings, and even mentions that results are per-API-key. No missing essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It does so thoroughly: for name, it explains it is optional, case-insensitive, accepts id or name, and triggers a full fetch of a single template. For compact, it notes the default (true) and the behavior when false (complete entries but may be capped). This far exceeds the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'List predesigned strategy templates, or fetch one in full.' It specifies the resource (strategy templates) and the two distinct modes (compact listing vs. full fetch). This differentiates it from sibling tools like run_backtest or validate_strategy, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use it to discover what exists' for the no-argument case, and 'Pass name=...' to fetch a single template in full. It also advises preferring compact or name to avoid truncation. However, it does not explicitly mention when not to use this tool or name alternatives, but the guidance is clear enough for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available tickers, optionally filtered by asset class.
The full universe is very large, so the MCP server
caps the returned list and marks it truncated_by_mcp — pass
asset_class to narrow it, or use search_tickers to resolve a specific
asset by name.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_class | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the list is capped and marked truncated_by_mcp, which is a key behavioral trait. However, it could mention the exact cap or any rate limits, but the explanation is still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficient, and front-loaded with the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with one optional parameter and an output schema, the description covers purpose, filtering, truncation warning, and alternative tool. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the asset_class parameter's purpose and suggests using it to narrow results, adding necessary context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available tickers with optional filtering by asset class, and distinguishes itself from search_tickers by noting the latter is for resolving a specific asset by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to pass asset_class to narrow the list or use search_tickers for a specific asset, providing clear context on when to use this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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) — adds benchmark-relative metrics. 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 summary/stats detail: 'trades', 'equity_curve', 'monthly_returns', 'yearly_returns'. trades_limit: Max trades returned when trades are included.
Returns:
The shaped result at the requested detail; 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.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | ||
| signals | No | ||
| strategy | No | ||
| benchmark | No | ||
| execution | No | ||
| data_inputs | No | ||
| data_source | Yes | ||
| trades_limit | No | ||
| response_detail | No | summary |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: quota-counted, compute-bound, error handling for 400/422/401/403/429/503/504, return truncation, and error recovery guidance. It does not explicitly state idempotency or side effects, but the detail is high.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main paragraph, error guidance, parameter list, and return explanation. It is front-loaded with the core purpose. However, it is slightly verbose, though every sentence carries useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, output schema present), the description covers purpose, usage guidelines, behavioral transparency, parameter semantics, and return values comprehensively. It addresses error scenarios and recovery, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter descriptions, but the description compensates with detailed explanations for all 9 parameters, including mutual exclusivity of strategy/signals, data_source options (inline vs server-side), execution defaults, response_detail enum meanings, and include options. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a historical backtest against the engine' and distinguishes it from the cheaper `validate_strategy`. It explains the tool's primary verb and resource, and the context signals confirm uniqueness among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: validate first with `validate_strategy`. It advises against retrying on 504 errors and recommends reducing date range or simplifying strategy. On 429/503, it instructs to wait for Retry-After. Alternatives like `compare_backtests` and `get_catalog` are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search available assets by ticker or name (relevance-ranked).
Use to resolve a user's asset mention ("bitcoin", "S&P") to the exact ticker before requesting a server-side data fetch. asset_class filters to 'stocks', 'crypto', 'forex', or 'indices'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| asset_class | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses relevance-ranked search and acceptable values for asset_class. It does not cover pagination or error behavior, but given the existence of an output schema, the behavioral context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a brief example, all front-loaded with the core purpose. No wasted words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with an output schema, the description covers purpose, filter usage, and the typical workflow step. It is mostly complete, though it could mention case sensitivity or partial matching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description adds essential meaning: query is a user mention, asset_class filters to specific values ('stocks', 'crypto', etc.), and limit has a default. This is sufficient but could elaborate on query format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches available assets by ticker or name with relevance ranking, and specifies the use case of resolving user mentions to exact tickers before data fetch. This distinguishes it from siblings like list_tickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use the tool ('to resolve a user's asset mention... before requesting data'), implying it is a preliminary step. It does not explicitly state when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a strategy document without running a backtest.
A cheap quota separate from backtest runs, so validate freely and ALWAYS before run_backtest.
Args: strategy: The strategy document — name, indicators[], and condition_tree (see get_strategy_schema for the exact shape). injected_indicators: Names of custom time-series columns the caller will supply via data_inputs at run time, so conditions referencing them validate.
Returns: On success: {"valid": true, "warmup_bars": ..., referenced indicators/columns}. On failure: {"valid": false, "errors": [...]} where each error carries a machine code, the location in the document, a message, and context (e.g. the list of valid column names). A failed validation is a NORMAL result, not an error — read the errors, fix the document, and validate again before running.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy | Yes | ||
| injected_indicators | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it's a cheap, separate-quota validation that returns success/failure without running a backtest. It clarifies failed validation is a normal result, not an error, and details the return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a one-line summary, usage note, Args, and Returns. Every sentence adds value without redundancy. It's appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (validating a strategy with indicators and conditions), the description covers purpose, parameters, return values (including error format), and usage context (cheap quota, reference to schema). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds rich meaning: explains strategy document structure (name, indicators, condition_tree) and injected_indicators purpose (custom columns supplied at runtime). This compensates fully for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a strategy document without running a backtest, distinguishing it from the sibling run_backtest. The verb 'validate' and resource 'strategy document' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'validate freely and ALWAYS before run_backtest,' providing clear when-to-use guidance. References get_strategy_schema for shape details, and mentions cheap quota to encourage frequent use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0compare_backtestscompute_statsengine_infoget_catalogget_data_rangeget_latest_signalget_meget_strategy_schemalist_indicatorslist_templateslist_tickersrun_backtestsearch_tickersvalidate_strategyEach tool has a clearly distinct purpose: validation, backtest execution, comparison, statistics, catalog browsing, ticker search, etc. Overlaps are minimal and clearly differentiated (e.g., get_latest_signal returns current signal only, run_backtest returns full performance).
All tool names follow a consistent verb_noun pattern in snake_case (e.g., validate_strategy, run_backtest, list_indicators). No mixing of conventions like camelCase or inconsistent verb styles.
14 tools is well within the 3-15 ideal range. Each tool serves a necessary function for the backtesting domain—validation, execution, analysis, discovery—without bloat or missing essentials.
Covers the core backtesting workflow: strategy creation (schema, validation), execution (run, compare, signal), data discovery (tickers, range), and analysis (stats). Minor gaps: no tool for editing saved strategies or managing user settings, but these are peripheral to the server's main purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Research-only MCP server: turn your AI into a quant research desk — backtests, no trades.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Backtest360/backtest360-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
