Skip to main content
Glama

update_backtest

Modify a backtest's name or notes to organize and document trading strategy results in the QuantConnect platform.

Instructions

Update a backtest's name or note.

Args: project_id: ID of the project containing the backtest backtest_id: ID of the backtest to update name: Optional new name for the backtest note: Optional new note for the backtest

Returns: Dictionary containing update result

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
backtest_idYes
nameNo
noteNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The core handler function for the 'update_backtest' tool. It authenticates, validates input, makes an authenticated POST request to QuantConnect's 'backtests/update' endpoint, and handles the response with detailed success/error messages.
    @mcp.tool()
    async def update_backtest(
        project_id: int, 
        backtest_id: str, 
        name: Optional[str] = None, 
        note: Optional[str] = None
    ) -> Dict[str, Any]:
        """
        Update a backtest's name or note.
    
        Args:
            project_id: ID of the project containing the backtest
            backtest_id: ID of the backtest to update
            name: Optional new name for the backtest
            note: Optional new note for the backtest
    
        Returns:
            Dictionary containing update result
        """
        auth = get_auth_instance()
        if auth is None:
            return {
                "status": "error",
                "error": "QuantConnect authentication not configured. Use configure_auth() first.",
            }
    
        # Validate at least one field is provided
        if name is None and note is None:
            return {
                "status": "error",
                "error": "At least one of 'name' or 'note' must be provided for update",
            }
    
        try:
            # Prepare request data
            request_data: Dict[str, Any] = {
                "projectId": project_id, 
                "backtestId": backtest_id
            }
    
            if name is not None:
                request_data["name"] = name
            if note is not None:
                request_data["note"] = note
    
            # Make API request
            response = await auth.make_authenticated_request(
                endpoint="backtests/update", method="POST", json=request_data
            )
    
            # Parse response
            if response.status_code == 200:
                data = response.json()
    
                if data.get("success", False):
                    update_fields = []
                    if name is not None:
                        update_fields.append(f"name to '{name}'")
                    if note is not None:
                        update_fields.append("note")
    
                    return {
                        "status": "success",
                        "project_id": project_id,
                        "backtest_id": backtest_id,
                        "updated_fields": update_fields,
                        "message": f"Successfully updated backtest {backtest_id}: {', '.join(update_fields)}",
                    }
                else:
                    # API returned success=false
                    errors = data.get("errors", ["Unknown error"])
                    return {
                        "status": "error",
                        "error": "Backtest update failed",
                        "details": errors,
                        "project_id": project_id,
                        "backtest_id": backtest_id,
                    }
    
            elif response.status_code == 401:
                return {
                    "status": "error",
                    "error": "Authentication failed. Check your credentials and ensure they haven't expired.",
                }
    
            else:
                return {
                    "status": "error",
                    "error": f"API request failed with status {response.status_code}",
                    "response_text": (
                        response.text[:500]
                        if hasattr(response, "text")
                        else "No response text"
                    ),
                }
    
        except Exception as e:
            return {
                "status": "error",
                "error": f"Failed to update backtest: {str(e)}",
                "project_id": project_id,
                "backtest_id": backtest_id,
            }
  • Registration block in the main entrypoint where register_backtest_tools(mcp) is called at line 50, which in turn defines and registers the update_backtest handler using @mcp.tool().
    register_auth_tools(mcp)
    register_project_tools(mcp)
    register_file_tools(mcp)
    register_backtest_tools(mcp)
    register_live_tools(mcp)
    register_optimization_tools(mcp)
  • The registration function that contains the definition of all backtest tools, including the nested update_backtest function decorated with @mcp.tool() for automatic registration.
    def register_backtest_tools(mcp: FastMCP):
        """Register backtest management tools with the MCP server."""
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permission requirements, whether changes are reversible, rate limits, or what happens when only partial fields are provided. The description adds minimal behavioral context beyond the basic operation type.

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 appropriately sized and well-structured with clear sections: purpose statement, parameter explanations, and return value indication. Every sentence earns its place, though the 'Returns' section could be slightly more informative. The information is front-loaded with the core purpose stated first.

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 this is a mutation tool with no annotations but with an output schema (implied by 'Returns' statement), the description provides adequate but not comprehensive context. It covers the basic operation and parameters well, but lacks behavioral details about permissions, side effects, or error conditions. The presence of an output schema reduces the need to describe return values in detail.

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?

With 0% schema description coverage, the description must compensate - and it does well by explicitly listing all 4 parameters with clear explanations of what each represents. The 'Args' section adds meaningful semantics: project_id identifies the containing project, backtest_id specifies which backtest to update, and name/note are optional fields that can be modified. This provides good parameter understanding despite 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 action ('Update') and resource ('a backtest's name or note'), providing specific verb+resource pairing. It distinguishes from siblings like 'update_file_content' or 'update_project' by specifying the exact resource type (backtest) and fields (name/note). However, it doesn't explicitly differentiate from 'update_optimization' which is a similar operation on a different resource.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a backtest to exist), doesn't specify when to use this versus 'create_backtest' or 'delete_backtest', and offers no context about typical workflows. The agent must infer usage from the tool name alone.

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/taylorwilsdon/quantconnect-mcp'

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