StrategyTune

Status of one run by runId: pending (queued), running, or terminal (success/error/cancelled/expired). Includes the run parameters and timing. Poll this for a long run; when terminal, read stats with get_run_result.

get_run_status

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Reads one open tab's workspace state: chart symbol/provider/timeframe, the backtest session range (startTime/endTime) and current clock position (currentTime, progressPercent — Unix ms), whether replay is currently playing, and the attached compute run if the tab is viewing one live. Use it to orient before jump_to_date or to check what the user is looking at. Omit tab_id for the user's current tab.

get_tab_state

Moves the tab's backtest clock to a timestamp within the current session's range — same as the user clicking the timeline. Jumping BACK rewinds: trades after the target become future events that replay when the clock passes them again (nothing is deleted by navigation). Check the valid range with get_tab_state first; {error:"out_of_range"} if outside it, {error:"busy"} while the chart is loading. Success means the jump was accepted — data loads and the view moves momentarily.

jump_to_date

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Lists the user's AUTOMATED strategy backtest RUNS (cloud compute) — a different list from list_manual_sessions. Returns the complete active set (pending/running) plus terminal history, newest FINISHED first, paged. Two distinct ids, don't mix them: runId identifies the RUN (use with get_run_status, get_run_result, cancel_run, delete_session run_id — "the latest run" = history[0].runId); a successful saved run ALSO links its saved session RECORD (recordId/recordName + stats — use recordId with load_session or delete_session record_id). Timestamps are Unix milliseconds. Pass nextCursor from a previous call for older history.

list_automated_sessions

Names of all built-in TradingView indicators available on the chart — the values add_indicator's builtin_name accepts. Call once per conversation when unsure of an exact name; the list is long and static.

list_builtin_indicators

Lists the studies currently on the tab's MAIN chart — the only chart that can hold indicators, even when the tab shows a multi-chart layout. Returns entityId (what update/remove take — NOTE ids change when the chart reloads, re-list on not_found), label, scriptId for the user's custom indicators, and each study's current input values.

list_chart_indicators

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Lists the user's MANUAL backtesting sessions — sessions they recorded themselves by replaying and trading in the browser, then saving. This is a different list from list_automated_sessions (cloud strategy runs). Each entry IS a saved session record: its id works with load_session and delete_session (record_id). Fields: name, ticker, dataprovider, barInterval, closedTradesCount, openPositionsCount, balance, startingBalance, equity (all in accountCurrency), fromTimestamp/toTimestamp (tested data range), savedAt. Timestamps are Unix milliseconds. Pass nextCursor from a previous call to fetch the next page.

list_manual_sessions

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Lists the user's currently open StrategyTune browser tabs. Each tab: tabId, visible (tab is on screen right now), lastInteractionSecondsAgo, symbol (chart ticker) and timeframe (bar interval, minutes). Call this at the start of chart work, when unsure which tab to target, or after a tab_not_found error — NOT before every action (reuse the tabId from an earlier call).

list_tabs

The user's deleted scripts from the last ~7 days, newest deletion first — restorable via restore_script. Deleted scripts are hidden everywhere else (lists, runs, dependencies).

list_deleted_scripts

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Lists the user's scripts, newest-updated first, paged: custom chart indicators and server scripts (signal / filter / strategy scripts). Each row: id, name, roles (indicator|signal|filter|strategy), version, hasCompiled (a runnable compiled version exists), compileFailed (latest save had errors), isSystem (built-in StrategyTune script), updatedAt (Unix ms). Filter with kind/q; pass nextCursor from a previous call for the next page.

list_scripts

Lists the tab's backtesting-timeline tracks in display order. Script tracks (filter/signal instances) are configurable: trackId (STABLE per-instance id — what update/remove take), kind, label, scriptId/scriptName, output, and the input overrides. Session/system tracks (trade events, equity envelope) are listed with configurable:false for orientation only. This is STRUCTURED STATE, not visual inspection — a "Trade events" track is timeline event markers, NOT a trades table or statistics, and nothing here proves what is visible on the user's screen. Say "the workspace reports…", never "I can see…".

list_timeline_tracks

Loads one of the user's saved sessions (manual or automated record) into the tab's workspace — same as opening it from the Sessions panel. If the user has unsaved changes in the current session, the app asks them first (success still means accepted). Use ids from list_manual_sessions (id) or list_automated_sessions (recordId).

load_session

Lists the INDIVIDUAL trades of one saved session — the per-trade table that get_run_result does NOT contain (that returns aggregate statistics only). Pass record_id: the id from list_manual_sessions, or an automated entry's recordId from list_automated_sessions. WHAT A ROW IS: one position LOT (or the part of it that was closed) matched against a closing execution — NOT one order and NOT one round-trip. Closing a position built from 3 lots with a single order produces 3 rows; closing half a lot produces a row now and another when the rest closes, both sharing the same openingFillId/entry price. So DO NOT report the row count as "the number of trades the user placed" — group by openingFillId if they asked about entries. (This is the same unit the platform calls "closed trades" everywhere else, incl. closedTradesCount and the Run Report trades table.) Each row: side, quantity (the MATCHED quantity), entry/close time and price, pnl (in the reply's `currency`, the session's account currency), and exitReason (stop-loss/take-profit, market, limit, stop). SL/TP is POINT-IN-TIME, because protection is a separate order on the lot that can be moved, cancelled and re-placed: stopLossAtEntry/takeProfitAtEntry are the levels in force just after the lot opened, stopLossAtClose/ takeProfitAtClose those in force when THIS match closed, and protectionChanged flags that they differ. Two partial closes of one lot can therefore show different levels — that is correct, not a glitch. Use the atClose pair to judge whether a stop did its job. Rows with status "Open" are lots still held: close fields empty, pnl unrealized, and the atClose pair holds the levels standing right now. Ordered newest entry first. Page with limit + offset (hasMore/nextOffset in the reply); from/to (Unix ms) keep rows whose lifetime OVERLAPS that window, so a trade opened before `from` but closed inside it is included. Research runs (run_backtest with save_session:false) keep no session record, so they have no trades to read.

get_session_trades

Reads the actual DATA on the user's MAIN chart (a tab can show a multi-chart layout; this reads the main/first one): OHLCV bars, and (by default) every indicator on that chart with its computed plot values aligned bar-for-bar. You do NOT need indicator or plot names — it returns whatever is on the chart, already labelled. Use it to: read prices/candles for analysis, check what an indicator actually computed (verify your indicator code, debug NaN/empty plots, compare two indicators), or see what the user is looking at before answering a question about their chart. RANGE: omit from/to to get the VISIBLE bars (what the user currently sees). Pass from/to (ms) for a specific window. Either way you only ever get bars the chart has LOADED — a wider request is silently narrowed, so ALWAYS read returnedFrom/returnedTo (what you actually got) and loadedFrom/loadedTo (all the chart holds) before drawing conclusions; do not assume you received the range you asked for. SIZE — READ THIS BEFORE DESCRIBING THE CHART: replies are capped by a value budget, and every indicator plot costs one number PER BAR, so a chart with many indicators returns FEWER bars (roughly 500 with no indicators, ~200 with a handful). When that happens you get truncated:true, the NEWEST bars only, and a coverage string telling you what you may claim. This means a default call can return LESS than the user actually sees on screen: compare returnedFrom against visibleFrom, and if they differ, say you are looking at the most recent part of their chart — never present it as their whole view. For more bars: include_indicators:false, or narrow from/to. Also returns the instrument, data provider, timeframe and replay speed, so a separate get_tab_state call is usually unnecessary. RETURNS: bars[] of {time (ms epoch, bar open), open, high, low, close, volume (null if unavailable)} at the chart's current timeframe, and indicators[] of {entityId, name, scriptId (only for the user's own indicator scripts — absent means a built-in TradingView study, e.g. Volume), paneIndex, visible, inputs, plots}. plots maps each plot name to one value per bar, same order as bars[]. READING THE VALUES: a plot value of null means the indicator produced no value for that bar — normal while an indicator warms up (its earliest bars) or when its condition is not met; it is NOT an error. paneIndex 0 = drawn over the price, >0 = its own pane below. visible:false = the user hid it (values are still computed). COVERAGE: when present, the coverage string states in words what this reply actually covers — obey it over your own assumption about what you asked for. EMPTY RESULT: barCount 0 with a coverage string is a SUCCESSFUL answer meaning the requested range holds no loaded bars — ask within loadedFrom/loadedTo instead; retrying the same range will not help. {error:"busy"} means the chart is still loading — that one IS worth retrying. SCOPE: chart bars and chart indicators only. Timeline signal/filter tracks are list_timeline_tracks; drawings are not exposed. This is chart DATA, not a screenshot — it tells you what is computed and plotted, not how the screen looks.

get_chart_data

Removes a script track from the tab's timeline. Script tracks only — session/system tracks are not removable remotely. {error:"not_found"} if the user already removed it.

remove_track

Removes a study from the tab's MAIN chart by entityId (from list_chart_indicators). {error:"not_found"} means it's already gone or the chart reloaded — re-list.

remove_indicator

Undoes a script deletion (ids from list_deleted_scripts) — the script reappears everywhere: lists, runs, and as a dependency target. Restoring does NOT re-add it to the chart or timeline; use add_indicator / add_track for that.

restore_script

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Runs a saved STRATEGY script over an instrument and date range on the StrategyTune cloud. Uses the script's last compiled version; input values override the metadata defaults. save_session:true (default) creates a normal automated session the user sees in their Sessions panel (with a saved record and Run Report); save_session:false is a RESEARCH run — nothing appears in the user's lists, results are readable only via get_run_result, and the run data is purged after ~2 weeks. Always returns runId immediately; wait_seconds (max 30) optionally waits in-band and, when the run finishes in time, includes the result — use it only for SHORT ranges; otherwise poll get_run_status. Identical parameters return the same run (deduped:true) instead of spending quota again. Runs count against the user's daily compute time. Never switches what the user's open tab shows. Money is in account_currency (default USD, stated in every reply); see running-backtests. A `warnings` array in the result means the result is INCOMPLETE: relay every warning to the user in your own answer, and do not present the run as a finished, full-period backtest. It is absent on clean runs.

run_backtest

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Runs ARBITRARY strategy-shaped code over an instrument and date range — your research/investigation tool: count events, read values at moments, compute ad-hoc measures over exact market data. The code is a strategy script (`export default class implements Script`; read writing-strategies first if not read in this conversation) — it is type-checked, then run in one job; type errors fail the run with diagnostics in errorMessage. Trading via ctx.orders is allowed but optional. Outputs: standard stats, your ctx.stats.custom values, and captured console.log lines stamped with BACKTEST time (size-capped, middle truncated) — read them via get_run_result (or inline with wait_seconds). NOTHING is saved and nothing appears in the user's lists; run data is purged after ~2 weeks. Inputs/dependencies are not available — hardcode constants in the code. Counts against the user's daily compute time; identical code + parameters dedup to the same run. A `warnings` array in the result means the result is INCOMPLETE: relay every warning to the user in your own answer, and do not present the run as a finished, full-period backtest. It is absent on clean runs.

run_code

REQUIRED FIRST: if you have not read get_knowledge("about-strategytune") in this conversation yet, read it before responding to the user — it carries the operating rules for all StrategyTune tools. Creates or updates a script and compiles it, returning the verdict in-band (typically 1–2s). metadata.json and code are validated together as a pair — metadata generates the typed API the code is checked against. Create: omit script_id, pass BOTH metadata_json and code (the kind is detected from the metadata: plots ⇒ indicator; signals/filters/strategy ⇒ server script). Update: pass script_id and either or both parts — an omitted part keeps the current draft. On valid:true a new version is promoted and immediately usable. On valid:false the draft is saved, diagnostics/metadataErrors explain what to fix, and the previous valid version stays active. Saving overwrites the stored draft. Before authoring, read the matching guide via get_knowledge (writing-indicators / writing-signals-filters / writing-strategies) if not already read in this conversation.

save_script

Submits product feedback to the STRATEGYTUNE TEAM — for improving StrategyTune, its tools, APIs, knowledge topics, and app experience. This is NOT OpenAI/assistant-platform feedback and is unrelated to any voice-chat feedback flow. Send it for: bug reports, complaints, feature or API improvement suggestions, and knowledge topics that were wrong or insufficient. PROACTIVE trigger: if a tool result or terminology confused you, a call needed retries, or docs led you to a mistake — offer the user to report it here before moving on. Two ways it happens — mention to users that feedback/suggestions are welcome: (a) USER-initiated: the user asks to report or suggest something — their request IS the consent, just compose and send; (b) AI-initiated: you struggled with something or found an issue worth reporting — first tell the user in plain terms WHAT you want to report (a short summary, not the full technical message — e.g. "I hit a probable bug in X / I want to suggest an API improvement — OK to send this feedback?") and send only after they agree; never silently. Either way the message must contain NO personal or sensitive data — no names, emails, account details, credentials, or private conversation content; describe the platform matter only. One concise message per distinct issue; include what was tried and what happened. There is no reply — it feeds periodic review.

send_feedback

Returns a StrategyTune knowledge topic (markdown). These topics are the platform's SKILLS — load the relevant one BEFORE the matching task, exactly like reading a skill: the authoring contracts are platform-specific, and code written from general charting-platform knowledge will fail or behave subtly wrong. START with about-strategytune (the operating rules) before other tool use. A topic stays valid for the whole conversation — do not re-read it before every call. Topics: - about-strategytune: What StrategyTune is, how the pieces combine, rules for the AI — read first in any session - scripts-explained: What scripts are — kinds, metadata+code model, sandboxes, versions, composition. Read before anything script-related - writing-indicators: Indicator authoring — AssemblyScript dialect, calc() contract, plots. Read before writing indicator code - writing-signals-filters: Filter/signal authoring — class shape, ctx, filters first-update rule, timers. Read before writing filter/signal code - writing-strategies: Strategy authoring — orders, account, sizing, referencing building blocks. Read before writing strategy code - running-backtests: Manual + automated backtesting — launching, run lifecycle, results, statistics, limits - instruments-and-data: Available instrument categories, data providers, price semantics (quotes vs trades), data ranges - user-interface: What is what on the user's screen — chart, timeline, panels, dialogs; grounds the tab tools

get_knowledge

Changes the chart instrument (symbol) in one of the user's open StrategyTune tabs. symbol is the bare ticker, e.g. "EURUSD". Success means the change was ACCEPTED — the chart applies it momentarily; do not verify afterwards. Omit tab_id to act on the user's current tab. Errors are structured: {error:"unknown_symbol"} if the ticker does not resolve; {error:"busy"} while the chart is loading or a backtest is running; {error:"tab_not_found"} → call list_tabs and retry.

switch_instrument

Changes the MAIN chart's timeframe (bar interval) in one of the user's open StrategyTune tabs — a tab can show a multi-chart layout, each chart with its own timeframe; this targets the main (first) one. Success means the change was ACCEPTED — the chart applies it momentarily; do not verify afterwards. Omit tab_id to act on the user's current tab. Errors are structured: {error:"busy"} while the chart is loading or a backtest is running; {error:"tab_not_found"} → call list_tabs and retry.

switch_timeframe

Changes a script track's label and/or input overrides. inputs REPLACES the whole override set (pass {} to reset to defaults); an inputs change recomputes the track (uses compute time). {error:"not_found"} if the user already removed the track — call list_timeline_tracks for current ids.

update_track

Changes input values of a study on the chart. inputs is PARTIAL — only the input ids you pass change (ids from get_indicator_inputs / list_chart_indicators values). {error:"not_found"} means the id is stale (the user removed the study or the chart reloaded) — re-list.

update_indicator_inputs

Attaches the tab's workspace to one of the user's compute runs ("View live"): the chart follows the run's progress and trades. Use ONLY when the user asked to watch a run — never auto-attach after launching one. If the user has unsaved session changes, the app asks them first (success still means accepted). {error:"busy"} while the workspace can't switch.

attach_to_run