BackTest_MCP

by Dor1Toes

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: data fetching, cache listing, running backtests, retrieving results, listing jobs, generating reports, accessing artifacts, and scanning live signals. No two tools overlap in function, even though several relate to backtests but target different aspects (results vs artifacts vs jobs).
Naming Consistency4/5
The naming follows a verb_noun pattern with prefixes like get_, list_, run_, generate_, and scan_. The mix of get_backtest_result and get_backtest_artifacts vs list_backtest_jobs and list_cached_symbols is syntactically consistent, though get vs list could be unified. Overall it is predictable and readable.
Tool Count5/5
Eight tools is ideal for a backtesting MCP server. The scope is tightly focused on data retrieval, backtest execution, result inspection, artifact access, reporting, and live signal generation—each tool addresses a distinct step in the workflow with no redundancy or bloat.
Completeness5/5
The tool surface covers the full lifecycle: fetching market data, running dynamic backtests, retrieving results and artifacts, listing historical jobs, generating reports, and scanning live signals. There are no obvious missing operations for the domain; the set is comprehensive and self-contained.
Average 4.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 discloses caching behavior, preview modes, return structure, and an error case for empty symbols. It also provides default values and source selection. Missing details like network access or permission requirements, but the coverage is strong for a data-fetching tool.
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 Args and Returns sections, front-loads the purpose, and every sentence adds value. It is detailed yet concise, with no fluff.
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 6-parameter tool with no output schema and no annotations, the description provides a complete picture: purpose, all parameter semantics, return structure, and an error condition. It does not cover edge cases like invalid symbol format or start > end, but the core usage is clear.
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 descriptions are 0%, so the description fully carries parameter meaning. It explains every parameter: symbols format with an example, date formats and defaults, interval default, preview behavior, and preview_rows default. This is far beyond the basic 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 first sentence states a specific action ('Fetch and cache OHLCV bars') on a specific resource ('one or more symbols') with source context ('local DB or remote source'). This clearly distinguishes it from backtest-related sibling tools, though it slightly overlaps with list_cached_symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While it explains parameter usage and defaults, it does not mention any exclusions or alternative tools, leaving the selection decision ambiguous given siblings like list_cached_symbols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It does disclose data source (SQLite), ordering (newest first), and the full return structure, which is helpful. However, it does not explicitly state that this is a read-only operation or note any side effects or limitations beyond the basic list behavior. The verb 'list' implies non-mutation, but explicit disclosure would be stronger.
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 Args and Returns sections. Each sentence contributes value: the one-line summary gives the core purpose, the Args section explains both parameters, and the Returns section defines the output shape. No redundant or filler content exists.
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?
The tool is simple (two optional parameters) and has no output schema, so the detailed Returns section is valuable and makes the description reasonably complete. It covers payload structure and field lists. A minor gap is that it doesn't define any maximum or bounds on the limit parameter, but this is not critical for a listing tool.
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 input schema provides only names, types, and defaults (0% schema description coverage). The description compensates fully: it explains the limit parameter with a default and meaning, and the status parameter with example values ('done', 'failed') and behavior for empty string. This adds substantial semantic 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 the tool's function: 'List recent backtest jobs from SQLite, newest first.' It uses a specific verb ('list'), a specific resource ('backtest jobs'), and a scope ('recent', 'newest first'). This differentiates it from sibling tools like get_backtest_result, which likely retrieves a single job, and run_backtest_dynamic, which runs new jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (listing recent jobs from SQLite) but does not explicitly explain when to use this tool versus alternatives like get_backtest_result or run_backtest_dynamic. There is no mention of exclusions or alternative tools, so the guidance is only implied by the action verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the return structure (JSON with ok, job_id, artifacts) and artifact entry fields, which is helpful. However, it does not mention error behavior (missing job_id), path details, or permissions, leaving some behavioral ambiguity.
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 concise and well-structured with a clear summary line followed by Args and Returns sections. Every sentence adds value, and the format is easy to scan.
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 simple two-parameter listing tool with no output schema or annotations, the description provides the essential purpose, parameters, and return format. It lacks edge-case behavior (e.g., invalid job_id) but is otherwise 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section documents both parameters: job_id as 'Backtest job identifier' and kind with an explicit list of valid filters plus the empty-all behavior. This fully compensates for the 0% schema description coverage, adding 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?
The description opener 'List on-disk artifact paths for a backtest job' uses a specific verb (List) and resource (artifact paths), clearly distinguishing it from sibling tools like get_backtest_result (result data) and list_backtest_jobs (job listing). The filter kinds are enumerated, reinforcing scope.
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 clarifies that kind is an optional filter and that empty returns all kinds, giving clear context for when to use this tool with filtering. However, it does not explicitly contrast with siblings or state when not to use it, so it stops short of full usage 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?
No annotations are provided, so the description carries the full burden. It discloses the local SQLite cache as the data source and explicitly provides the return JSON format, which is beyond what the empty input schema offers. Although it does not explicitly state that the operation is read-only, 'List' and 'cache' imply non-destructive behavior. This is sufficient for a simple listing tool.
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: the first states purpose, the second gives the return type. Every word adds value and it is front-loaded. No extraneous information or repetition.
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?
The tool is simple: no parameters, no output schema, and the description covers both what it does and the exact return structure. The mention of 'local SQLite cache' and the return format fully equips an agent to invoke and interpret the result. There is no missing critical context.
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, and the schema is trivially 100% covered. According to the rubric, 0 parameters yields a baseline of 4. The description adds no parameter details (there are none), so no additional credit or penalty is applied.
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 function: 'List stock symbols that already have OHLCV data in the local SQLite cache.' It uses a specific verb ('List'), identifies the resource ('stock symbols'), and includes a distinguishing qualifier ('already have OHLCV data in the local SQLite cache') that separates it from sibling tools like get_stock_data.
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 implicitly conveys when to use the tool: to check which symbols already have cached OHLCV data. However, it does not explicitly mention alternatives or when not to use it, so it lacks the explicit exclusion/alternative guidance required for a 5. The context is clear, earning a 4.
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 the description carries the burden. It discloses success/failure return shapes, the side effect of registering a report_markdown artifact, and the default title behavior, which is beyond minimal.
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 concise and well-structured, with a leading purpose sentence followed by clearly labeled Args and Returns sections. No redundant or unnecessary 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?
The description covers prerequisites, parameters, return types, error cases, and side effects. For a simple report generator with no annotations or output schema, it is fully complete.
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 coverage, the description fully describes both parameters: job_id's requirement for an equity_curve artifact and title's optionality with a computed default, adding critical meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Build a Markdown tearsheet report from a completed backtest's equity curve.' This clearly distinguishes it from siblings like get_backtest_result or run_backtest_dynamic.
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?
It states the prerequisite that the job_id must refer to a completed backtest with an equity_curve artifact, implying when to use it. However, it does not explicitly name alternative tools or provide when-not-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 of explaining behavior. It fully documents the return schema, including the `ok` flag, status, error handling, and the `result` field conditionally populated when status is `'done'`. It also covers the unknown job case. It doesn't mention replication or side effects, but for a fetcher that's a reasonable trade-off.
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-organized with an Args section and a Returns section, both concise and free of fluff. Every sentence adds value, and the return format is presented in a compact but complete manner.
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 simple one-parameter fetch operation, the description is fully sufficient. It specifies input provenance, success and error return shapes, and conditional behavior of the `result` field. No output schema exists, but the description provides one inline, ensuring the agent understands what to expect.
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 the schema provides only the name and type of `job_id`, the description explains it is a 'Job identifier returned by `run_backtest_dynamic`'. This provenance clue adds essential meaning beyond the schema, fully compensating for the 0% schema description coverage.
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 ('Fetch status and summary') and the resource ('a backtest job stored in SQLite'). It distinguishes itself from sibling tools like get_backtest_artifacts and list_backtest_jobs by focusing on job results rather than artifacts or a list.
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 clear context by referencing `run_backtest_dynamic` as the source of `job_id`, implying this tool is used after starting a backtest. However, it doesn't explicitly mention when not to use it or suggest alternative tools for other needs (e.g., get_backtest_artifacts for file outputs).
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 carries the full burden and does so excellently. It discloses sandbox isolation, pre-execution validation, validation failure (no job created), runtime failure (job_id plus error), and success result with metrics. It also hints at artifact persistence, giving the agent a clear behavioral model.
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 logically structured with a summary, Args, and Returns sections. It is moderately long but every part serves a purpose. The spec URI is repeated twice, which is slightly redundant, but the overall organization keeps it readable and efficient 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 has two complex string parameters and no output schema, the description fully covers the important aspects: success, validation failure, and runtime failure responses, plus a preview of the metrics returned. It also references a spec for deeper details, making it self-contained enough 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description fully compensates. It explains `code` as Python source with exactly one Strategy subclass and enforced imports, and `config_json` as a JSON string with required/optional settings, date format, and pointer to full schema. This adds substantial meaning beyond the raw 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 begins with a specific verb and resource: 'Run a dynamic Strategy backtest in an isolated sandbox and persist artifacts.' This clearly states what the tool does and distinguishes it from siblings like get_backtest_result or scan_strategy_signals. The 'dynamic' and 'persist artifacts' add specificity beyond the tool name.
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 clear context for when to use the tool: it runs backtests, enforces strategy rules, and returns a job_id for later retrieval. It does not explicitly name alternative tools or state when not to use it, but the context makes the primary use case obvious. This aligns with 'clear context, no exclusions'.
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 provided, the description carries the full burden and does excellently. It discloses internal mechanics (loads strategy.py and config.json from storage/artifacts/{job_id}/), data fetching behavior, the warmup-based window, email side effects when notify is true, and detailed error/return behavior for missing files or invalid config.
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, followed by an overview paragraph and organized Args/Returns sections. It is longer than strictly necessary but every section adds valuable context. It earns a 4, not a 5, because the level of detail (especially the full return shape) could be slightly trimmed without losing core meaning.
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?
The description is complete for a tool with no output schema and no annotations. It covers the purpose, all parameters, the exact return shape under success and failure, side effects (notification), and even references the config spec. There are no significant gaps that would leave an agent uncertain about invocation or interpretation of results.
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%, but the description compensates fully by explaining every parameter in the Args section: job_id, warmup_days_override, notify, and notify_to. It adds meaning beyond the bare schema types and defaults, including the purpose of each argument and how overrides work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Scan the latest bar for live strategy signals from a saved backtest job.' This immediately distinguishes it from sibling tools like get_backtest_result or run_backtest_dynamic, which focus on historical results or running backtests, not live signal scanning.
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 implicitly conveys when to use the tool (for live signals derived from a saved backtest) and explains the process (loads artifacts, fetches OHLCV, optional notify). However, it does not explicitly name alternatives or state when NOT to use it, so it stops short of a 5.
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:

[![BackTest_MCP MCP server](https://glama.ai/mcp/servers/Dor1Toes/BackTest_MCP/badges/card.svg)](https://glama.ai/mcp/servers/Dor1Toes/BackTest_MCP)

Score Badge

Copy to your README.md:

[![BackTest_MCP MCP server](https://glama.ai/mcp/servers/Dor1Toes/BackTest_MCP/badges/score.svg)](https://glama.ai/mcp/servers/Dor1Toes/BackTest_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/Dor1Toes/BackTest_MCP'

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