Skip to main content
Glama
FerroxLabs

TVControl

by FerroxLabs

batch_run

Run chart actions across multiple symbols and timeframes to automate universe scans, collect OHLCV data, and retrieve strategy results.

Instructions

Run an action across multiple symbols and/or timeframes

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to run for each symbol/timeframe. get_study_values reads every visible indicator per symbol and is the one to use for universe scans.
symbolsYesArray of symbols to iterate (e.g., ["BTCUSD", "ETHUSD", "AAPL"])
delay_msNoDelay between iterations in ms (0-60000, default 2000)
entity_idNoExact strategy entity ID for get_strategy_results; recommended when more than one strategy is present
timeframesNoArray of timeframes (e.g., ["D", "60", "15"])
ohlcv_countNoBar count for get_ohlcv action (1-500, default 100)
study_filterNoFor get_pine_tables: substring matching the indicator whose table to read. Omit for all.
restore_start_stateNoRestore the starting chart symbol/timeframe in a guaranteed cleanup path (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.5.3
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "screenshot",
      -  "get_ohlcv",
      -  "get_strategy_results",
      -  "get_study_values"
      -]New value: +[
      +  "screenshot",
      +  "get_ohlcv",
      +  "get_strategy_results",
      +  "get_study_values",
      +  "get_pine_tables"
      +]
    • addedInput schema / properties / study_filter
      Added value: +{
      +  "description": "For get_pine_tables: substring matching the indicator whose table to read. Omit for all.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changedv2.3.0
    • changedInput schema / properties / action / description
      Previous value: -"Action to run for each symbol/timeframe"New value: +"Action to run for each symbol/timeframe. get_study_values reads every visible indicator per symbol and is the one to use for universe scans."
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "screenshot",
      -  "get_ohlcv",
      -  "get_strategy_results"
      -]New value: +[
      +  "screenshot",
      +  "get_ohlcv",
      +  "get_strategy_results",
      +  "get_study_values"
      +]
  3. First observedv2.2.1

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral disclosure burden, and it is a single 9-word sentence that reveals nothing. Key traits are undisclosed: the tool mutates chart state (implied only by the restore_start_state parameter's mention of a 'guaranteed cleanup path'), loops with pacing delays, and has unspecified partial-failure semantics. The schema clues help, but the description itself adds no behavioral transparency.

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?

One front-loaded sentence with zero filler. The verb 'Run' leads, the resource follows, and the multi-symbol/multi-timeframe scope is delivered immediately. For a tool whose detailed parameter semantics live in the schema, this is ideal sizing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter orchestration tool with no output schema and no annotations, the description is too thin. It doesn't explain what the aggregated return looks like, how to choose between batch_run and similar siblings (strategy_sweep, quote_batch, the singular data_get_* tools), that the tool navigates the chart and restores state, or how failures in individual iterations are handled. The schema covers parameter meaning well but not these tool-level operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter meaning, but every parameter is well-documented in the schema with enums, ranges, defaults, examples, and usage hints (e.g., study_filter's substring matching, action's per-action guidance). The schema does the heavy lifting and the description doesn't need to compensate.

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 states a specific verb ('Run'), a resource ('an action'), and a clear scope ('across multiple symbols and/or timeframes'). This conveys the batch/fan-out nature that differentiates it from the singular data_get_* siblings (data_get_ohlcv, data_get_study_values, etc.), though it doesn't name an alternative explicitly.

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 never states when to use this tool vs. singular alternatives or other batch tools like strategy_sweep or quote_batch. Some usage guidance exists inside the schema — the action parameter notes get_study_values 'is the one to use for universe scans' and entity_id gives strategy-specific advice — but tool-level when-to-use/when-not-to-use context is only implied by the phrase 'across multiple symbols and/or timeframes'.

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

Deploy Server

Other Tools