Performance Implications When Using Different TradingView MCP Tools

When using TradingView MCP tools, performance bottlenecks stem from CDP round-trip latency, large JSON payloads that consume LLM context windows, and UI redraws triggered by chart manipulation commands.

The tradesdontlie/tradingview-mcp repository implements a Model Context Protocol (MCP) server that bridges Claude Code (or the tv CLI) with the TradingView Desktop application via the Chrome DevTools Protocol (CDP). Because every tool invocation traverses CLI → MCP → CDP → TradingView, understanding the performance implications when using different MCP tools is essential for maintaining responsive workflows and minimizing token consumption.

Understanding the MCP-to-CDP Architecture

Each tool call follows a strict multi-hop path that introduces inherent latency. First, the CLI or LLM client writes JSON to stdin. The Node.js MCP server parses this request, constructs a CDP command, and transmits it via WebSocket to localhost:9222. TradingView Desktop processes the command—potentially triggering UI redraws or data fetches—and returns a JSON response. Finally, the MCP server serializes the response to stdout for the LLM client.

This architecture means that even "simple" calls incur network round-trip costs to the CDP endpoint, and the payload size of the returned JSON directly impacts both server memory usage and LLM context window consumption.

Key Performance Factors

Network Latency to the CDP Endpoint

Although the CDP runs locally on localhost:9222, each request traverses the Node.js server and CDP socket. Repeated polling—such as calling chart_get_state every second—accumulates round-trip delays that can degrade responsiveness.

Payload Size and LLM Context Windows

Tools returning large JSON objects consume significant token budget. According to CLAUDE.md, data_get_ohlcv returns approximately 500 bytes in summary mode but roughly 8 KB for 100 full bars, while pine_get_source can exceed 200 KB for large scripts. Large payloads force earlier conversation history out of the LLM's context window and increase processing time.

Context-Management Defaults

The project enforces compact output through specific defaults: summary: true for OHLCV requests, mandatory study_filter parameters for Pine drawing tools, and caps on label counts. Bypassing these defaults in src/tools/data.js or src/tools/pine.js defeats the optimization design and slows both server and LLM processing.

Chart-Side UI Side Effects

Tools like chart_set_symbol, chart_set_timeframe, and chart_manage_indicator trigger UI redraws and indicator re-renders. On slower machines, chaining multiple UI-changing calls can freeze the TradingView interface for several seconds.

Concurrency Limitations

The MCP server processes one CDP command at a time. Executing multiple high-frequency streaming commands (tv stream …) alongside heavy data requests creates queueing delays.

Entity ID Caching and Reuse

The architecture recommends calling chart_get_state once per session to capture entityId values, then reusing those IDs in subsequent calls. Repeated state queries add unnecessary latency and payload overhead.

Performance-Optimized Tool Usage Patterns

Retrieve Compact OHLCV Data

Always use summary mode to minimize payload size:

tv ohlcv --summary

The underlying implementation in src/tools/data.js sets summary: true by default, ensuring approximately 500-byte responses rather than 8 KB full datasets.

Filter Pine Drawing Tools by Study

Limit label queries to specific indicators:

tv data labels --study_filter "Profiler"

Supplying the study_filter parameter reduces responses from several kilobytes to a few hundred bytes by restricting output to the selected study.

Avoid Fetching Full Pine Source Code

Do not retrieve complete script sources unless absolutely necessary:

# Avoid - returns >200 KB

tv pine get

# Prefer - compiles without large payload

tv pine compile

The pine_get_source tool implementation deliberately returns the full script text; the README.md explicitly warns against using it for large scripts.

Batch Operations with Lightweight Actions

Process multiple symbols efficiently:

tv batch run --symbols ES1! NQ1! --action ohlcv --summary

Using compact summaries keeps total data transfer under a few kilobytes even across many symbols.

Cache Entity IDs Across Calls

Store chart identifiers to eliminate redundant state queries:

// Acquire IDs once
const state = await tv.chart_get_state();
const chartId = state.chartId;

// Reuse in subsequent calls
await tv.chart_set_symbol({ chartId, symbol: "AAPL" });

As documented in CLAUDE.md, treat chart_get_state as a one-time initialization call per session.

Critical Source Files Affecting Performance

Several modules directly influence execution speed and payload size:

• src/tools/data.js: Implements OHLCV and strategy data tools, containing the logic that determines summary versus full bar requests.
• src/tools/pine.js: Handles Pine drawing tools (data_get_pine_*), enforcing study_filter and label count caps.
• src/tools/chart.js: Provides chart control tools including chart_get_state, which should be called only once per session.
• src/tools/_format.js: Central formatting helper that trims and structures responses before CDP transmission.
• CLAUDE.md: Documents the decision tree and performance rules including output size estimates and context management guidelines.

Summary

• Network latency accumulates with each CDP round-trip to localhost:9222, making repeated polling expensive.
• Payload size directly impacts LLM token usage; prefer summary: true (500 B) over full OHLCV data (8 KB) and avoid pine_get_source (>200 KB).
• Context-management defaults in src/tools/data.js and src/tools/pine.js optimize output; bypassing them degrades performance.
• UI side effects from chart_set_symbol and similar tools cause redraws that freeze the interface when chained.
• Concurrency limits serialize CDP commands, causing queueing when mixing streaming and heavy data requests.
• Entity ID caching via chart_get_state eliminates redundant state transfers when reused across the session.

Frequently Asked Questions

Why is chart_get_state slow when called repeatedly?

Each invocation triggers a full CDP round-trip and returns complete chart metadata. The tradesdontlie/tradingview-mcp architecture designates this as a one-time initialization call; store the returned entityId values and reuse them instead of re-querying.

How does summary: true affect data_get_ohlcv performance?

When summary is enabled (the default in src/tools/data.js), the tool returns approximately 500 bytes of aggregated data rather than ~8 KB for 100 full bars. This reduces network overhead, server memory usage, and LLM token consumption.

What causes TradingView Desktop to freeze when using MCP tools?

Tools like chart_set_symbol, chart_set_timeframe, and chart_manage_indicator trigger UI redraws and indicator re-renders. Chaining multiple UI-changing commands overwhelms the rendering thread, particularly on slower machines.

Can I run multiple MCP tools in parallel?

No. The MCP server processes CDP commands sequentially. Running concurrent high-frequency streaming commands alongside heavy data requests creates a processing queue, increasing latency for all operations.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}