tradingview-capture
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| capture_startB | Start capturing TradingView codes from one TradingView Desktop layout into output_dir. Returns a job id at once. history_from (YYYY-MM-DD, optional) first loads each chart's history back to 00:00 UTC on that date, or as far as TradingView goes. |
| capture_retryB | Retry the failed and pending symbols of an existing batch with the batch's own settings, history_from included. Returns a job id at once. |
| capture_statusB | Progress of a capture job, by job_id or by output_dir. |
| batch_summaryC | The manifest of a batch: per-symbol status, errors and file hashes. |
| symbol_dataC | Structured data for one symbol. parts: identity, tables, labels, lines, boxes, lastValues, drawings, readiness, inputs, plots, colors, fills, bands, notExported (default identity, tables, lastValues, drawings). series_last adds the last N CSV rows. |
| image_cropC | Crop a pixel region of a symbol's image.png and return it as a PNG image. |
| diagnoseB | Start TradingView Desktop briefly and report which internal paths a capture needs are available. Returns no chart contents. |
| output_pruneA | Keep the current day's capture batches and list the older ones under the output root; with apply=true move those older batch folders to the macOS Trash. Never deletes anything for good. keep_days counts today (1 keeps today only). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct stage or artifact: starting a capture, retrying a batch, checking job status, inspecting batch manifests, extracting per-symbol data, cropping images, diagnosing paths, and pruning outputs. The boundary between capture_start and capture_retry is explicit, and batch_summary vs symbol_data is clearly scoped by batch vs single symbol.
All names use snake_case, which is consistent, but the patterns vary: capture_* for lifecycle actions, noun_noun for resources (batch_summary, symbol_data, image_crop), and a bare verb (diagnose). It is still highly readable and predictable in practice.
Eight tools is well-scoped for a capture pipeline: start/retry/status plus inspection, data extraction, image cropping, diagnostics, and cleanup. No obvious redundancy or padding.
The surface covers the full capture lifecycle and post-capture access well, including retry and pruning. The main gap is the absence of a stop/cancel operation for an in-flight capture job, which could leave agents waiting on long-running jobs they cannot halt.