Building Custom Indicators with Claude Code and the SabrTrader MCP Server

This page documents the complete workflow for building a custom SabrTrader indicator by describing it in plain language to Claude Code, an AI coding agent, while SabrTrader's MCP (Model Context Protocol) server gives that agent direct control of the platform. The result is a closed loop: the agent researches the setup, writes C# source against the SabrTrader Indicator SDK, compiles it, installs it into the plugin folder, adds it to a live chart, screenshots the render, critiques its own output and patches the code — repeatedly, without you typing code. The same workflow applies to automated strategies, including backtesting and optimization.

Overview: What This Workflow Produces

This workflow turns a natural-language description of a trading setup into a compiled, installed, charted and self-refined SabrTrader indicator. You write a prompt. An AI coding agent does the research, the coding, the compiling, the installation and the visual review.

Three ingredients are required, and each supplies something the others cannot:

Without the MCP server the agent is coding blind: it can produce a plugin but cannot see how it renders. With the MCP server the loop closes — build → install → render → screenshot → evaluate → patch — and the agent can improve the visual design on its own between your instructions.

What this workflow does not do

• It does not verify that the AI's interpretation of a discretionary methodology is correct. If you cannot state the rules yourself, you cannot check them.
• It does not produce a validated edge. An on-chart win-rate label is not a backtest.
• It does not remove code review. You are installing a compiled plugin that runs inside your trading platform.
• It does not read your mind. A vague prompt forces the model to guess, and the output reflects the guess, not your intent.

If you have never created a chart or added an indicator in the platform, start with SabrTrader Platform Setup: Workspaces, Charts, and Indicators first, because the agent will be manipulating exactly those objects.

Prerequisites and Environment Setup

Before the agent can build anything you need a coding environment, a working folder and a running instance of SabrTrader.

Install the AI coding agent

• Claude Code is downloaded from claude.com. The default installation gives you a command-line interface (CLI).
• The Visual Studio Code extension is the alternative front end. Visual Studio Code is free, and the Claude Code extension installs from the VS Code extension marketplace. The workflow shown in the source video uses the VS Code extension because the file tree, diffs and terminal output are easier to follow than in the CLI.
• Functionally the CLI and the extension are equivalent. The choice is ergonomic, not technical.

Plan tier

Start on the free tier to confirm the workflow runs on your machine. Sustained indicator development consumes a large number of tokens because the agent reads documentation, reads example source files, compiles repeatedly and analyses screenshots. Most users move to a paid tier quickly.

Create a scoped working folder

Create one empty folder for the project — for example C:\dev\sabr-indicators\silver-bullet — and open only that folder in VS Code. This is folder scoping: it restricts the agent's read and write access to a single directory so it cannot touch unrelated files elsewhere on disk. State the restriction in the prompt as well ("only work in this folder"), because the instruction and the workspace root reinforce each other.

Model selection

Use the default general-purpose model for routine indicator work. Reserve the largest, slowest, most expensive model for genuinely hard problems — complex multi-pass algorithms, intricate rendering maths, or a build that will not converge. The trade-off is: bigger model, better multi-step reasoning, higher cost per token, longer wall-clock time. For writing a plugin against a documented SDK with 200 examples available, the default model is normally sufficient.

Permission mode

Bypass / auto-approve permissions mode runs the agent without asking you to approve each file write or tool call. It is what makes an unattended 30-minute refinement loop possible, and it is what the source video uses. It also removes a safety checkpoint: the agent can overwrite files and execute commands without a prompt. Use it only when the agent is folder-scoped, when the folder contains nothing you cannot lose, and when you are present to watch. Do not leave it running unattended.

Platform prerequisites

• SabrTrader must be running, connected to a data feed and showing a chart with loaded bars — the agent inspects real bars through MCP before writing logic.
• You need write access to the SabrTrader plugin folder so the compiled indicator can be installed.
• The .NET build toolchain used by the SDK must be installed, or the compile step will fail on the first attempt.

The SabrTrader MCP Server: Enabling It and What It Exposes

The MCP server (Model Context Protocol server) is a local server built into SabrTrader that exposes the platform's functions as callable tools for an AI agent. It is the control-and-feedback channel that separates this workflow from ordinary AI code generation.

Where to enable it

1. Open Settings → Preferences.
2. Select the MCP Server page.
3. Toggle the server to enabled.
4. Copy the server URL displayed on that page.
5. Paste the URL into your prompt, or register it in your agent's MCP configuration file.

The URL is how the agent finds the server. If it is not supplied, the agent will write code it can never see running.

What the agent can do once connected

The practical rule is: the agent can do anything you can do in SabrTrader. Typical tool categories include:

Security considerations

• Enable the MCP server only while you are supervising a session, and disable it afterwards.
• An agent with MCP access plus a connected live brokerage account can, in principle, act on that account. Prefer a simulation account or a data-only connection while developing.
• Combine MCP access with folder scoping so the agent's file-system reach is limited even though its platform reach is broad.
• The MCP server is a developer integration. It is not required for the built-in AI panels; those are configured separately as described in AI Setup: Connecting an LLM Provider to SabrTrader.

Giving the Agent Knowledge: SDK Docs and the GitHub Indicator Library

An AI agent that has never seen the SabrTrader API will invent method names. Two links prevent that, and both belong in every prompt.

1. The SabrTrader SDK documentation

The SDK (Software Development Kit) documentation is the official reference for building indicators and strategies. It runs to roughly 100 pages and covers the plugin lifecycle, data access, settings attributes, the strategy engine and the custom rendering APIs. For a human this density is a chore; for an agent it is a lookup table it can query on demand.

2. The public GitHub repository of indicator source code

SabrTrader publishes the source of its built-in indicators — roughly 200 of them — in a public GitHub repository. This matters more than documentation alone for four reasons:

• House style. The agent copies naming, file structure and code organisation used by the platform's own indicators.
• Lifecycle correctness. Real examples show which method initialises state, which processes each bar, and which draws.
• Settings attributes. Examples reveal how parameters are decorated so SabrTrader auto-generates the settings panel with grouped, labelled, typed fields.
• Rendering patterns. Custom drawing — boxes, gradients, labels, dashboards — is far easier to imitate from working code than to derive from prose.

Give both links every time you start a new project or a new session. The agent does not retain them between sessions.

Related built-in references

Before commissioning a new indicator, check whether the behaviour already exists. Many structural concepts used in the example — swing structure, fair value gaps, order blocks — are already implemented in the Market Structure Indicator, and the catalogues of free indicators and premium indicators list what ships with the platform.

Anatomy of a Good Indicator Prompt

Prompt specificity is the principle that a more detailed prompt produces output closer to your intent; a vague prompt forces the model to guess, and the result reflects the guess. The prompt used in the source video was deliberately vague — the author did not know the setup — and the first render was correspondingly generic. Detail is the single largest lever on output quality.

A good prompt has six blocks. Each block solves a specific failure mode.

Copy-paste prompt template

Replace the bracketed parts:

Create a new indicator for SabrTrader that shows historical and real-time setups for [SETUP NAME]. First, research the exact rules of this setup and list them back to me before coding. The rules I expect are: [YOUR OWN RULE LIST, NUMBERED, IN ORDER OF REQUIRED EVENTS].

Do not simply add some plots. Think carefully about the best way to visualise this setup on a chart, and use custom rendering where it produces a clearer result. The indicator must make the setup obvious at a glance and help me decide what to do now. Expose every threshold as a user setting with sensible defaults, grouped logically in the settings panel. Do not hardcode values.

Mark historical occurrences and also evaluate the forming bar for live setups. State explicitly in a comment whether any confirmation logic uses bars that would not have been available at signal time.

When it compiles, install it into the SabrTrader plugin folder and add it to my chart using the MCP server at [MCP URL]. Then take a screenshot, review your own output as a trader would, and fix anything that is unclear, overlapping or misleading. Repeat until it reads cleanly.

Use the SabrTrader SDK documentation at [SDK DOCS URL] and the open-source indicator examples at [GITHUB REPO URL]. Only work in this folder.

Specifying visuals explicitly

If you know what you want, say it in the prompt rather than discovering it over ten refinement rounds: colours, fill opacity, border weight, label position, font size, z-order, whether zones extend right, whether they terminate when filled, and where a statistics panel should sit.

What the Agent Actually Does, Step by Step

A typical run proceeds through the following phases. Watching them is how you catch a wrong turn early.

1. Reads the working folder. Establishes what already exists and where to write files.
2. Fetches the SDK documentation. Retrieves the pages relevant to indicators and rendering.
3. Lists MCP tools. Connects to the server URL and enumerates the platform actions available to it.
4. Studies example indicators. Pulls several source files from the GitHub repository as structural templates.
5. Builds a to-do list. Decomposes the task into ordered steps, visible in the agent panel so you can track progress.
6. Inspects chart data via MCP. Reads real bars to confirm instrument, timeframe, tick size and timestamps before writing time-based logic.

7. Writes the C# source. Produces the indicator class, its settings properties and its rendering code.
8. Compiles. Runs the build.
9. Enters the compile-fix loop. Reads compiler errors, edits the source, rebuilds. Repeats until the build succeeds. This is normal and often accounts for several iterations.
10. Renames and tidies classes, files and display names for consistency.

11. Copies the compiled plugin into the SabrTrader plugin folder.
12. Opens or reuses a chart and sets the timeframe. In the source run the agent switched the chart to 5-minute bars on its own initiative, because a kill-zone setup on one-hour windows needs intraday resolution.
13. Adds the indicator to the chart through MCP.
14. Takes a screenshot and saves it to disk.
15. Opens and analyses the screenshot, comparing what rendered against what it intended.
16. Patches and repeats — recompile, reinstall, re-render, re-screenshot.

Steps 14 to 16 are the part that most AI coding workflows lack, and they are what the MCP server enables.

The Closed Feedback Loop Explained

An AI closed feedback loop is a workflow in which the AI writes code, installs it, renders it, captures the result, evaluates that result and refines the code — with no human action required between steps. In this workflow the loop is:

1. Build — compile the plugin.
2. Install — copy it to the plugin folder.
3. Render — add it to a chart through MCP.
4. Screenshot — capture the chart image.
5. Evaluate — open the image and critique it.
6. Patch — edit the source and return to step 1.

The first render is rarely good. In the source run it showed session windows and a small statistics block, but no legible setups. What matters is what the agent did next, unprompted.

Self-corrections observed in a single run

• Fair value gap zones did not terminate at fill. The boxes ran past the point where price had already closed the gap. Fixed so a zone stops at the bar that fills it.
• Statistics numbers were not aligned. Changed to right-aligned so digits line up and are readable at a glance.
• Label collisions. Overlapping text on adjacent bars was resolved with layout logic that offsets or stacks labels.
• Opacity and contrast tuning. Zones were first too faint to see, then too heavy; the agent iterated toward a readable middle.
• Inverted visual hierarchy. The agent noted that the loudest object on the chart was a position box from a trade that resolved hours ago, while the current setup was faint — the opposite of what a trader needs.
• Sequence did not read as a sequence. It added explicit 1-2-3 numbering and connectors so the required order of events is visible, not merely inferable.
• No "what should I do now" cue. It added an actionable state readout rather than only historical annotation.

Why screenshots are the critical link

Trading indicators are judged visually. Correct logic rendered illegibly is a failed indicator. Without image feedback the agent can verify only that the code compiles and that values are computed; it cannot tell that two labels overlap, that a zone is invisible against the background, or that the eye is drawn to the wrong object. The screenshot converts a rendering problem into something the model can perceive and fix.

Reviewing the Generated Indicator Inside SabrTrader

Once the plugin is installed, open the indicator's settings panel from the chart exactly as you would for any built-in indicator. SabrTrader auto-generates the panel from the attributes on the indicator's public properties, so the groups you see are a direct reflection of how the agent structured its parameters.

Parameter groups produced in the example run

Treat generated parameters as a proposal

The agent chose these names, groups and defaults. You are free to rename them for clarity, regroup them so related settings sit together, delete parameters you will never change, and set defaults that match the instrument you trade. Ask the agent to make these edits; do not hand-edit the compiled plugin.

A useful follow-up request is a preset dropdown: a single enumerated setting (for example Minimal / Standard / Full) that switches whole groups of visual toggles at once, so you can strip the chart down without opening the panel and unticking eight boxes.

Trading Concepts Behind the Example Indicator

The example built in the source video is the ICT Silver Bullet. The definitions below stand on their own; you do not need prior knowledge of the methodology to follow them. Note the author's own disclaimer: a setup being popular is not evidence that it works.

Kill zone

A kill zone is a predefined time window during the trading session in which a strategy is permitted to look for setups. Outside the window, no entries are taken regardless of price action. Kill zones exist to concentrate activity in periods of higher participation and to prevent overtrading.

ICT Silver Bullet windows

The ICT Silver Bullet is a time-based intraday model restricted to three one-hour windows, expressed in New York time:

Buy-side and sell-side liquidity

Buy-side liquidity (BSL) is the cluster of resting buy-stop and breakout orders sitting above a prior swing high. Sell-side liquidity (SSL) is the cluster of resting sell-stop and breakout orders sitting below a prior swing low. Both are pools of orders that will execute if price reaches them.

Liquidity sweep (stop run)

A liquidity sweep is a move that trades through an obvious high or low, triggers the resting orders there, and then reverses. On the chart it appears as a wick or a brief extension beyond a prior extreme followed by rejection. In the model it is event 1: it establishes which pool has been taken and therefore which direction the subsequent move is expected to run.

Market structure shift (MSS)

Market structure is the sequence of swing highs and swing lows that defines trend or balance: higher highs with higher lows is an uptrend, lower highs with lower lows is a downtrend, overlapping swings are balance. A market structure shift is a break of the most recent swing high or low that signals a change in the prevailing short-term direction. In the model it is event 2: it confirms that the sweep produced a reversal rather than a continuation.

Displacement

Displacement is a fast, one-directional expansion of price — a run of large-bodied bars in the same direction with little retracement. It typically leaves an imbalance behind it because price moved faster than two-sided trading could fill.

Fair value gap (FVG)

A fair value gap is a three-bar price imbalance in which the wick of bar 1 and the wick of bar 3 do not overlap, leaving a price band that was traversed without two-sided trade. The unfilled band frequently attracts price back. In the model it is event 3 and it is the entry location: price retraces into the gap and the trade is taken there. A gap is filled when price trades back across it; a well-built indicator terminates the drawn zone at the fill bar instead of extending it forever.

Setup sequencing

Setup sequencing means numbering the required conditions so that the order of events, not merely their presence, validates the trade. For this model the valid order is:

1. Liquidity sweep — BSL or SSL is taken.
2. Market structure shift — the opposite-side swing is broken.
3. Displacement leaving a fair value gap — entry on the retrace into that gap.

Stop placement goes beyond the sweep extreme. The target is the opposing liquidity pool. An indicator that flags all three conditions without enforcing their order will mark invalid setups; this is why the agent later added explicit 1-2-3 numbering and connectors.

Historical versus real-time signals

A historical signal marks a past occurrence for study. A real-time signal evaluates the currently forming bar so the setup can be traded live. Both must be requested explicitly; an indicator that only annotates history is a study tool, not a trading tool.

Repainting

Repainting is when an indicator's historical markers differ from what could have been seen live, usually because confirmation used bars that had not yet formed at signal time. A repainting indicator makes any pattern look excellent in hindsight. Always ask the agent, in writing, whether confirmation logic references future bars, and require the answer in a source comment.

Session times and timezone handling

Time-based logic must map to the correct clock. Windows defined in New York time must account for the chart's timezone, the exchange's session definition and daylight-saving transitions in both zones. A one-hour offset error moves every kill zone onto the wrong bars and silently invalidates every marked setup.

Interpreting the On-Chart Statistics Panel

In the source run the agent added a statistics panel that nobody asked for: wins, losses, win rate and net result for the setups it marked on the visible data. Understanding what such a panel is — and is not — matters more than the numbers it shows.

How to read it

Why this is not a backtest

• Single instrument, single date range, visible bars only. These are in-sample numbers on whatever happens to be loaded on your chart.
• Assumed execution. There is no spread, no slippage, no commission, no queue position and no partial fill modelling.
• Assumed exits. Target and stop come from the indicator's own settings, not from an executed order.
• Intrabar ambiguity. If a bar touches both stop and target, the indicator must assume which came first; without tick data that assumption may favour the winner.
• Look-ahead and repaint risk. If any confirmation uses future bars, the sample is contaminated by hindsight.
• Parameter fitting. The defaults the agent chose may already reflect what looked good on the chart it was screenshotting.

Treat the panel as a sanity check — "does this pattern occur often enough and resolve often enough to be worth studying?" — not as evidence. For real numbers, convert the logic into a strategy and run a proper backtest through the strategy engine, or replay the period tick by tick using Market Replay, which delivers data in original sequence and removes hindsight from your own observation.

Step-by-Step Tutorial: Build Your First AI-Generated Indicator

Follow these steps in order. Each one has a verifiable outcome, so you can tell immediately where a run went wrong.

1. Install Visual Studio Code and the Claude Code extension. Download VS Code (free), open the Extensions view, search for Claude Code and install it. Sign in with your Claude account. Verify: the Claude Code panel opens inside VS Code and accepts a message.

2. Create an empty project folder and open it as the workspace. One folder per indicator project. Verify: the VS Code file tree shows only that folder.

3. Start SabrTrader and load a chart. Connect a data feed and open the instrument and timeframe you intend to develop against. Verify: bars are present and the chart is not empty.

4. Enable the MCP server. Go to Settings → Preferences → MCP Server, toggle it on, and copy the URL. Verify: the status shows enabled and a URL is displayed.

5. Compose the prompt. Use the six-block template from the prompt section. Insert your setup rules, the MCP URL, the SDK documentation URL, the GitHub repository URL and the folder scope guard. Verify: all three URLs are present before you send.

6. Set the model and permission mode. Default model for routine work. Enable bypass/auto-approve only if the folder is disposable and you will watch the run. Verify: the selected model and mode are shown in the agent panel.

7. Run the prompt and watch the to-do list. The agent should fetch docs, list MCP tools, read examples and produce an ordered plan. Verify: the MCP tool list appears — if it does not, the server is unreachable and everything downstream will fail.

8. Let the compile-fix loop finish. Build errors on the first attempts are expected. Verify: a successful build message and a plugin file written to disk.

9. Confirm installation. Check that the compiled plugin is present in the SabrTrader plugin folder and that the indicator appears in the platform's indicator list. Restart the platform if it does not appear. Verify: the indicator name is selectable when adding an indicator to a chart.

10. Confirm the render. The agent should add the indicator itself and take a screenshot. Verify: something draws on the chart and the screenshot file exists in the project folder.

11. Ask the agent to state the rules it implemented. Request a numbered list of the conditions and their required order, plus an explicit statement of whether any confirmation uses future bars. Verify: the list matches the setup as you understand it.

12. Review the settings panel. Open the indicator settings, check the parameter groups, and request renames, regroupings or new defaults. Verify: no important threshold is hardcoded.

13. Refine one issue at a time. Send single-issue instructions such as "the fair value gap zone should terminate at the fill bar" or "number the sequence 1-2-3 and connect the events". Verify: the screenshot after each patch shows the specific change.



14. Test across timeframes and instruments. Switch the chart from 5-minute to 1-hour and to a second instrument. Verify: session windows still land correctly and nothing renders off-scale.

15. Commit the working version. Initialise a git repository in the project folder and commit before any further refactor. Verify: git log shows a commit you can return to.

16. Save the chart template and workspace so the indicator, its settings and its layout reload next session. Verify: closing and reopening the workspace restores the configured chart.

Iterating and Refining Effectively

Refinement is where most of the value is created and where most of it is destroyed. The governing rule: specific, single-issue instructions improve an indicator; open-ended "make it better" instructions gamble with it.

Prompt patterns that work

• Concrete defect: "The fair value gap box should terminate at the bar where price fills the gap, not extend to the right edge."
• Explicit layout: "Right-align the numbers in the statistics panel and keep it anchored to the top-right corner."
• Sequence clarity: "Number the three events 1, 2, 3 and draw a thin connector between them so the order is visible."
• Role-play critique: "Look at this screenshot as a discretionary trader deciding whether to take this trade. What is unclear?"
• Targeted design question: "Is a shaded zone the clearest way to show the entry area, or would a bracket with a mid-line read better?"
• Rule verification: "List the conditions you implemented, in the order you require them, and quote the source you used for each."

Prompt patterns that backfire

• "Improve it." The agent will look for something to change and may minimise a design that was already working. In the source run, an open-ended improvement request produced a version the author judged worse than its predecessor.
• "Make it look better." Aesthetic direction without constraints leads to opacity and contrast oscillation.
• Bundling five unrelated fixes in one message. Debugging which change caused a regression becomes guesswork.

Version control is the safety net

Commit after every version you would be unhappy to lose. Git is the only reliable rollback: the agent's own memory of previous versions is unreliable across long sessions, and a compiled plugin overwrites its predecessor in the plugin folder. Tag versions with a short description of what changed so you can compare screenshots against commits.

Knowing when to stop

Stop refining when the indicator answers three questions instantly: Is there a setup?, Where is the entry, stop and target?, and What should I do right now? Additional visual detail past that point adds clutter, not information.

Best Practices

• Supply the SDK documentation and the GitHub examples in every prompt. They are the difference between working code and hallucinated API calls. The agent does not remember them between sessions.
• Scope the agent to one folder. One project, one directory, one git repository.
• Start from a setup definition you can verify yourself. If you cannot state the rules in numbered order, you cannot check whether the agent implemented them.
• Write visual specifications explicitly. Colours, fill opacity, border weight, label anchor, font size, z-order, extend-right behaviour and fill termination. Ten seconds of specification saves ten refinement rounds.
• Demand parameters, not constants. Every threshold, lookback, time window and colour should be a user setting with a documented default.
• Request both historical and real-time evaluation, and require an explicit written statement about whether confirmation uses future bars.
• Commit working versions before any refactor. Especially before an open-ended improvement request.
• Validate on multiple instruments and sessions. A threshold expressed in absolute points that works on one index future will misbehave on another; ATR-relative thresholds travel better.
• Check timezone mapping first when anything time-based misbehaves. It is the most common silent failure in session-restricted logic.
• Develop against a simulation account or a data-only connection while the MCP server is enabled, then disable the server when you finish.
• Read the generated source at least once. You do not need to write C# to spot a hardcoded date, a suspicious future-bar reference or a magic number.
• Move to a strategy when you need real numbers. Indicators annotate; strategies execute, backtest and optimize. See Auto Strategy Builder and AlgoStudio Pro.
• Check the built-in library first. Structural tools already exist — see the Market Structure Indicator and the free indicator catalogue — and building on them is faster than reinventing them.

Common Mistakes

Beyond Indicators: Strategies, Backtesting and Optimization

The same workflow applies unchanged to automated strategies. The only difference is which SDK surface the agent targets and which MCP tools it calls after the build.

Backtesting is replaying historical data through a strategy to measure hypothetical performance. Strategy optimization is systematically varying parameters to find the best-performing combination on historical data — and it is also the fastest route to curve fitting, so hold out data the optimizer never sees and re-test on it.

Because MCP exposes the strategy engine, the agent can run the backtest, read the results and patch the code without you clicking through the platform. That makes an automated optimize-and-refine loop technically easy and statistically dangerous; constrain the parameter space yourself.

Execution behaviour — order types, bracket attachment and how targets and stops are placed on fill — is a separate topic. Start with the SuperDOM and ATM strategy setup for the execution side, and Market Replay for rehearsing a strategy's behaviour on recorded tick data before it touches live capital. Visual strategy construction without prompting is covered in AlgoStudio Pro, and prompt-driven strategy generation in Auto Strategy Builder.

Frequently Asked Questions

What is the SabrTrader MCP server and what can an AI agent do with it?

The SabrTrader MCP server is a local server, built into the platform, that exposes SabrTrader's functions as tools an AI agent can call over the Model Context Protocol. Once enabled, an agent can do essentially anything you can do in the platform: open and close charts, change timeframe and bar type, add and configure indicators, read bar and tick data, take screenshots of charts, run strategies and backtests, and inspect trades and positions. In this workflow its most important role is feedback — it lets the agent see the visual result of the code it just wrote.

Do I need to know C# to build a SabrTrader indicator with Claude Code?

No. In the demonstrated workflow no code was typed by the user; the agent wrote, compiled, fixed and installed everything. However, you should be able to read code well enough to spot a hardcoded value, a suspicious reference to future bars or an assumption you disagree with. You are installing a compiled plugin that runs inside your trading platform, so a skim of the source before you rely on it is a reasonable minimum.

Where do I enable the MCP server in SabrTrader?

Open Settings → Preferences → MCP Server, toggle the server to enabled, and copy the URL shown on that page. Paste that URL into your prompt or into your agent's MCP configuration so the agent can connect. Disable the server again when you finish a development session.

Which Claude model should I use for building indicators?

Use the default general-purpose model for routine indicator work — it is fast, cheaper per token and sufficient for coding against a documented SDK with hundreds of examples available. Reserve the largest, slowest, most expensive model for genuinely hard problems: complex algorithms, intricate rendering maths, or a build that will not converge after several compile-fix cycles. Matching model capability to task difficulty is the main lever on cost and iteration speed.

Should I use the Claude Code CLI or the VS Code extension?

Both are functionally equivalent; the choice is ergonomic. The CLI is what installs by default. The Visual Studio Code extension runs the same agent inside a free editor where you can see the file tree, code diffs, terminal output and the agent's to-do list side by side, which makes it easier to follow a long run and to spot a wrong turn. The workflow in the source video uses the VS Code extension for that reason.

How does Claude Code know how SabrTrader indicators are written?

You tell it, in the prompt, by supplying two links: the SabrTrader SDK documentation (roughly 100 pages covering indicators, strategies and the rendering APIs) and the public GitHub repository containing the source of roughly 200 built-in indicators. The documentation supplies the API surface; the examples supply house style, lifecycle method usage, settings attributes and custom rendering patterns. Examples matter more than documentation alone because the agent imitates working code more reliably than it derives behaviour from prose. Supply both links in every new session — the agent does not retain them.

Where does the compiled indicator get installed?

Into the SabrTrader plugin folder. When the delivery instruction is present in the prompt, the agent copies the compiled plugin there itself after a successful build, then adds it to a chart through the MCP server. If the indicator does not appear in the platform's indicator list, confirm the file landed in the correct plugin folder and restart SabrTrader so it rescans for plugins.

Can the AI see what it built, or is it coding blind?

With the MCP server enabled it can see the result. The agent adds the indicator to a chart, takes a screenshot through MCP, opens the image and evaluates it. This is what closes the loop: build → install → render → screenshot → evaluate → patch. Without the MCP server the agent can only verify that the code compiles, not that the output is legible — and rendering problems such as overlapping labels, invisible zones or inverted visual hierarchy are invisible to a compiler.

Can I build automated strategies the same way, including backtesting and optimization?

Yes. The workflow is identical; only the SDK surface and the post-build MCP calls change. The agent can create a strategy, compile it, install it, run a backtest, read the resulting metrics, run a parameter optimization and refine the code based on what it read. Constrain the optimization search space yourself and hold out data the optimizer never sees, because an automated optimize-and-refine loop makes curve fitting effortless.

How do I stop the agent from touching files outside my project folder?

Use folder scoping. Create one empty folder for the project, open only that folder as the editor workspace, and add an explicit sentence to the prompt: "Only work in this folder; do not read or modify anything outside it." The workspace root and the instruction reinforce each other. This is especially important when bypass/auto-approve permission mode is enabled, because file writes then happen without a confirmation step.

Is the on-chart win rate from a generated indicator a valid backtest?

No. It is an indicative sanity check computed on the bars currently loaded on one chart, for one instrument, over one date range, using the indicator's own assumed stop and target. It excludes spread, slippage, commission, queue position and partial fills; it must guess the intrabar order of stop and target touches; and it is contaminated if any confirmation logic uses future bars. Use it to judge whether a pattern occurs often enough to study. For real numbers, convert the logic into a strategy and run a proper backtest, or replay the period tick by tick.

How do I verify the AI actually implemented the trading rules correctly?

Four checks. First, ask it to list the conditions it implemented, in the exact order it requires them, with the source it used for each rule. Second, compare that list to a rule definition you trust — one you can state yourself. Third, pick three marked setups on the chart and walk through them bar by bar, confirming each event occurred and occurred in the right order. Fourth, ask explicitly whether any confirmation uses bars that would not have been available at signal time, and require the answer as a comment in the source. Do not accept an unverified summary of a discretionary methodology.

What is the ICT Silver Bullet setup and which time windows does it use?

The ICT Silver Bullet is a time-based intraday model that only looks for entries inside three one-hour windows, expressed in New York time: 03:00–04:00, 10:00–11:00 and 14:00–15:00. Within a window the sequence is: a liquidity sweep takes buy-side or sell-side liquidity, a market structure shift breaks the opposite swing, and a displacement move leaves a fair value gap that price retraces into for entry. The stop sits beyond the sweep extreme and the target is the opposing liquidity pool. The order of the three events, not just their presence, is what validates the setup.

Why did the agent change my chart timeframe or open a new chart?

Because MCP grants it chart control and the prompt did not restrict which chart to use. An agent building a kill-zone model on one-hour windows will reasonably switch to an intraday interval such as 5-minute to see setups, and may open a fresh chart rather than reuse yours. To prevent it, name the target explicitly in the prompt: "Use only the existing chart with id/window X. Do not open new charts and do not change my timeframe without telling me."

How do I roll back if a refinement makes the indicator worse?

Restore the previous git commit and rebuild. Initialise a git repository in the project folder before the first run and commit every version you would be unhappy to lose, especially before any open-ended improvement request. The agent's own recollection of earlier versions is unreliable over a long session, and the compiled plugin overwrites its predecessor in the plugin folder, so version control is the only dependable rollback.

What is the difference between an indicator and a strategy in this workflow?

An indicator computes values from data and draws them on a chart; it annotates and can expose settings, but it does not place orders. A strategy contains entry, exit and sizing logic and can be executed, backtested and optimized by the strategy engine. Both are built with the same prompt-and-MCP workflow. Use an indicator to visualise and study a pattern; move to a strategy when you need measured performance statistics or automated execution.

What is repainting and why should I care about it here?

Repainting is when an indicator's historical markers differ from what could have been seen live, usually because the signal was confirmed using bars that had not formed yet. An AI agent asked to "show historical setups" will happily confirm each occurrence with hindsight unless told not to, which makes any pattern look excellent in review and unusable in real time. Always request an explicit statement about future-bar usage, and check live behaviour on the forming bar against the historical markers.

Do I need a live brokerage connection to use this workflow?

No. You need a data connection so the chart has bars for the indicator to compute on and render against. A simulation account or a data-only feed is preferable during development, because the MCP server grants the agent broad platform control and you do not want an agent experimenting near a funded account. Connect live only after the indicator is reviewed and you have disabled the MCP server.

Troubleshooting

The agent reports no MCP tools, or cannot connect to the MCP server

Check three things in order. First, confirm the server is enabled in Settings → Preferences → MCP Server. Second, confirm the URL you pasted into the prompt or MCP configuration matches the URL shown on that page exactly, including the port. Third, confirm SabrTrader is running — the server lives inside the platform and stops when the platform closes. Re-run the prompt and verify the agent lists the tool set before it starts coding; if the list is missing, everything downstream will fail silently.

The plugin compiles successfully but the indicator does not appear in SabrTrader

The compiled file is probably in the wrong location or the platform has not rescanned. Verify the file exists in the SabrTrader plugin folder — ask the agent to print the full destination path it used. Then restart SabrTrader so it rescans the plugin directory. If it still does not appear, check that the build targeted the framework version the SDK expects, and that the plugin file is not blocked by the operating system after being written by an external process.

The indicator loads but nothing draws on the chart

Work through the likely causes in this order. (1) Wrong timeframe: a kill-zone model needs intraday bars; on a daily chart no window will ever match. (2) Wrong instrument or insufficient history loaded. (3) Timezone offset: the session filter is comparing against a clock that never matches your bar timestamps, so every bar is excluded. (4) A quality or displacement threshold set so high that nothing qualifies — lower it temporarily to confirm the drawing code works at all. (5) Opacity set so low the drawing is invisible. Ask the agent to add a diagnostic mode that prints how many bars passed each filter stage.

Labels, boxes and the statistics panel overlap and are unreadable

This is chart clutter and label collision, and it is a layout problem rather than a logic problem. Send a specific instruction: "Detect label collisions and offset or stack overlapping labels", "Anchor the statistics panel to the top-right and give it a fixed width with right-aligned numbers", and "Reduce zone fill opacity so price bars remain visible through it". Also add toggles so individual elements can be switched off. Follow each patch with a screenshot review.

The most prominent object on the chart is not the most important one

This is inverted visual hierarchy — for example a large, saturated position box from a trade that resolved hours ago drowning out the current setup. Instruct the agent explicitly: "The active or most recent setup must be the highest-contrast element. Fade resolved or historical elements to low opacity, reduce their border weight and draw them beneath live elements in z-order."

The agent changed my chart timeframe or opened a chart I did not ask for

It has chart control through MCP and no instruction telling it which chart to use. Add to the prompt: "Use only the chart with id/window X. Do not open new charts. Do not change the timeframe without telling me first." If a stray chart was opened, close it manually and tell the agent which one is authoritative before continuing.

The build error loop never converges

The agent is guessing at API calls. Point it at a specific, structurally similar example in the GitHub repository by name and instruct it to copy that file's structure exactly, then substitute the logic. Also re-supply the SDK documentation URL for the specific area that is failing (rendering, settings attributes, data access). If it still stalls, switch to the larger model for this task only — this is the case that justifies the extra cost.

My trades or drawings disappeared from the chart after adding the indicator

They are almost always still present, hidden behind the indicator's overlays. Reduce the fill opacity of the indicator's zones, or ask the agent to draw its shapes beneath price and beneath trade markers in z-order. Toggling the indicator off briefly confirms the objects are intact.

Kill zones or session windows land on the wrong bars

This is a timezone mapping error. Confirm which clock the indicator uses (chart timezone, exchange time or New York time), confirm which clock your chart displays, and check daylight-saving handling in both zones. Ask the agent to expose the timezone as a user setting and to draw the window boundaries as vertical lines so you can verify them against actual bar timestamps rather than assuming.

A refinement round made the indicator worse and I want the previous version back

Restore the last good git commit and rebuild. If you did not commit, ask the agent to revert its most recent patch set — it can usually undo the last change but not reliably reconstruct a version from several rounds ago. Initialise git in the project folder now and commit before every further round.

The on-chart statistics show an implausibly high win rate

Suspect look-ahead. Ask the agent whether the signal or its outcome classification references bars after the signal bar, and whether the intrabar tie-break between stop and target defaults to the target. Also check whether targets and stops are derived from the same swing points the setup detection used. Then verify by comparing the marked historical signals with what the indicator produces on the forming bar in real time, or by replaying the same period tick by tick.

The agent edited files outside my project folder

The workspace root was too broad, the scope guard was missing from the prompt, or bypass permission mode allowed silent writes. Close the agent, restore any affected files from version control or backup, then restart with a single-purpose empty folder as the workspace and an explicit scope guard sentence in the prompt. Re-enable bypass mode only after the scope is confirmed correct.

Related reading

• AI Setup: Connecting an LLM Provider to SabrTrader
• Auto Strategy Builder (AI Strategy Generation)
• AlgoStudio Pro (Visual Strategy Designer)
• Market Structure Indicator
• SabrTrader Platform Setup: Workspaces, Charts, and Indicators
• Premium Indicators (Included in Paid Plans)
• Free Indicators (Included in Every Plan)
• Market Replay: Tick-by-Tick Historical Simulation