Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Patch a strategy file

patch_file
Destructive

Applies exact text or guarded line-range edits to one file in any strategy owned by the authenticated user and creates a new immutable strategy revision. Requires editHandle from get_file/list_files. For insert_before and insert_after operations, include an exact unique anchor. For replace_text, oldText must match exactly one location in the current readback. If a statement appears in several lifecycle methods, include surrounding function context to select the intended occurrence. Use replaceAll=true only when every occurrence is part of the requested change; repeated text does not make unrelated resets or branches interchangeable. For a localized exact replacement, the complete required shape is {"path":"main.py","editHandle":"","operations":[{"type":"replace_text","oldText":"","newText":""}]}. Keep path, editHandle, operation type, oldText, and newText in the same call; omitting any of them fails validation. For the current attached/open strategy, omit strategyId and revisionId after get_file; the server resolves the latest conversation revision, so do not manually transcribe those UUIDs. Pass explicit ids only for a named or different strategy. For replace_range operations, include startLine and endLine. For replacing most or all of main.py after create_strategy, prefer replace_file. Do not use patch_file for a short placeholder or a repair that replaces most of the returned file. Never estimate an endLine beyond the exact returned file. For those rewrites, call replace_file directly with the complete content and latest editHandle. Before any second file mutation, read the first mutation's returned new revisionId with get_file and use that readback's revisionId and editHandle. Never reuse the preceding revisionId or editHandle after a successful mutation. For existing-strategy fixes, this is the action step after get_file identified the concrete change and returned an editHandle. Mutate only the strategy/revision named by the user when it differs from the open page context. After a successful patch, call get_file on the returned new revisionId to read back the final saved code and verify the saved executable code before final-answering; do not verify by re-reading the original/base revisionId from before the edit. For direct edits to existing saved strategies, edit plus readback completes the direct edit unless the user explicitly asked for a backtest. Do not start a backtest just because you want validation after this edit. For copy/apply-same-rules requests, do not use patch_file after reading only one strategy, and do not use it after reading only the target. A different revision of the named target is still target evidence, not source evidence, unless the user explicitly asked to copy from an older target revision. First read the source strategy code and the named target strategy code, then diff executable assignments/thresholds/cadence/branches within the requested copy scope. Copy only explicitly requested mechanics for a limited transfer; update every differing target value to the source value only for whole-strategy parity. Preserve target-specific identity such as symbol/ticker, strategy name, account/broker identity, and labels unless the user explicitly asks to change them; do not copy the source symbol/name into the target. Build the patch from the target file and selectively copy behavior values into it; do not patch by pasting the whole source file over the target when identities differ. In Python strategy code, self.symbol is target identity when source and target tickers differ; for a TQQQ source applied to an SQQQ target, keep self.symbol as SQQQ while copying behavior rules. Target identity does not include cadence, sleeptime, trigger thresholds, order sizing, entry/exit branches, helper calls, or risk rules; those are behavior and must match the source only when included in the requested copy scope. Do not add settings absent from the source or merge unrelated memory/preferences. Before patch_file in a copy/apply-same-rules edit, preserve the literal target identity line from the target readback in the patch. If your patch would turn target identity into source identity, do not call this tool yet; correct the patch first. After readback for a copy/apply-same-rules edit, if the target file contains source identity such as the source symbol/name/account/broker, edit again before final-answering. Do not list source identity as evidence of success. When the fix replaces an executable setting, guard, helper call, order path, or branch, remove or replace the stale executable code; do not append a competing line and leave the old contradictory behavior in place. When the user says to stop using a value/source, or says that value/source is stale or wrong, remove executable fallback uses of that value/source instead of keeping them as a backup path. If the readback still contains the stale executable value/source/fallback the user asked to remove, the edit is not complete; call patch_file or replace_file again before final-answering. If the user supplied a concrete replacement value for a code-owned setting such as cost basis, entry price, threshold, cadence, market, symbol, or helper path, replace the stale executable literal/path and read it back. For live fill/cost-basis fixes where live order tools fail but the user supplied a concrete bot-owned fill, record/use that exact fill value in executable state/code as the bootstrap latest verified bot-owned fill; do not add only an unset placeholder such as None. For plan-driven first-build work, make the visible implementation item in_progress with update_plan_item before using file tools so the user sees the current plan step while file work runs. If a patch operation fails, no new revision was created: read the current file/editHandle and retry with replace_file or a corrected patch before starting a backtest or ending the strategy build. Default to the active strategy unless the user explicitly asks for another owned strategy.

Input Schema

NameRequiredDescriptionDefault
pathYes
editHandleYesOpaque edit handle returned by list_files or get_file. It replaces raw hash copying while preserving stale-write protection.
operationsYes
revisionIdNoBase revision ID to snapshot from. Omit with strategyId for the current attached/open strategy.
strategyIdNoBase strategy id. Omit with revisionId for the current attached/open strategy so UUIDs do not need to be transcribed.
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses that each successful patch creates a new immutable revision, that editHandle enforces stale-write protection, that a failed patch creates no new revision, and that after success the agent must read back the new revisionId rather than reuse the prior revisionId or editHandle. These are material mutation-behavior details that an agent needs before invoking the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a very long, monolithic block that mixes the core patch contract with extensive copy/apply-same-rules policy, plan-item instructions, and backtest guidance. While it starts with the purpose, key operational rules are buried and repeated across many sentences. It is far from appropriately sized or front-loaded.

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 complex mutation tool with nested operations and no output schema, the description is complete enough: it covers revision creation, stale-write handling, failure behavior, readback verification, identity preservation in copy workflows, and the replace_file boundary. Missing optional parameter semantics are minor relative to the overall coverage.

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 only 50% schema description coverage, the description does substantial work: it explains path, editHandle provenance, operation types, oldText/newText/anchor uniqueness, replaceAll semantics, startLine/endLine for replace_range, and when to omit strategyId/revisionId. It even gives a complete replace_text call shape. It does not mention the optional `description` parameter or `expectedOldText`, leaving a minor gap.

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: it applies exact text or guarded line-range edits to one strategy file and creates a new immutable revision. It explicitly distinguishes itself from replace_file for large rewrites and names get_file/list_files as the prerequisite source of editHandle. An agent can tell what this tool does and how it differs from nearby file 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?

The description gives explicit when-to-use and when-not-to-use guidance: use patch_file for localized exact replacements after get_file, prefer replace_file for most/all of main.py or placeholder repairs, and do not start a backtest after a direct edit unless requested. It also states alternatives, prerequisites, and sequencing for multi-mutation and copy/apply-same-rules workflows.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.