backtest360-mcp

Official

by Backtest360

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: validation, backtest execution, comparison, statistics, catalog browsing, ticker search, etc. Overlaps are minimal and clearly differentiated (e.g., get_latest_signal returns current signal only, run_backtest returns full performance).
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., validate_strategy, run_backtest, list_indicators). No mixing of conventions like camelCase or inconsistent verb styles.
Tool Count5/5
14 tools is well within the 3-15 ideal range. Each tool serves a necessary function for the backtesting domain—validation, execution, analysis, discovery—without bloat or missing essentials.
Completeness4/5
Covers the core backtesting workflow: strategy creation (schema, validation), execution (run, compare, signal), data discovery (tickers, range), and analysis (stats). Minor gaps: no tool for editing saved strategies or managing user settings, but these are peripheral to the server's main purpose.
Average 4.6/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral context. It discloses that it is available only on paid plans and hints at its non-destructive nature by suggesting it be used for pre-fetch validation. It could mention if the tool is read-only, but the intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two efficient sentences plus a note. It front-loads the core purpose and adds actionable guidance without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers the essential context: what the tool retrieves, when to use it, and plan requirements. Minor gaps in parameter details exist but are offset by low parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely references 'symbol/frequency' without further explanation of format or constraints, leaving the agent to infer from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns available date range and estimated bar count for a given symbol/frequency. It is distinct from sibling tools like 'compare_backtests' or 'run_backtest' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises calling this tool before a server-side fetch to ensure parameters stay within provider limits, providing clear context. However, it does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses that no P&L or stats are computed, and returns only signal, conditions, and timestamp. While it doesn't explicitly state read-only behavior, the context implies it is a query without side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and then list return values. Every sentence is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good purpose and usage guidance, the description lacks parameter explanations and does not leverage the output schema (which exists) to detail return format. Given the complexity of four object parameters, this gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 4 parameters (2 required), all objects with additionalProperties: true, and schema description coverage is 0%. The description does not explain any of these parameters (e.g., what 'strategy', 'execution', 'data_inputs', 'data_source' contain or how to use them). It fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool evaluates strategy on the most recent bar only, returning a signal (-1/0/1), condition slots, and timestamp. Distinguishes itself from run_backtest, which is for performance analysis, thus specifying the resource and action effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for 'what would this strategy do right now' questions) and when to use an alternative (use run_backtest for performance). This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it is cheap, cacheable per session, and explains the compact strip behavior, wire optimization, and potential MCP server truncation. No annotations provided, but description compensates well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but the wire optimization paragraph is somewhat technical and could be more concise. Overall, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description explains return values for both modes, including the truncated_by_mcp flag. It adequately covers the dual behavior and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning to both parameters: name (optional, case-insensitive, example shown) and compact (default true, effects explained). Thoroughly compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists indicators or fetches one indicator's full schema, with specific mention of compact and detailed modes. However, it does not explicitly distinguish it from sibling tools like get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use compact mode for discovery and when to use name= for obtaining a full schema before adding to a strategy. Also explains wire optimization but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses relevance-ranked search and acceptable values for asset_class. It does not cover pagination or error behavior, but given the existence of an output schema, the behavioral context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a brief example, all front-loaded with the core purpose. No wasted words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with an output schema, the description covers purpose, filter usage, and the typical workflow step. It is mostly complete, though it could mention case sensitivity or partial matching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description adds essential meaning: query is a user mention, asset_class filters to specific values ('stocks', 'crypto', etc.), and limit has a default. This is sufficient but could elaborate on query format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches available assets by ticker or name with relevance ranking, and specifies the use case of resolving user mentions to exact tickers before data fetch. This distinguishes it from siblings like list_tickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use the tool ('to resolve a user's asset mention... before requesting data'), implying it is a preliminary step. It does not explicitly state when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries burden. Discloses free/quota-free nature, which is helpful. Could mention side effects (none) but minimal risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise and informative sentences. Front-loaded with return fields, then usage note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and output schema present, this description sufficiently covers purpose and usage. Would be complete even without schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4 as per guidelines. Description adds no param info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states output: engine version, API contract number, health. Clear verb 'returns' not needed since it's implied. Distinguishes from siblings like compare_backtests, get_catalog, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling once at session start and notes it's free/quota-free. No alternatives mentioned, but context is clear given uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It discloses that the tool computes stats, warns about silent mis-annualization with wrong trading_days_per_year, explains optional parameters add extra metrics, and notes that return format depends on API key plan. While it doesn't explicitly state read-only nature, the computation-oriented description and lack of side effects make it sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, usage guideline, parameter list, and return type. It is informative without being overly verbose; every sentence adds value. Slightly lengthy but justified by the need to explain multiple parameters and warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary inputs, explains output format (JSON with stats key), and directs to get_catalog for metric details. Since an output schema exists, the description doesn't need to detail every return field. Adequate for a computation tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for each parameter: required format for returns, importance and warning for trading_days_per_year, effects of benchmark_returns and trades, and default for risk_free_rate. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes performance metrics from a returns series, with a specific verb and resource. Explicitly distinguishes from sibling tool run_backtest by noting that backtest results already include these statistics, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use ('Use when the returns came from somewhere other than run_backtest') and implicitly when not to (backtest results already include stats). Names the alternative tool run_backtest, giving clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Notes catalogs are 'cheap, cacheable per session', implying a read-only, non-destructive operation. No annotations provided, but description adequately covers behavior. Lacks explicit statement of being read-only, but strong implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear list, but somewhat verbose with bullet points; still front-loaded and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a catalog retrieval tool: explains purpose, when to use, what each catalog contains, and references output schema. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 0%, the description adds detailed semantics for the 'catalog' enum values, explaining exactly what each catalog contains, far beyond the schema's minimal representation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches one engine reference catalog, enumerates each possible catalog and its content, distinguishing it from sibling tools like run_backtest or search_tickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to fetch before building a strategy, never guess parameter names or frequencies, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but implies a read operation, mentioning 'fetch' and no side effects. It could explicitly state it's read-only, but for a simple schema retrieval, it's adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no fluff. Every sentence earns its place by stating what the tool does and why to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, output schema present, and no complexity, the description fully covers the tool's purpose and usage context. It ties to validate_strategy for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4 per guidelines. The description does not need to add param info, and schema coverage is 100% vacuously.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a JSON schema for a strategy document, specifying condition_tree and indicators, and distinguishes from sibling validate_strategy by mentioning the shared rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to fetch this before composing a strategy manually, and references validate_strategy as a sibling that checks against the same schema, providing clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It discloses the tool is 'Cheap, cacheable per session,' explains that results are scoped to the calling key, details the return formats for both argument modes, and warns about potential truncation with truncated_by_mcp. No behavioral contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured. It leads with the core purpose, then uses sub-sections for different argument scenarios. While every sentence adds value, it could be slightly more compact without losing clarity. Overall, it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the tool's dual-mode behavior, the description is remarkably complete. It covers return shapes for both modes, parameter details, truncation warnings, and even mentions that results are per-API-key. No missing essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It does so thoroughly: for name, it explains it is optional, case-insensitive, accepts id or name, and triggers a full fetch of a single template. For compact, it notes the default (true) and the behavior when false (complete entries but may be capped). This far exceeds the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'List predesigned strategy templates, or fetch one in full.' It specifies the resource (strategy templates) and the two distinct modes (compact listing vs. full fetch). This differentiates it from sibling tools like run_backtest or validate_strategy, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use it to discover what exists' for the no-argument case, and 'Pass name=...' to fetch a single template in full. It also advises preferring compact or name to avoid truncation. However, it does not explicitly mention when not to use this tool or name alternatives, but the guidance is clear enough for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the list is capped and marked truncated_by_mcp, which is a key behavioral trait. However, it could mention the exact cap or any rate limits, but the explanation is still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficient, and front-loaded with the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with one optional parameter and an output schema, the description covers purpose, filtering, truncation warning, and alternative tool. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the asset_class parameter's purpose and suggests using it to narrow results, adding necessary context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available tickers with optional filtering by asset class, and distinguishes itself from search_tickers by noting the latter is for resolving a specific asset by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to pass asset_class to narrow the list or use search_tickers for a specific asset, providing clear context on when to use this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: quota-counted, compute-bound, error handling for 400/422/401/403/429/503/504, return truncation, and error recovery guidance. It does not explicitly state idempotency or side effects, but the detail is high.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main paragraph, error guidance, parameter list, and return explanation. It is front-loaded with the core purpose. However, it is slightly verbose, though every sentence carries useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, output schema present), the description covers purpose, usage guidelines, behavioral transparency, parameter semantics, and return values comprehensively. It addresses error scenarios and recovery, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter descriptions, but the description compensates with detailed explanations for all 9 parameters, including mutual exclusivity of strategy/signals, data_source options (inline vs server-side), execution defaults, response_detail enum meanings, and include options. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a historical backtest against the engine' and distinguishes it from the cheaper `validate_strategy`. It explains the tool's primary verb and resource, and the context signals confirm uniqueness among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: validate first with `validate_strategy`. It advises against retrying on 504 errors and recommends reducing date range or simplifying strategy. On 429/503, it instructs to wait for Retry-After. Alternatives like `compare_backtests` and `get_catalog` are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: quota counting, compute scaling, wall-clock budget, truncation mechanisms (engine vs MCP), error response formats, and return structure. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear purpose, Args, and Returns sections. Every sentence adds necessary information without redundancy. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects, output schema), the description covers inputs, outputs, error cases, truncation, and edge conditions. It leaves no critical gap for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description includes a detailed Args section explaining each parameter's meaning and expected structure (e.g., strategies as list of objects, response_detail enum). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run several strategies on the same data and compare side by side'. It uses specific verb 'run' and resource 'strategies', and the comparison aspect differentiates it from sibling tools like run_backtest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on quota costing and scaling, and advises against blind re-runs on truncation. However, it does not explicitly specify when to use this tool versus alternatives (e.g., run_backtest) or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It does so by detailing the return shape (scopes, limits, usage, capabilities) and noting that the call is cheap and returns a fixed-shape record. No side effects or destructive actions are implied, and the description is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, a usage tip, and a bulleted list of return fields. While it is somewhat verbose, every sentence adds value, and it avoids redundancy. Slightly more conciseness could be achieved, but it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and the presence of an output schema (implied by the return description), the description is complete. It explains what the tool does, when to use it, and exactly what it returns, covering all necessary context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description adds no parameter information, which is appropriate. With zero params, a baseline of 4 is given per calibration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the configured API key's permissions, limits, and current usage. It uses a specific verb ('get') and resource ('me'), and the returned fields are enumerated. Among siblings, it uniquely provides authentication context, distinguishing it from tools like engine_info or get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling early in a session before planning work, to avoid discovering limits through failed calls. It labels the tool as 'Cheap,' suggesting low cost, which guides when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it's a cheap, separate-quota validation that returns success/failure without running a backtest. It clarifies failed validation is a normal result, not an error, and details the return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a one-line summary, usage note, Args, and Returns. Every sentence adds value without redundancy. It's appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (validating a strategy with indicators and conditions), the description covers purpose, parameters, return values (including error format), and usage context (cheap quota, reference to schema). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds rich meaning: explains strategy document structure (name, indicators, condition_tree) and injected_indicators purpose (custom columns supplied at runtime). This compensates fully for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a strategy document without running a backtest, distinguishing it from the sibling run_backtest. The verb 'validate' and resource 'strategy document' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'validate freely and ALWAYS before run_backtest,' providing clear when-to-use guidance. References get_strategy_schema for shape details, and mentions cheap quota to encourage frequent use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![backtest360-mcp MCP server](https://glama.ai/mcp/servers/Backtest360/backtest360-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Backtest360/backtest360-mcp)

Score Badge

Copy to your README.md:

[![backtest360-mcp MCP server](https://glama.ai/mcp/servers/Backtest360/backtest360-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Backtest360/backtest360-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Backtest360/backtest360-mcp'

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