Skip to main content
Glama
Sign In
TradingView MCP

TradingView MCP

by madiver
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

batch_run

Run screenshot, OHLCV, or strategy-result actions across multiple symbols and timeframes in one pass, with configurable delays and bar counts.

Instructions

Run an action across multiple symbols and/or timeframes

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbols": "<symbols>",
      "action": "<action>"
    },
    "name": "batch_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesAction to run: screenshot, get_ohlcv, get_strategy_results
symbolsYesArray of symbols to iterate (e.g., ["BTCUSD", "ETHUSD", "AAPL"])
delay_msNoDelay between iterations in ms (default 2000)
timeframesNoArray of timeframes (e.g., ["D", "60", "15"])
ohlcv_countNoBar count for get_ohlcv action (default 100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/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 burden of behavior disclosure, but it only says 'run an action' with no mention of iteration order, delays, error handling, side effects, or result aggregation. It omits whether execution stops on failure or continues per symbol, and whether the tool returns per-item results or a single summary. This is a significant gap for a batching wrapper.

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 single sentence is front-loaded, on-topic, and contains no wasted words, making it concise and easy to scan. However, the brevity skips behavioral details that the tool likely needs, so while the structure is good, it is not fully informative.

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 a tool with 5 parameters, no annotations, and no output schema, this description is incomplete. It does not explain how the batch loop behaves, what the return payload looks like, or how errors from individual symbols/timeframes are surfaced. An agent cannot predict the tool's full contract from this definition alone.

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 coverage is 100%: every parameter (action, symbols, delay_ms, timeframes, ohlcv_count) has a description, so the schema already documents each field's meaning. The description only reinforces the symbols/timeframes components and does not add syntax, defaults, or cross-parameter relationships beyond the schema. Baseline 3 applies because the schema does the heavy lifting.

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 clear verb (run) and a specific resource ('an action across multiple symbols and/or timeframes'), which conveys the batching purpose without being a tautology. It distinguishes from siblings by emphasizing the multi-symbol/timeframe scope, though it does not explicitly name the allowed actions or contrasting single-action tools. The schema fills the action-list gap, so this is a minor omission.

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 implies that the tool should be used when the same action needs to be repeated over multiple symbols or timeframes. However, it does not explicitly contrast with single-action tools like data_get_ohlcv or capture_screenshot, nor does it provide when-not-to-use guidance or alternatives. The intended use is inferable but not clearly articulated.

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