Backtest360
Server Details
MCP server exposing the Backtest360 engine API as tools for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 12 of 12 tools scored. Lowest: 3.8/5.
Each tool targets a distinct operation: running backtests, comparing strategies, computing stats, fetching catalogs, validating schemas, etc. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., run_backtest, get_catalog, list_indicators) with no deviations.
12 tools is well-scoped for a backtesting server, covering discovery, validation, execution, and analysis without redundancy or bloat.
The tool set covers the full lifecycle: strategy schema retrieval, validation, data range checks, backtest execution, comparison, stats computation, and engine health—no obvious gaps.
Available Tools
12 toolscompare_backtestsAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully assumes the burden of disclosure. It details quota counting, compute scaling, wall-clock budget, truncation behavior (two distinct flags), and error handling (400/422 vs tool error). This is comprehensive and beyond basic expectations.
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 brief opening, separate paragraphs for behavior, Args, and Returns. It is informative but slightly lengthy due to detailed truncation and error explanations; however, every 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 the tool's complexity (5 parameters, nested objects, output schema with truncation flags), the description covers all essential aspects: purpose, parameter details, return format, and error scenarios. It is fully adequate for an AI agent to select and invoke the tool correctly.
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 fully describes all 5 parameters: data_source (referencing run_backtest), strategies (format), include_benchmark, response_detail, and trades_limit. This adds significant meaning beyond the raw schema, which only has titles and default values.
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 several strategies on the same data and compare side by side,' which is a specific verb+resource combination. It distinguishes from siblings like run_backtest (single strategy) and other tools, making its 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?
The description explains when to use the tool (comparing multiple strategies) and provides important context about compute scaling and wall-clock budget. It advises against re-running blindly when truncation occurs. However, it does not explicitly contrast with alternatives like compute_stats or run_backtest, leaving some implicit inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_statsAInspect
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).
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.
trading_days_per_year: Annualization factor.
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 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description explains the input format (log returns, parallel arrays), the effect of optional parameters (benchmark adds alpha/beta/capture, trades adds trade-level metrics), and that the output metric set depends on the API key's plan. Could mention idempotency or error conditions but covers key behavioral traits.
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 concise, front-loaded with the core purpose, and uses a clear parameter list format. Every sentence adds value, with no redundancy or fluff.
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 5 parameters, nested objects, and no annotations but an output schema reference, the description covers when to use, parameter details, and points to get_catalog for metric definitions. Completeness is high for a compute tool.
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 schema description coverage at 0%, the description provides detailed semantics for all 5 parameters: format of returns, optional benchmark and trades, decimal risk-free rate, and annualization factor. Adds meaning beyond the schema's type and default values.
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 computes performance metrics from a returns series, and distinguishes it from run_backtest which already includes these statistics. The verb 'compute' and resource 'performance metrics' are specific and 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?
Explicitly states when to use: when returns come from external systems or portfolios, and when not: backtest results already include statistics. Provides clear alternatives context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
engine_infoAInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is free, not quota-counted, and suitable for one-time use. It implies a read operation 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?
The description is extremely concise: two sentences with no filler. The first sentence lists the return fields; the second provides usage context. Every word is useful.
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 that there is an output schema (though not shown) and the tool is simple, the description is complete. It covers what the tool does, when to use it, and cost implications. A minor gap is lack of specifics about the output format, but the schema likely handles that.
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?
There are zero parameters, so the baseline is 4. The description adds value by explaining the purpose and return values, which is more than the schema alone provides (an empty object).
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 explicitly states it returns engine version, API contract number, and health. It also clarifies its usage (call once at session start). This clearly distinguishes it from sibling tools, which all involve different operations like backtesting or searching.
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 gives clear guidance: call once at the start of a session and that it's free (not quota-counted). It does not explicitly mention when not to use or alternatives, but for a unique info tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalogAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes catalogs as 'cheap, cacheable per session', implying low cost and read-only nature. While no annotations exist, the description adds useful behavioral context, though it could explicitly state no destructive side effects.
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?
Concise single opening sentence followed by a clean bullet list. Every sentence adds value with no redundancy or filler.
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 simple one-parameter tool with an output schema, the description covers all necessary context: catalog purposes, caching behavior, and a critical usage rule. Complete and self-contained.
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 single parameter 'catalog' has an enum, and the description explains each enum value's content in detail, providing meaning far beyond the schema (which had 0% coverage).
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 'Fetch one engine reference catalog' and lists the six distinct catalogs with their contents, making the tool's purpose unmistakable and distinct from siblings 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 instructs to fetch the catalog 'BEFORE building a strategy or config' and warns 'never guess parameter names or frequencies', providing clear when-to-use and a crucial caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_data_rangeAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool requires a paid plan and imposes a per-run bar count limit, which is useful behavioral context. The description does not contradict any annotations (none exist) and adds value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and well-structured: the first sentence states the purpose, the second provides usage advice. It is efficient, though it could be slightly more concise.
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 tool with 2 required parameters and an output schema, the description is adequate but not complete. It explains what the tool returns (date range and bar count) and when to use it, but lacks param details. The output schema likely provides return structure, so the description meets minimal needs.
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 0% description coverage, meaning the description must compensate. However, it only mentions 'symbol/frequency' in passing without detailing valid values, formats, or constraints. This leaves the agent with limited guidance on how to populate the required parameters.
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 tool name 'get_data_range' and description clearly state it retrieves the available date range and bar count for a given symbol and frequency. It is distinct from siblings like 'compute_stats' 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 explicitly advises calling this tool before a server-side fetch to ensure start/end dates are within provider limits and bar count stays within per-run limits. It also mentions availability on paid plans, giving clear context for when to use. However, it does not specify when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latest_signalAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it only uses the most recent bar, returns no P&L/stats, and outputs specific fields. With no annotations, it carries the full burden and does so adequately, though it could mention any side effects or prerequisites.
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 three sentences, front-loaded with the main purpose, and every sentence adds value without repetition or fluff.
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 an output schema present, return values are covered. However, the lack of parameter explanations and the tool's involvement of nested objects (strategy, data_source) means the description is not fully complete 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% for 4 parameters. The description does not explain the purpose or format of parameters like strategy, execution, data_inputs, or data_source, leaving the agent to rely on parameter names alone.
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 evaluates the strategy on the most recent bar and returns the latest signal, condition slots, and timestamp. It distinguishes from the sibling run_backtest by explicitly contrasting uses.
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 gives explicit guidance: use for 'what would this strategy do right now' questions, and use run_backtest for performance. This clearly indicates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_strategy_schemaAInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only, non-destructive operation. It adds context about the relationship with validate_strategy, though it could mention that no side effects occur. Still, it's sufficient for this simple tool.
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, front-loaded with the core purpose followed by a usage hint. No wasted wording.
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?
Tool has an output schema, so return value is covered. Description explains its role in the strategy creation workflow and references the validation sibling, making it complete for its simplicity.
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 schema coverage is 100%. Description adds no param info, but none is needed. Baseline for 0 params is 4.
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 returns the JSON Schema for the strategy document, specifying it covers condition_tree and indicators. Distinguishes from siblings like validate_strategy by indicating it is for previewing rules before validation.
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 to fetch this before composing a strategy by hand, and notes that validate_strategy checks against the same rules, providing clear context on when to use this tool versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_indicatorsAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: cheap/cacheable, response format, compact vs. full, potential truncation (truncated_by_mcp), and wire optimization (descriptions=false).
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 lengthy with technical wire optimization details that may not be essential for an AI agent. Well-structured but could be trimmed for conciseness.
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 no output schema, description covers return format, dual behavior, caching, and truncation. Adequate for correct usage, though output schema would further enhance 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?
Schema coverage 0%, but description fully explains both parameters: name accepts id or name (case-insensitive), compact defaults to true and toggles response detail. Provides concrete examples.
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 lists indicators or fetches a single indicator's full schema. It distinguishes two modes (compact catalog vs. detailed entry via name argument) and contrast with sibling tools like get_strategy_schema.
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 tells when to use each mode: discovery with no args, preparation before adding indicator with name=, and full listing with compact=False. Lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tickersAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the critical truncation behavior (capped list, marked truncated_by_mcp), adding value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, highly informative sentences with no wasted words; the main action is front-loaded.
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 simplicity (one optional param, output schema exists), the description covers usage, limitations, and alternatives adequately.
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 explains the parameter's purpose (optional filter) and suggests its use to narrow results, compensating for the lack of schema details.
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 'List available tickers' with an optional filter by asset class, distinguishing it from sibling tool '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 says when to use filtering and directs to search_tickers for specific asset resolution, plus warns about truncation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_backtestAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses quota-counting, compute-bound nature, timeout handling, truncation of oversized results (truncated_by_mcp), and error response shapes. 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?
Well-structured with paragraphs, Args list, and Returns. Front-loaded with key info. Slightly verbose due to detailed parameter descriptions, but justified by 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 complexity (9 params, nested objects, output schema exists), the description covers purpose, usage, all parameters, return value, error handling, and truncation. Complete.
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 has 0% description coverage, but the description details all 9 parameters in the 'Args' section, including mutual exclusivity, default values, and expected shapes, fully compensating.
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', uses a specific verb and resource, and distinguishes from siblings by mentioning the cheaper validate_strategy alternative.
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 guidance on when to use (for backtesting) and mentions validate_strategy as a cheaper alternative. Explicit error handling instructions for 504, 429, 503. Lacks explicit when-not scenarios, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_tickersAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions relevance ranking and asset_class filter but omits side effects, rate limits, or confirmation of read-only nature.
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 brief and front-loaded: first line gives core action, second line provides usage context, third line adds parameter detail. No redundant sentences.
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 output schema present, return format explanation is unnecessary. Description covers purpose, usage, and one parameter; lacks mention of pagination or empty results, but overall adequate.
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%, so description must add value. It details asset_class filter values ('stocks', 'crypto', etc.) but offers no specifics on query or limit format/length.
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 'Search available assets by ticker or name (relevance-ranked).' It specifies verb, resource, and ordering, distinguishing it from sibling 'list_tickers' which likely lists all without search.
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 using this tool to resolve user asset mentions before data fetch, providing clear context. It does not exclude other uses but implies list_tickers for browsing, which is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_strategyAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that validation is cheap, uses a separate quota, and does not run a backtest. It clearly describes return values for both success and failure, noting that failed validation is a normal result. It does not mention rate limits or quota details, but overall provides good behavioral context.
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 three paragraphs: purpose, args, returns. It front-loads the purpose and key guidance. While slightly long, every sentence adds value. It could be slightly more terse, but the structure is clear.
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 (implied by the return description), the explanation of return values is sufficient. The description references get_strategy_schema for exact shape, covering the complexity of the strategy object. With two parameters (one optional) and a nested object, the description provides adequate context for usage.
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 thoroughly explains the 'strategy' parameter by listing its components (name, indicators[], condition_tree) and directs to get_strategy_schema for the exact shape. The 'injected_indicators' parameter is explained as custom column names for runtime injection. This adds significant 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?
The description clearly states it validates a strategy document without running a backtest, distinguishing it from the sibling tool run_backtest. The verb 'validate' and resource 'strategy document' are specific, and the phrase 'cheap quota separate from backtest runs' adds differentiation.
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 use this tool before run_backtest ('validate freely and ALWAYS before run_backtest'). It mentions get_strategy_schema for understanding the strategy shape, which provides context. However, it does not explicitly state when not to use it or list alternatives beyond run_backtest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!