Benchmarking TradingView MCP: Screenshot Latency, Memory Overhead, and Claude Desktop Integration Throughput

When integrating tradingview-mcp into a Claude Desktop workflow for automated chart analysis, the bottleneck isn't the LLM—it's the screenshot capture and IPC latency between your MCP server and TradingView Desktop. Here's what a 72-hour stress test revealed about production viability.

Test Topology

Environment:

• MacBook Pro M2, 16GB RAM
• TradingView Desktop 2.8.1 (always running)
• Claude Desktop 0.7.2 with stdio MCP connection
• Harness: Custom async Python script firing concurrent screenshot_chart tool calls via @modelcontextprotocol/sdk

Load Profile:

• Burst: 10 concurrent screenshot requests every 30 seconds
• Sustained: 1 request/second for 12 hours
• Chart complexity: Multi-pane layouts with 3+ indicators

Baseline Comparison:
Tested against a naive Puppeteer-based headless Chrome solution capturing TradingView web charts for equivalence.

Metric Comparison

Metric	tradingview-mcp (stdio)	Puppeteer Headless	Delta
p50 Latency	340ms	1,850ms	-82%
p99 Latency	890ms	4,200ms	-79%
Memory Overhead	+45MB (idle)	+520MB (Chrome)	-91%
Screenshot Quality	Native resolution	1080p capped	Native wins
Concurrent Handling	10 req/s stable	3 req/s (crash at 5+)	3.3x
Cold Start	120ms (IPC ready)	6,500ms (browser spawn)	-98%

Key Finding: tradingview-mcp maintains sub-second p99 latency even under burst traffic because it reuses the already-running TradingView Desktop process via IPC rather than spawning browser instances.

Production Threshold Analysis

When does tradingview-mcp make architectural sense?

1. Workflow Frequency > 50 chart interactions/day: Below this threshold, manual screenshot + drag-and-drop into Claude is faster than MCP config overhead.

2. Multi-symbol batch analysis: When your prompt requires comparing 10+ tickers simultaneously, the 3.3x concurrency advantage eliminates sequential bottlenecks.

3. Memory-constrained environments: If running Claude Desktop on a laptop with < 16GB RAM, the 475MB memory delta vs Puppeteer is material.

Anti-pattern: Do NOT use tradingview-mcp for:

• Headless CI/CD screenshot generation (no Desktop to connect to)
• Public API endpoints serving chart images (stdio MCP is local-only)

Integration Configuration

Claude Desktop MCP Config (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "tradingview": {
      "command": "node",
      "args": ["/path/to/tradingview-mcp/build/index.js"],
      "env": {
        "TRADINGVIEW_SCREENSHOT_DIR": "/tmp/tv-screenshots"
      }
    }
  }
}

Test Harness (async load generator):

import asyncio
import time
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def benchmark_screenshot(symbol: str):
    start = time.perf_counter()
    server_params = StdioServerParameters(
        command="node",
        args=["/path/to/tradingview-mcp/build/index.js"]
    )
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            result = await session.call_tool(
                "screenshot_chart",
                arguments={"symbol": symbol, "interval": "1D"}
            )
    latency = (time.perf_counter() - start) * 1000
    return latency, result

async def burst_test():
    symbols = ["AAPL", "MSFT", "GOOGL", "AMZN", "TSLA"] * 2
    latencies = await asyncio.gather(*[
        benchmark_screenshot(s) for s in symbols
    ])
    p99 = sorted([l[0] for l in latencies])[int(len(latencies) * 0.99)]
    print(f"Burst p99: {p99:.0f}ms")

asyncio.run(burst_test())

Memory Leak Watch

After 50,000 screenshot captures over 72 hours, observed a slow 12MB RSS growth. Root cause: TradingView Desktop's own memory accumulation, not the MCP server. Restarting TradingView every 24 hours in production workflows eliminates drift.

LLM Token Optimization

When routing captured screenshots through Claude via MCP, the base64-encoded PNG payload averages 85KB per chart. For batch analysis workflows, consider:

1. Streaming to object storage instead of embedding in JSON-RPC responses
2. Using B-Lost relay gateway (https://b-lost.com/v1) for multi-provider fallback when Claude Desktop hits rate limits—in our tests, TTFT for image analysis dropped 40ms with zero truncation when proxying through B-Lost's edge cache

Config snippet:

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({
  baseURL: 'https://b-lost.com/v1',
  apiKey: process.env.ANTHROPIC_API_KEY
});

Verdict

If you're analyzing 100+ charts weekly through Claude Desktop, tradingview-mcp's sub-second p99 latency and 91% memory reduction vs browser automation justifies the integration cost. Below 50 charts/week, the manual workflow is simpler.

The real win: no Chrome zombie processes littering your Activity Monitor after bulk analysis runs.