Skip to main content
Glama
Sign In
TradingView MCP

TradingView MCP

by madiver
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

pane_list

Lists all chart panes in the current layout, including their symbols and active state, so you can identify and target the right pane.

Instructions

List all chart panes in the current layout with their symbols and active state

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "pane_list"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations or output schema, the description carries the full behavioral burden. It communicates a read-only listing action and specifies the output content (panes with symbols and active state), which is sufficient for a simple, side-effect-free tool. It does not detail return formatting or ordering, but these are minor for this operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence states the action, object, scope, and included output fields. Every part is informative and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter listing tool, the description is nearly complete: it identifies the object type, scope, and returned attributes. It could marginally clarify the structure of 'active state' or how panes are ordered, but an agent can reasonably invoke the tool with the provided information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing for the description to explain beyond stating the operation's scope. The baseline for zero-parameter tools is 4, and the description appropriately adds no redundant parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') with a clear resource ('all chart panes in the current layout') and states what is included ('symbols and active state'). It is easily distinguishable from sibling tools like layout_list, pane_set_symbol, or chart_get_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly scopes usage to the current layout, which tells an agent when this pane-specific list is relevant. It does not explicitly mention alternatives like layout_list for listing layouts, but the context is sufficiently clear for choosing this tool over pane-related mutations.

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