Skip to main content
Glama

fetch_backtest_status

Check the execution status and retrieve the latest results of a cryptocurrency trading strategy backtest in Freqtrade.

Instructions

Get current backtest execution status and latest result payload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for 'fetch_backtest_status' tool. Decorated with @mcp.tool(), it retrieves the backtest execution status by calling _client_get with the 'backtest' endpoint. Takes a Context parameter and returns the result as a string.
    @mcp.tool()
    def fetch_backtest_status(ctx: Context) -> str:
        """Get current backtest execution status and latest result payload."""
        client: FtRestClient = ctx.request_context.lifespan_context["client"]
        return str(_client_get(client, "backtest"))
  • Core helper function that dynamically calls client methods with fallback support for multiple freqtrade-client versions. Used by _client_get to make HTTP requests.
    def _call_client_method(client: FtRestClient, method_names: List[str], *args, **kwargs):
        """Call first matching client method to support multiple freqtrade-client versions."""
        for method_name in method_names:
            method = getattr(client, method_name, None)
            if callable(method):
                return method(*args, **kwargs)
        raise AttributeError(f"No supported method found in {method_names}")
  • Helper function that wraps _call_client_method for making HTTP GET requests to the freqtrade client. Used by fetch_backtest_status to retrieve backtest status.
    def _client_get(client: FtRestClient, path: str, params: Dict[str, Any] | None = None):
        return _call_client_method(client, ["_get"], path, params=params)
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-only operation ('Get') and specifies the data returned (status and payload), but does not mention potential side effects, error conditions, or response format details. This is adequate but minimal for a tool with zero parameters.

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 a single, efficient sentence that front-loads the core purpose ('Get current backtest execution status and latest result payload') with zero wasted words. It is appropriately sized for a simple, parameterless tool.

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?

Given the tool's simplicity (zero parameters, no annotations, no output schema), the description is complete enough for basic understanding. However, it lacks details on the response structure or potential errors, which could be helpful for an agent invoking it without an output 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?

The tool has zero parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description does not add parameter-specific information, which is unnecessary here. A baseline of 4 is appropriate as no parameters exist to explain.

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 purpose with specific verbs ('Get') and resources ('current backtest execution status and latest result payload'), distinguishing it from siblings like fetch_backtest_history (historical data) or fetch_bot_status (bot status). It precisely identifies what information is retrieved without ambiguity.

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 implies usage for checking ongoing backtest status, but provides no explicit guidance on when to use this tool versus alternatives like fetch_backtest_history or fetch_performance. It lacks context on prerequisites, timing, or exclusions, leaving the agent to infer appropriate scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/worlddebugger/freqtrade-mcp'

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