u/Accurate-Mirror-143

Please add an optional AI-assisted review when creating, modifying, or activating trading strategies.

The AI could use the strategy parameters together with the current chart, broader market conditions, relevant exchange rates, and recent news as context, where available. It could ask the user to explain the strategy’s rationale, assumptions, entry and exit logic, risk management, and conditions under which the strategy should no longer be used.

Rather than rating or approving the strategy, the AI should act as a sparring partner — challenging assumptions, identifying inconsistencies or overlooked risks, and pointing out where the strategy may behave differently under changing market conditions.

This would add an interactive learning and reflection layer to strategy development while leaving strategy design, activation, and execution fully under the user’s control.

Please add an optional AI-assisted review as a configurable behavior for the Buy and Sell buttons.

Users could choose whether these buttons place an order directly, open the regular order dialog, or only start a compact AI review without submitting an order. The last option would be particularly useful for manual traders whose broker is not connected to TradingView.

The AI could consider the current chart, trade parameters, market conditions, relevant exchange rates, and recent news to challenge the user’s thesis and highlight overlooked risks or inconsistencies.

This would allow TradingView to support reflection and hands-on learning even when the actual order is placed manually outside the platform.

Please allow users to create reusable symbol dashboards by combining existing components from Financials, Technicals, Forecasts, Documents and other views via drag and drop.

Dashboards could be extended with structured custom fields such as Rating, Quality, Risk, Thesis and Review Status, saved as templates and automatically updated for the selected symbol.

This would add a personal interpretation layer without duplicating TradingView’s existing data and visualizations.

Titles of related feature requests:

- Watchlist Dashboard - Other-Increase-2593

- Custom Watchlist Field - nathan57877

- Display Pine Values in Watchlists - Accurate-Mirror-143

- Dedicated Result Pane for Indicators - Accurate-Mirror-143

Pine Script can process market, price, and indicator data comprehensively, but it reaches its limits when a task cannot be expressed as a formula or implemented in a fixed algorithm. At the same time, much of the information needed to put a signal into context lies outside the chart and is available primarily as text.

The proposal adds typed AI queries to Pine. They would transform data and text that are difficult to formalize into outputs that a script can display or process directly. Simple queries would return a string, float, int, or bool; more complex results could be returned as a user-defined type (UDT) containing the actual value as well as status, source, and time information.

The aim is not to introduce a general-purpose chat interface within the chart, but to provide Pine functions with defined inputs, return types, and status values.

A script could, for example, classify an already calculated feature vector as a trend, sideways, or reversal regime, assess the clarity of a market structure, or summarize several indicator states in an understandable sentence.

Users could also enter an excerpt from a report, a message, or a transcript into an input field in the configuration menu and have it analyzed. The text could, for example, be summarized, assigned to a predefined category, or assessed according to specified criteria.

Research functions could additionally incorporate external, particularly current, information about the symbol being viewed, including news flow and market sentiment, statements from earnings releases, regulatory changes, production disruptions, weather events, or central bank decisions.

The primary benefit would not be to replace a technical condition with an AI opinion, but to place already identified signal combinations into context more quickly and from an expert perspective. A technical signal could therefore be directly linked to an understandable explanation and the currently relevant external developments.

Functions for supplied data and text could reside in the ai.* namespace. Requesting external information semantically belongs in the request.* namespace.

The following syntax is intended only as one possible implementation:

string regime = ai.string(

instruction = "Classify the supplied feature vector.",

choices = array.from(

"uptrend", "downtrend", "sideways", "reversal"),

data = features)

float clarity = ai.float(

instruction = "Assess the clarity of the market structure.",

data = features,

min_value = 0.0,

max_value = 1.0)

string summary = request.ai_string(

instruction = "Summarize the most important current developments.",

subject = syminfo.tickerid)

A model query must not consume the regular Pine execution-time budget while waiting for an external AI platform. The Pine functions would therefore act as interfaces to a platform-side service.

Script execution could be suspended at the call site. While the script is waiting for the AI platform’s response, time tracking for the Pine execution budget would be paused. Once a response is available or a predefined timeout has been reached, execution would resume at the same point with the remaining time budget.

From the script’s perspective, the function would therefore behave like a normal function call: once execution resumes, either a typed result or an identifiable error status is available.

A particularly relevant use case would be alert enrichment. The technical Pine condition would trigger the alert, after which TradingView would add current, symbol-specific context, including sources. This would keep the technical condition separate from the research while still providing the user with an immediately understandable explanation.

For users, this would provide a way to work with relationships that cannot be expressed as formulas or implemented in fixed algorithms. Technical signals, user-supplied texts, and current external events could be analyzed, presented clearly, and related to one another within the same environment. The need to switch between the chart, search engines, news portals, and manual post-processing would be significantly reduced.

For authors, this would create new possibilities for indicators with closed-set classifications, numerical assessments, explanatory outputs, and optional current context. Results could be used directly in labels, tables, colors, and alert messages.

The proposal would therefore add more than merely “AI” to Pine. It would provide a defined analysis layer for data, text, and external information.

Titles of related feature requests:

- Push Pine Market-State Objects to External AI Agents - Accurate-Mirror-143

- Inclusion of External API Call in PineScript – for Actual integration of AI Models - santanudas2002

- A sincere plea to the TradingView team: External API support for Pine Script - bigbaldy1128

- Wishing for a way to retrieve external data in a Pine Script Indicator - BuyerFamous7244

- External data into TradingView pinescript (Pine seed?) - cheesycrustz

- MCP codex + Claude & Possibility to import, export or downloading Financial & Macro Data - FrostingAgreeable309

Please add a mechanism that allows Pine indicators to push structured user-defined type objects to externally configured AI agents.

A TradingView indicator can perform the deterministic part of technical analysis. Interpreting that state in a broader context and presenting it through a customized interface are separate tasks that do not necessarily belong inside Pine.

In the proposed workflow, the private indicator would serve as a specialized data source. Pine would calculate a structured snapshot for the latest completed bar. An external AI agent could then interpret the snapshot, combine it with model knowledge, use additional tools or web research where appropriate, and produce a qualitative or multidimensional analysis.

The transmission to the AI agent should support serializable Pine values such as string, int, float, and bool, as well as arrays of these values. This would allow each snapshot to combine the current market state with a deliberately selected history of relevant values or events or pre-processing results. The latest completed bar would determine when the snapshot is generated, but not the temporal scope of its contents. Pine would remain responsible for calculating, selecting, and preprocessing all transmitted context.

The AI would not become part of the Pine calculation. Pine would remain responsible for deterministic and reproducible market-data processing, while the external agent would provide a separate layer for post-processing, interpretation, and presentation. Indicator calculations would therefore not depend on non-deterministic AI responses.

One important application would be the generation of custom analysis interfaces. Instead of requiring the presentation to be hard-coded in Pine or manually developed as a separate web application, users could describe the desired output to the agent in natural language (I noticed that this works very well).

For example, a user could ask the agent to create an interactive dashboard comparing trend quality, momentum, volatility, and breakout conditions. The agent could translate that instruction into a functional HTML interface containing radar charts, time-series views, heatmaps, scorecards, comparison tables, filters, tabs, symbol selectors, configurable time windows, or multiple connected pages.

Users could revise the interface through further natural-language instructions to their agent. This would enable individualized analysis and visualization workflows without requiring a new Pine script or separately programmed frontend for every variation.

The indicator could operate on any chart timeframe, while snapshot transmission would have its own configurable maximum frequency. A data snapshot would normally be pushed only for the latest completed bar. Pine logic could optionally restrict transmission to relevant state changes, confirmed signals, or other script-defined events.

No analytical data would need to return to the Pine calculation. If the external service makes the generated output available at a URL, the user could access it through a clickable link displayed on the chart or in the indicator pane.

A Pine user-defined type would provide a natural way to describe the transmitted dataset:

//@type Technical market state calculated for the latest confirmed bar.

//@field trendDirection Detected direction of the technical trend.

//@field relativeStrengthIndex RSI value between 0 and 100.

//@field averageTrueRange ATR in the symbol's price units.

//@field breakoutConfirmed True when the completed bar confirms a breakout.

//@field trendScore Normalized assessment of trend quality.

type MarketState

string trendDirection

float relativeStrengthIndex

float averageTrueRange

bool breakoutConfirmed

float trendScore

The script could construct an object of this type from its calculated values:

state = MarketState.new(

trendDirection = trendState,

relativeStrengthIndex = rsiValue,

averageTrueRange = atrValue,

breakoutConfirmed = breakoutState,

trendScore = calculatedTrendScore

)

A new function such as agent.push() could transfer the object when the snapshot is ready:

if barstate.isconfirmed

agent.push(

data = state,

id = "market-state",

freq = agent.freq_once_per_bar_close

)

As an optional extension, the external service could make the generated output available at a URL. Because external processing may take time, agent.push() should return immediately rather than wait for this URL or return it as a regular Pine value. A separate function such as agent.link() could use the same ID to expose the resulting resource if a URL becomes available:

agent.link(

id = "market-state",

title = "Open market analysis",

location = agent.location.pane

)

Alternatively, the link could be attached to an existing Pine visual object:

var label analysisLabel = label.new(

bar_index,

high,

"Open market analysis"

)

label.set_xy(

analysisLabel,

bar_index,

high

)

agent.link(

id = "market-state",

target = analysisLabel

)

The location and target parameters would represent alternative display modes. location could place a dedicated control on the chart or in the indicator pane, while target could make an existing Pine visual object, such as a label or box, clickable.

If the external service provides a URL, TradingView could associate it with the corresponding indicator instance and the ID used by agent.push(). TradingView could then update either the dedicated link control or the visual object associated through agent.link(). The URL would be handled outside the Pine calculation and would not affect script execution. The resource available at that URL and its internal structure would remain outside the scope of Pine and TradingView.

The exact function names and signatures are illustrative. The essential capabilities would be to push a Pine UDT while preserving its type name, field names, field types, and current values, and to expose the resulting external resource through a declarative link associated with the same ID.

The existing //@type and //@field annotations could optionally be included as schema metadata. This would allow the receiving agent to understand each field’s intended meaning, scale, or unit rather than receiving only its name and current value.

TradingView could automatically serialize the UDT into a suitable transport format. Pine authors would not need to construct JSON strings or implement formatting and escaping logic. The transmitted representation could internally contain information equivalent to:

{

"type": "MarketState",

"fields": {

"trendDirection": {

"type": "string",

"value": "bullish",

"description": "Detected direction of the technical trend."

},

"relativeStrengthIndex": {

"type": "float",

"value": 63.7,

"description": "RSI value between 0 and 100."

},

"averageTrueRange": {

"type": "float",

"value": 4.18,

"description": "ATR in the symbol's price units."

},

"breakoutConfirmed": {

"type": "bool",

"value": true,

"description": "True when the completed bar confirms a breakout."

},

"trendScore": {

"type": "float",

"value": 0.82,

"description": "Normalized assessment of trend quality."

}

}

}

This transport representation would be generated by TradingView. From the Pine author’s perspective, the UDT would simultaneously serve as a calculation object, a compile-time-checked data schema, and an interface definition for the external agent.

agent.push() should create a structured outbound event rather than execute a provider-specific network request directly from Pine. It should neither contain provider credentials nor depend on a specific external service. TradingView would handle serialization, authentication, routing, and delivery to the configured agent.

The target agent, endpoint, permissions, maximum dispatch frequency, and other provider-specific settings could be configured separately in the TradingView interface. The configuration could support ChatGPT, Claude, self-hosted agents, and other compatible services without coupling Pine to a single provider.

This approach would establish a clear division of responsibilities. Pine would calculate and submit a reproducible UDT snapshot, TradingView would serialize and route it, and the external agent would interpret the information and generate a configurable, potentially interactive and multi-page analysis interface. If the external service provides a URL, TradingView could associate it outside the Pine execution, using the same ID, with a declared link or Pine visual object.

Please indicate directly in the chart, for example in Symbol Details, whether the displayed security is shown for its home market, and optionally allow charts from non-home markets to be blocked.

At least in Germany, brokers commonly support trading the same security with the same ISIN at very different domestic and international venues. When intending to trade at a liquid venue or in a particular currency, users must ensure that they do not inadvertently base their decision on the price history of another venue.

The home exchange is normally the most liquid market for a security. A direct indication would therefore be useful, while an optional restriction could help traders who want to use charts from home markets only.

Titles of related feature requests:

- ISIN-based filter in symbol search

- syminfo.prefixes(ISIN) for Parallel Market Discovery

- Cross-Exchange Listings & Identifier Mapping in Pine

Please introduce a unified panel system that allows modules such as Watchlists, Symbol Details, News, and Indicator Settings to be positioned flexibly within the TradingView interface.

These modules should be resizable, dockable to either side of the chart area, arranged beside or above one another, placed into a cell of a multi-chart layout instead of a chart, or detached into a separate window for multi-monitor use.

Currently, several TradingView modules use different and largely fixed presentation models. A common panel system would make better use of available screen space, provide a more flexible workflow, and reduce cognitive load by giving users one consistent interaction model for positioning and managing panels. Existing positions and behavior could remain the default.

TradingView Desktop’s Tab Symbol Syncing already provides a workaround for some multi-window workflows. However, it is unavailable in regular browsers and on tablets, and it does not allow individual modules to be freely docked, arranged, or placed inside multi-chart layouts.

&gt;> Titles of related feature requests <<

Detached Watchlist with Chart Syncing — Suitable_Lemon_867

Detachable watchlist — Scared_Bike_11

The ability to have a separate window for watchlists, and the ability to link windows — alexmandaro

Multiple Watchlists (either vertically stacked or in detachable windows) — Ivid106

Dockable Indicator Settings Panel in Sidebar — Accurate-Mirror-143

Dockable non-modal Indicator Settings Panel — Accurate-Mirror-143

Allow Left-Side Docking of the Pine Editor to Improve UI Stability — Accurate-Mirror-143

Detach Function for Improved Multi-Monitor Use with Windows Snap Support — Accurate-Mirror-143

Remark: The Snap feature also works in the desktop app using Windows key + Z; only the hover functionality is missing.

Please show a compiler warning when a Pine Script library import is unused instead of merely silently optimizing it away. This would help developers and reviewers detect obsolete imports and potential mistakes.

Titles of related feature requests:
- Highlight unused variables & functions
- Marking Unused Functions and Variables
- Early Warning for Non-Exported Functions in Libraries
- Warning for outdated library versions in the Pine Editor

When switching symbols, the Metrics → Financials window should retain its current scroll position (selected subsection) as long as the window remains open, instead of resetting to the top. This makes comparing the same financial section across multiple watchlist symbols much more efficient.

Titles of similar feature requests:

- Pinned Indicator Settings Panel Across Symbol Changes

- Preserve open Detail Panel when opening Alert Log

- Preserve X-Axis Date Range When Resizing Browser or Expanding Panels

Please add Pine Script access to the full company profile/business description shown in TradingView.

When browsing a watchlist, I use custom Pine indicators to quickly assess each stock. I would also like to display the full company profile directly in a Pine table, instead of manually opening the profile section for every symbol.

syminfo.description only returns the symbol name, not the full profile text.

Titles of related feature requests:

Feature Request: Please provide Pine Script access to Market Cap, Shares Outstanding, & other fundamental data

syminfo.news

More data access in Pine Script

Please allow users to drag Watchlist symbols directly onto the chart. “Add <ticker> to compare” is already available in the context menu, but drag and drop would provide a faster and more intuitive workflow.

Related feature requests:

Multiple watchlists, drag/drop tickers between watchlists

View two watchlists side-by-side, drag drop symbols between them

https://preview.redd.it/m18uywnef7hh1.png?width=131&format=png&auto=webp&s=08ae38a5c7d058c4b66e44f0941b88c4914513d7

Please allow users to display at least one selected numeric Pine indicator output as a sortable watchlist column.

This would let users rank symbols without opening every chart and provide a direct watchlist alternative to a separate screener workflow.

Related earlier feature requests:

“Indicator-Generated Text in Watchlist Tooltips”

“Closed-Loop Pine Screening”

Please allow users to reorder the existing round shortcut buttons for Templates, Layouts, and Watchlists via drag and drop.

Currently, their order is defined by the order in which items were favorited. Changing it later is inconvenient because users may need to remove and re-add favorites just to rearrange shortcuts.

Drag-and-drop reordering would preserve the current favorite-based default while making the shortcut order easy to adjust.

There could be an optional filter that checks how comparable hypothetical bracket trades for the same instrument on the same venue, using either a stop-market or a stop-limit order, would have performed based on historical market data before a new trade is submitted.

The user could define:

– one or more timeframes

– one or more lookback periods

– the minimum number of comparable historical trades

– the minimum expected profit, including fees and slippage

– whether the system should warn or block the trade if the threshold is not met

The user could specify whether the required threshold must be met across all selected combinations or based on an aggregated result.

The expected profit would combine the historical win rate with the average gains and losses.

Example:

“Trade blocked: the minimum expected profit was not met across the selected timeframes and lookback periods.”

Please make the Settings and Source Code buttons in an indicator’s title bar work as toggles, similar to the existing Hide button.

Currently, the Hide button in the indicator title bar can be clicked repeatedly to turn the indicator visibility on and off. In contrast, the Settings and Source Code buttons only open the respective dialog or panel, but do not close it again when the same button is clicked a second time.

This is especially relevant during active chart work, when you quickly want to check or adjust something in the settings or source code and then immediately return to the chart. If the same button that opens a dialog or panel could also close it again, the workflow would feel more natural and require less mouse movement or less searching for a separate close action.

Please allow Pine scripts to provide only the calculated data, while the user can choose the desired chart type at the UI level in TradingView's indicator renderer, e.g., at the indicator's title line.

Currently, every selectable visualization type must be explicitly implemented in the Pine script. If the same series should be available as a table, line, histogram, columns, or area plot, the author needs additional inputs, multiple plot() calls, and visibility logic.

A renderer-level chart type selector, limited to representations compatible with the structure of the provided data and respecting scale and pane semantics, would reduce Pine boilerplate and give users more flexibility without requiring every selectable visualization type to be programmed in the script.

The set of offered types would depend on the data shape:

• Tabular or categorical data (category–value pairs without a bar index, e.g. from table output or computed aggregates) additionally supports types such as bar, pie, donut, radar, treemap, or box-and-whisker. In each case the renderer would offer only the chart types that are meaningful for that data structure.
• A time-indexed series (one value per bar) maps naturally to line, stepline, area, baseline, columns, or histogram. TradingView already uses a similar principle on the main chart, where the same OHLC data can be rendered through the UI as candles, bars, line, area, baseline, Heikin Ashi, and other chart types.

Comparable UI-driven switching mechanisms are also known from public charting libraries, such as Apache ECharts with magicType; they are mentioned here only as a conceptual analogy, not as a direct technical blueprint.

Please allow Pine Script table row and column headers to be clickable and expose corresponding click events (e.g., row/column index). This would enable developers to implement custom functionality such as column sorting, row selection, filtering, expanding/collapsing sections, and other interactive table behaviors directly within Pine-generated tables.

Related feature requests:
- Clickable Tabs for Pine Tables
- Custom Input Tabs

Please allow the Pine Editor to use local source files directly. AI coding agents such as Claude already support direct editing of local Pine Script files.

Allowing the Pine Editor to use local source files directly would enable seamless integration with modern AI-assisted development workflows and eliminate manual copy/paste between local files and the Pine Editor.

Related feature requests:

- Add "Select All" to the Pine Editor context menu

- Native GitHub Integration for Pine Script

- AI Integration into Pine Editor (Closed Feedback Loop)

- AI panel directly inside the Pine Editor next to the script

Please add a hovergroup parameter for Pine drawing objects, similar to group in input.*() statements.

Objects with the same hovergroup value should be highlighted together when any one of them is hovered. This would make it much easier to recognize which plots, hlines, labels, lines, boxes, tables, or cells belong to the same topic or category.

In essence, this would be the hover equivalent of the group selection highlighting commonly found in CAD, graphics and IDE applications.