Backtest360
Server Details
MCP server exposing the Backtest360 engine API as tools for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Backtest360/backtest360-mcp
- GitHub Stars
- 0
- Server Listing
- backtest360-mcp
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 20 of 20 tools scored. Lowest: 3.8/5.
Every tool targets a distinct operation or resource: backtesting, comparison, macro data, reference catalogs, etc. Even similar tools like run_backtest and compare_backtests are clearly differentiated by purpose and inputs.
Overall consistent verb_noun pattern in snake_case, with a few exceptions like engine_info (noun_noun) and export_backtest (verb_noun but less common verb). The pattern is predictable and aids agent selection.
20 tools is slightly above the ideal range but justified by the breadth of the platform (backtesting, data retrieval, reference, export). Each tool serves a clear purpose without redundancy.
Covers the full backtesting lifecycle: strategy validation, data sourcing, backtesting, comparison, export, and reference lookups. Minor gaps exist (e.g., no explicit strategy persistence), but the core workflow is complete.
Available Tools
20 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. If the wall-clock compute budget is exceeded, the call
fails with a tool error (504) instead of returning partial results —
narrow the request (fewer strategies, shorter date range, coarser
frequency) and retry.
Args:
data_source: Shared data source (same shape as run_backtest).
strategies: List of {"label": str, "strategy": {...},
"execution": {...}?} entries. Labels need not be unique or
id-safe — they are echoed back verbatim in the result.
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": {...},
"alignment"?}, each result shaped at the requested detail. When a
benchmark is included, non-benchmark entries also carry
"relative" (beta, alpha, information ratio, etc.). 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 discloses behavior: one quota-counted call, compute scaling with number of strategies, failure mode (504 on budget exceed), error responses, and return shape. It 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 and front-loaded with the purpose, but is somewhat verbose with details that could be more concise. Still, every section 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), the description covers all essential aspects including edge cases, failure modes, and return values. It is 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 description coverage is 0%, yet the description adds meaning for all five parameters: explains data_source shape, strategies as list of objects with label and strategy, include_benchmark purpose, response_detail shaping, and trades_limit. It clarifies that labels need not be unique.
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 purpose: 'Run several strategies on the same data and compare side by side.' It uses a specific verb and resource, and distinguishes itself from siblings like 'run_backtest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for usage, such as quota counting and compute scaling, and advises what to do on failure: 'narrow the request (fewer strategies, shorter date range, coarser frequency) and retry.' It does not explicitly name alternatives but implies comparison vs single strategy runs.
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).
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 |
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. Description discloses that computation depends on parameter correctness (e.g., mis-annualization if wrong trading_days_per_year). It is read-only in nature but does not explicitly state side effects; however, the context implies no mutation.
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 Args list and Returns section. Slightly verbose but every sentence provides value. Front-loads purpose and usage.
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 annotations, 5 parameters, and 0% schema coverage, the description covers essential behavioral details and parameter semantics. References get_catalog for metric descriptions, compensating for not detailing output 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?
Schema description coverage is 0%, but description provides detailed semantics for each parameter: returns format, trading_days_per_year annualization factor, optional benchmark/trades, and risk_free_rate decimal. Adds significant meaning beyond 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?
Clear verb 'compute' and resource 'performance metrics' from returns series. Distinguishes from sibling run_backtest by specifying when to use this tool instead.
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 (returns from external systems/portfolio) and when not (backtest results already include stats). Also provides specific guidance on trading_days_per_year parameter and its impact.
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.
export_backtestAInspect
Export a multi-strategy comparison as an Excel workbook.
Quota-counted; needs a key whose plan includes full-metrics export
(a 403 means the configured key's plan does not — do not retry).
Returns the workbook base64-encoded — decode and write it to a
``.xlsx`` file.
Args:
data_source: Shared data source (same shape as run_backtest).
strategies: Same shape as compare_backtests' ``strategies``.
include_benchmark: Add a buy-and-hold benchmark to the export.
Returns:
{"filename", "content_type", "size_bytes", "content_base64"}. A
400/422 rejection returns {"accepted": false, "error": ...};
capacity/timeout/permission failures raise a tool error. If the
encoded workbook would exceed the output size limit, raises a
tool error — narrow the request (shorter date range, fewer
strategies, coarser frequency) and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| strategies | Yes | ||
| data_source | Yes | ||
| 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 discloses behavioral traits: quota-counted, plan requirement, base64 encoding, return shape, and error types (400/422, capacity/timeout/permission, size limit). 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?
Front-loaded with purpose, then structured bullet-style for arguments and return shape. Clear and efficient, though slightly longer than necessary due to referencing other tool shapes.
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 3 params, no annotations, and an output schema implied by the return shape description, the description is complete: explains inputs, output, error scenarios, and size limit handling.
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 description adds meaning for all three params: data_source (same shape as run_backtest), strategies (same shape as compare_backtests' strategies), and include_benchmark (adds benchmark). Relies on referencing other tool shapes, which is helpful but not fully self-contained.
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 starts with a specific verb and resource: 'Export a multi-strategy comparison as an Excel workbook.' This clearly distinguishes it from siblings like run_backtest (runs backtest) and compare_backtests (compares but does not export).
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 prerequisites (key plan with full-metrics export) and error handling (403, size limit), but does not explicitly compare with siblings or state when to use this vs. alternatives like compare_backtests.
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
- 'sampling-modes' — Monte-Carlo resampling modes, each with its
status and parameters
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?
No annotations are provided, so the description carries the full burden. It notes that catalogs are 'cheap, cacheable per session,' which indicates performance characteristics and reusability. However, it does not mention error conditions or permission requirements, but for a read-only lookup tool this 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?
The description is well-structured with a clear opening sentence and bulleted list. It is slightly verbose but every sentence adds value, and the key instruction is front-loaded. 'Never guess parameter names or frequencies' is a strong behavioral cue.
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 simple single-parameter tool with an output schema (not shown), the description covers all necessary information: purpose, parameter options, usage timing, and behavioral hints. It is fully sufficient for an agent to invoke 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?
Despite 0% schema description coverage, the description thoroughly explains each enum value in the 'catalog' parameter, detailing exactly what data each catalog contains. This adds significant meaning beyond the enum 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 starts with 'Fetch one engine reference catalog' which clearly states the verb and resource. It then lists all catalog options with specific contents, distinguishing this tool from siblings like list_indicators or 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?
The description explicitly instructs to fetch the catalog before building a strategy or config, and to only use values listed, with a strong caution against guessing. This provides clear when-to-use and what-not-to-do guidance.
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_macro_seriesAInspect
Observations for one macroeconomic series over an optional date range.
Free — no special plan. ``series`` is an ``id`` from list_macro_series
(e.g. treasury_10y, cpi, unemployment_rate); arbitrary external ids are
not accepted. ``start``/``end`` are ``YYYY-MM-DD``, inclusive, both
optional (full history when omitted). Returns the value series at its
native reporting frequency, with the series descriptor and an ``as_of``
date. A long history is downsampled by the MCP server to a bounded
number of points (first and last kept), marked with
``downsampled_from_bars`` and ``points_returned`` on the
``observations`` block.
Note: values are the latest revised figures stamped by reference period,
not point-in-time as-first-reported data — do not treat them as the
values that were known at a past date.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| series | 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 provided, so description carries full burden. Discloses downsampling behavior, marking, and that values are revised figures not point-in-time. No contradictions with 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?
Well-structured with clear paragraphs. Slightly verbose (e.g., downsampling details could be tightened), but every sentence adds value and front-loads the main 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?
Output schema exists but not provided; description compensates by detailing return structure (value series, descriptor, as_of, downsampling markers). Covers most relevant aspects for a parameter 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?
Schema coverage is 0%, but description fully explains each parameter: 'series' must be a valid ID from list_macro_series with examples; 'start'/'end' are YYYY-MM-DD, optional, inclusive. Adds significant meaning beyond 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 verb 'get' and resource 'macro series' with specific purpose: observations over date range. Distinguishes from siblings like list_macro_series by specifying it retrieves observations for a single series.
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?
Explains that the series ID must come from list_macro_series, provides example IDs, and describes date format and optionality. Lacks explicit when-not-to-use or alternatives, but context signals allow inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_meAInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden and delivers. It explains the tool is cheap, returns scopes, limits, usage, and capabilities, and describes the data as a small fixed-shape record. 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 well-structured: main purpose first, usage guidance, then detailed return format with bullet points. No extraneous text.
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 and an output schema, the description fully explains the return structure and behavior. It is complete for this simple 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?
The tool has no parameters, so schema coverage is 100%. The description adds no parameter info but it's unnecessary. Baseline is 4, and completeness earns a 5.
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 returns the API key's permissions, limits, and current usage. The verb 'get' and resource 'me' are well-defined, distinguishing it from sibling tools that deal with market data or backtesting.
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 guidance: 'Cheap. Call early in a session — before planning work — to learn what this key can do instead of discovering limits through failed calls.' This tells the agent exactly when and why 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.
get_price_historyAInspect
OHLCV price history for a symbol over a date range.
Requires a paid plan (managed market data). ``start`` is required
(``YYYY-MM-DD``); ``end`` defaults to today. Returns a summary (symbol,
resolved date range, total bar count, price range, gap flags),
market-hours detection, and the OHLCV arrays. A long history is
downsampled by the MCP server to a bounded number of points — first and
last bar always kept, every column thinned on the same dates — with
``downsampled_from_bars`` and ``points_returned`` recorded on the
``ohlcv`` block; the untouched ``summary.total_bars`` still reports the
true bar count. The window is bounded by the plan's per-request bar cap
— call get_data_range first to size a request.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | Yes | ||
| symbol | Yes | ||
| frequency | No | daily |
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 exist, so description carries full burden. It discloses downsampling behavior, that first/last bars are kept, how thinning works, and that summary.total_bars is true count. Also mentions plan bar cap and 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 sufficiently concise, front-loaded with purpose, and every sentence adds meaningful information without redundancy. No wasted 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?
Tool has 4 params and an output schema; description covers prerequisites, parameter behavior, return components, downsampling, and cap. References sibling tool for sizing. Complete for intended use.
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%. Description explains start (required, YYYY-MM-DD) and end (defaults to today) but does not mention symbol or frequency parameter details. Partial compensation leaves gaps for half the 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 description clearly states it returns OHLCV price history for a symbol over a date range, specifying what it does and key return components (summary, OHLCV arrays). It distinguishes from siblings like get_data_range by mentioning sizing requests.
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 usage guidance: requires a paid plan, start is required with date format, end defaults to today, and advises calling get_data_range first to size requests. Lacks explicit 'when not to use' but offers practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteAInspect
Latest available price for a symbol.
Requires a paid plan (managed market data). Returns the most recent
*available* bar for the given frequency — the end-of-day close for
daily, the last completed bar otherwise — as open/high/low/close/volume
plus an ``as_of`` timestamp for that bar. This is a last-known price,
not a live tick; read ``as_of`` to judge how stale it is.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| frequency | No | daily |
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 carries the full burden and does well by explaining it is not a live tick, includes an as_of timestamp for staleness, and returns OHLCV data. It does not cover rate limits or permissions beyond the paid plan, but adds substantial 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 concise with a clear first line and detailed second paragraph. Every sentence adds value with no wasted 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?
Given the presence of an output schema and sibling tools like get_price_history, the description covers the main points. It could have mentioned the alternative for historical data, but is otherwise complete for a quote 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?
The input schema has 0% description coverage, yet the description fully compensates by explaining how the symbol and frequency parameters affect the returned bar (e.g., end-of-day close for daily, last completed bar otherwise). It adds 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 returns the latest available price for a symbol, which is a specific verb+resource. It implies a snapshot compared to historical data from siblings, but does not explicitly contrast with get_price_history.
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 mentions a paid plan requirement and explains the return behavior, but does not explicitly state when to use this tool over alternatives like get_price_history or when not to use it. Usage is implied rather than directed.
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.
get_ticker_infoAInspect
Identity and data coverage for one symbol, in a single call.
Metadata only — no market data, so no paid plan is needed. Returns the
asset's identity (name, asset class, exchange, currency, and whether it
is still active) together with a coverage summary for the given
frequency: the available date range and an estimated bar count. Use it
to confirm a symbol resolves and that the history you need exists before
requesting a quote or a price fetch. For the precise per-frequency range
use get_data_range.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| frequency | No | daily |
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, description carries full burden. Discloses metadata-only nature, no market data, free, returns identity and coverage summary with date range and bar count estimate. Does not describe error handling or rate limits, which limits score slightly.
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 main purpose upfront and supporting details. Slightly verbose but each sentence adds value. Could be trimmed by 10-15% without loss.
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 presence of output schema (not shown), return values need not be described. Covers essential aspects: identity fields, coverage summary (date range, bar count). Adequate for a 2-parameter 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 coverage 0%, so description must compensate. Explains symbol as ticker and frequency with default 'daily', but does not list valid frequency values or hint at constraints. Adds meaning beyond schema but leaves gaps.
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 states it provides identity and data coverage for one symbol, distinguishing it from siblings like get_data_range (precise per-frequency range) and get_price_history (market data). Uses specific verb 'confirm a symbol resolves and history exists.'
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?
Clear context: use before requesting a quote or price fetch, no paid plan needed. Implies alternative get_data_range for precise ranges but does not explicitly list when not to use.
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_macro_seriesAInspect
List the available macroeconomic series (the catalog).
Free — no special plan. Returns the set of macro series you can fetch
with get_macro_series, each with its stable ``id`` (the value
get_macro_series takes), title, category, native reporting frequency,
and units, plus the list of categories. Optionally filter to one
``category`` (e.g. rates, yield_curve, inflation, employment, recession,
growth). Call this first to find the ``id`` for the series you want.
| Name | Required | Description | Default |
|---|---|---|---|
| category | 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 full burden. It states the tool is free and requires no special plan. It describes the output clearly. The tool is a read-only listing, which is transparent. However, it does not mention rate limits or authentication, which are minor omissions for a simple list 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?
The description is three sentences, front-loaded with the main purpose. It uses bullet-like enumeration for the return fields efficiently. Every sentence provides value, 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?
Given the output schema exists, the description need not detail return structure fully. It identifies key fields. It covers the optional parameter. However, it does not mention pagination or result limits, which might be relevant for a catalog tool, but given the simplicity, it is largely 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 description coverage is 0%, so the description must compensate. It adds meaning to the optional 'category' parameter by providing examples (e.g., rates, yield_curve, inflation). This helps the agent understand valid values beyond the schema's null/string type.
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 purpose: listing available macroeconomic series (the catalog). It explains what is returned (id, title, category, frequency, units, plus categories) and distinguishes from the sibling get_macro_series. The verb 'list' and resource 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?
The description explicitly says 'Call this first to find the id for the series you want.' This guides the agent to use it before get_macro_series. It also mentions optional filtering by category with examples. However, it does not explicitly state when not to use or provide alternatives beyond the implicit pairing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description states behavior: 'cheap, cacheable per session', returns templates scoped to API key, and mentions potential truncation with truncated_by_mcp flag. Does not clarify read-only nature or rate limits, but overall informative.
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 dash-separated sections, front-loaded purpose. Slightly verbose with JSON examples, but each sentence adds value. No redundancy.
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?
No output schema, but description provides detailed return shapes for both modes (compact catalog fields, full entry structure including condition_tree, indicators, defaults, etc.) and mentions truncation flag. Sufficient for agent to understand inputs and outputs.
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 description adds full meaning: name accepts id or name (case-insensitive), compact boolean (default true) controls response detail. Provides example usage. Adequately compensates for lack of schema 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?
Description clearly states verb 'list' and resource 'strategy templates', distinguishes two modes (compact catalog vs. single full entry) and explains return shapes. Distinct from sibling list tools as it specifically targets templates.
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 describes when to use each argument: no arguments for discovery, name parameter for single template details. Warns about compact=False being large and possibly truncated. Does not directly compare to sibling tools, 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.
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) — when given, the result also carries
benchmark-relative metrics (beta, alpha, information ratio,
tracking error, up/down capture) and bar-alignment info.
data_inputs: Optional custom time-series the strategy references
(name -> {dates, values}).
response_detail: 'summary' (default — headline metrics, smallest),
'stats' (every metric), 'full' (plus trades and series
downsampled to a fixed, server-controlled number of points).
include: Optional add-on blocks at any detail level: 'trades',
'equity_curve', 'monthly_returns', 'yearly_returns',
'signal_diagnostics' (which per-bar entry/exit conditions
fired, as capped fire-date lists — {"available": false, ...}
if the run has none, e.g. precomputed signals).
trades_limit: Max trades returned when trades are included.
Returns:
The shaped result at the requested detail (including
``benchmark_relative``/``alignment`` when a benchmark was given);
an oversized result is thinned and marked ``truncated_by_mcp``. If
the engine rejects the request as invalid (400/422), returns
{"accepted": false, "error": ...} so you can fix the named
field(s) and retry. Capacity, timeout, and permission failures
(e.g. 429/503/504/401/403) raise a tool error carrying explicit
recovery guidance.
| 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?
Discloses key behavioral traits: 'Quota-counted and compute-bound.' Describes timeout handling, oversized result thinning with 'truncated_by_mcp' marker, benchmark-relative metrics inclusion, and error return structures for validation failures. No annotations exist, so description carries the full burden and meets it.
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 front-loaded with purpose, then organized as an Args section with bullet points for each parameter, followed by a Returns section. Every sentence adds value; no redundancy. Despite length, it is well-structured and efficient 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 9 parameters, nested objects, a large sibling set, and the need to explain error/truncation behavior, the description is comprehensive. It covers all parameter constraints, return value details, error recovery, and even suggests the cheaper alternative tool. Output schema exists, so return values need not be detailed in description, but they are.
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 fully document parameters. It does so with detailed explanations for all 9 parameters: data_source formats (inline vs server-side), strategy/signals mutual exclusivity, execution usage via get_catalog, benchmark effects, response_detail levels, include options, and trades_limit. Adds meaning well 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?
Description opens with 'Run a historical backtest against the engine,' clearly stating the verb and resource. It distinguishes from the sibling tool validate_strategy by noting it is 'far cheaper,' and implies that this tool is for actual backtesting rather than 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 advises to validate first with validate_strategy. Provides detailed error-specific guidance: for 504 reduce date range/frequency/complexity; for 429/503 wait for Retry-After; explains 400/422 return format for fixable errors. Covers when to use and how to handle failures.
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!
Your Connectors
Sign in to create a connector for this server.