What can you do with this server?

This server connects TradingView Desktop to AI assistants (like Codex) or CLIs via the Chrome DevTools Protocol, enabling programmatic control over chart functionalities: * Check connection/chart state: Verify the CDP connection is active and retrieve the current chart status. * Launch TradingView: Start TradingView Desktop with remote debugging enabled, with options for CDP port and killing existing processes. * Get chart details: Retrieve the current symbol, timeframe, chart type, and active indicators. * Change symbol: Switch the chart to a different trading symbol (e.g., AAPL, BTCUSD), with exchange-prefix support. * Adjust timeframe: Change the chart's timeframe (e.g., 1, 5, 15, 1D). * Modify chart type: Switch between types such as Candles, Line, or HeikinAshi. * Manage indicators: Add new indicators or remove existing ones from the chart. * Search symbols: Look up trading symbols by name or keyword. * Capture screenshots: Take screenshots of the chart or specific sections of the TradingView application.

Which integrations are available for this server?

Provides tools to control TradingView Desktop via Chrome DevTools Protocol, allowing symbol and timeframe changes, chart state queries, and launch management.

How do I use tradingview-mcp-codex?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tradingview-mcp-codex Set symbol to BTCUSD on 15-minute chart" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tradingview-mcp-codex

by gagahkharismanuary

Overview Schema Related Servers Score Discussions

JavaScript

Local

tradingview-mcp-codex

Connect Codex to your TradingView Desktop chart. Control symbols, timeframes, indicators, and screenshots via AI or CLI.

Not affiliated with TradingView Inc. Interacts only with your locally running TradingView Desktop app via Chrome DevTools Protocol.

Requires a valid TradingView subscription. Does not bypass any paywall or access control.

All processing is local. No chart data leaves your machine.

Prerequisites

Node.js 18+
TradingView Desktop installed (paid subscription)
Codex CLI with MCP support

Related MCP server: TradingView MCP Jackson

Install

git clone https://github.com/gagahkharismanuary/tradingview-mcp-codex.git
cd tradingview-mcp-codex
npm install

Step 1: Launch TradingView with debug port

TradingView must run with Chrome DevTools Protocol enabled on port 9222.

Mac (auto):

npm run launch

Mac (manual):

/Applications/TradingView.app/Contents/MacOS/TradingView --remote-debugging-port=9222

Windows:

"%LOCALAPPDATA%\TradingView\TradingView.exe" --remote-debugging-port=9222

Linux:

tradingview --remote-debugging-port=9222

Verify connection:

npm run health

Expected:

{
  "success": true,
  "cdp_connected": true,
  "chart_symbol": "BTCUSD"
}

Step 2: Register with Codex

codex mcp add tradingview-codex -- node /path/to/tradingview-mcp-codex/src/server.js

Replace /path/to/tradingview-mcp-codex with where you cloned. To find it:

pwd  # run inside the repo folder

Verify:

codex mcp list
codex mcp get tradingview-codex

Restart Codex after adding — tools load on session start.

Step 3: Verify in Codex

Ask Codex to call tvx_health_check. Expected:

{
  "success": true,
  "cdp_connected": true,
  "chart_symbol": "BTCUSD",
  "api_available": true
}

MCP Tools

Tool	What it does
`tvx_health_check`	Check CDP connection and chart status
`tvx_launch`	Launch TradingView Desktop with debug port
`tvx_chart_state`	Get symbol, timeframe, chart type, and indicator list
`tvx_set_symbol`	Change chart symbol
`tvx_set_timeframe`	Change chart timeframe
`tvx_set_chart_type`	Change chart type (Candles, Line, HeikinAshi, etc.)
`tvx_manage_indicator`	Add or remove an indicator
`tvx_symbol_search`	Search symbols by name or keyword
`tvx_screenshot`	Capture a screenshot of the chart

CLI

Install tvx globally (optional):

npm link

tvx status                                        # health check
tvx launch                                        # launch TradingView
tvx state                                         # get chart state
tvx symbol AAPL                                   # change symbol
tvx timeframe 15                                  # change timeframe (1, 5, 15, 60, D, W)
tvx charttype HeikinAshi                          # change chart type
tvx indicator add "Relative Strength Index"       # add indicator (full name required)
tvx indicator remove <entity_id>                  # entity_id from tvx state output
tvx search bitcoin                                # search symbols
tvx screenshot chart                              # capture chart (full, chart, strategy_tester)

Without npm link:

node src/cli/index.js symbol AAPL

Troubleshooting

Problem	Fix
`cdp_connected: false`	Launch TradingView with `--remote-debugging-port=9222`
`ECONNREFUSED`	TradingView not running or port 9222 blocked
Tools missing in Codex	Restart Codex after `codex mcp add`
`tvx` command not found	Run `npm link` inside the repo folder
Indicator add fails	Use full name: `"Relative Strength Index"` not `"RSI"`

One-liner Codex install prompt

Paste into Codex and it will handle the rest:

Clone https://github.com/gagahkharismanuary/tradingview-mcp-codex.git, run npm install, register with codex mcp add tradingview-codex -- node <path>/src/server.js, then verify with tvx_health_check.

Credits

Built on top of tradesdontlie/tradingview-mcp — a TradingView MCP server for Claude Code that connects AI agents to TradingView Desktop via Chrome DevTools Protocol. Core architecture, CDP connection patterns, chart API bindings, and tool designs are derived from that work. This project adapts and extends it for Codex workflows.

Available Tools

5 tools

tvx_chart_stateA

Get current chart symbol, timeframe, and type

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided; description states it's a read operation ('Get') but does not disclose any side effects, authentication requirements, or rate limits. Adequate but minimal for a simple getter.

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 concise sentence that efficiently communicates the tool's purpose without any unnecessary words or length.

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

Completeness3/5

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

Description does not specify the return format or structure of the output (e.g., object fields). Given no output schema, additional detail would improve completeness.

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?

No parameters exist in the schema, so description does not need to add meaning beyond schema; baseline 4 applies.

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 'Get' and lists the resources 'current chart symbol, timeframe, and type', clearly distinguishing it from sibling tools like tvx_set_symbol (sets) and tvx_set_timeframe (sets).

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives. However, being a read operation, it's implied for retrieving current state, but no exclusions or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tvx_health_checkB

Check TradingView CDP connection and current chart state

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'Check', implying read-only, but does not confirm safety, latency, side effects, or whether it modifies anything.

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?

Single short sentence. No waste. Front-loaded with key action and targets.

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?

Simple tool with no parameters and no output schema. Description covers both connection and chart state. Lacks specifics on return format or when to invoke, but adequate for a health check.

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?

No parameters defined. Schema coverage is 100% (vacuous). Description adds no parameter meaning, but baseline for 0 parameters is 4.

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

Purpose4/5

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

Clear verb 'Check' and specific resources ('TradingView CDP connection' and 'current chart state'). Distinguishes from sibling tvx_chart_state, which likely only handles chart state, but no explicit differentiation.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., tvx_chart_state for chart state alone). No mention of prerequisites or typical usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tvx_launchA

Launch TradingView Desktop with remote debugging enabled

ParametersJSON Schema

Name	Required	Description	Default
`port`	No	CDP port, default 9222
`killExisting`	No	Kill existing TradingView processes first

TDQS

A3.5/5.0

Behavior3/5

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

The description mentions 'remote debugging enabled' which hints at a behavioral trait, but it does not disclose what happens if TradingView is already running, permissions required, or the impact of killExisting. No annotations are provided, so the description partially carries the transparency burden. A score of 3 reflects basic transparency with room for improvement.

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?

The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient.

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

Completeness3/5

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

The tool is simple with two optional parameters and no output schema. The description is minimally adequate but does not address prerequisites (e.g., TradingView installation), failure behavior, or what the return value indicates. A score of 3 captures acceptable but not thorough completeness.

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

Parameters3/5

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds the context of 'remote debugging' but does not enhance understanding of individual parameters beyond what the schema provides.

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 clearly states the tool's purpose: 'Launch TradingView Desktop with remote debugging enabled'. It uses a specific verb ('Launch') and resource ('TradingView Desktop'), and the sibling tools handle different tasks (chart state, health check, symbol, timeframe), so it is well-distinguished.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., when remote debugging is needed, prerequisites, or scenarios where other tools are more appropriate). The description lacks context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tvx_set_symbolC

Set TradingView chart symbol

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Symbol or exchange-prefixed symbol

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It fails to disclose what 'set' entails (e.g., changes current chart symbol, requires open chart, persistence). Behavioral traits are minimally conveyed.

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

Conciseness4/5

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

The description is one short sentence with no wasted words. It front-loads the core function, though more detail could be added without sacrificing conciseness.

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

Completeness2/5

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

For a tool with no annotations and one parameter, the description is under-specified. It lacks information on prerequisites, side effects, or return values, leaving significant gaps in contextual understanding.

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

Parameters3/5

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

Schema description coverage is 100% for the single 'symbol' parameter. The description adds no extra meaning beyond the schema, which already describes the parameter format. Baseline score of 3 is appropriate.

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

Purpose4/5

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

The description 'Set TradingView chart symbol' clearly states the tool's action and resource. It distinguishes from sibling tools like tvx_chart_state (get state) and tvx_set_timeframe (set timeframe) by focusing on symbol setting.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Sibling tools exist but are not mentioned. The description does not specify prerequisites or context for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tvx_set_timeframeC

Set TradingView chart timeframe

ParametersJSON Schema

Name	Required	Description	Default
`timeframe`	Yes	Timeframe like 1, 5, 15, 1D

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present. The description only states the action without disclosing behavioral traits like side effects, required chart state, or data loading implications. For a mutation tool, this lack of transparency is a significant gap.

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

Conciseness4/5

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

The description is a single sentence with no waste. It is appropriately concise for a simple tool. However, it lacks structure (e.g., separate sections) and could include brief usage hints without compromising conciseness.

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

Completeness3/5

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

Given the tool's simplicity (one required parameter, no output schema), the description is minimally adequate. However, it omits behavioral context and usage guidelines that would help an agent use it correctly in dynamic scenarios.

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

Parameters3/5

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

The input schema has 100% coverage with a clear parameter 'timeframe' and example values ('1, 5, 15, 1D'). The description adds no extra meaning beyond the schema, so it meets the baseline of 3 without adding value.

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

Purpose4/5

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

The description 'Set TradingView chart timeframe' clearly states the verb (Set) and resource (TradingView chart timeframe). It is specific and easily understood. However, it does not differentiate from sibling tools like tvx_chart_state, which might also modify chart settings, leaving a minor ambiguity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as tvx_chart_state or tvx_set_symbol. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: launch, health check, get chart state, set symbol, set timeframe. No overlap or ambiguity.

Naming Consistency4/5

All tools use the 'tvx_' prefix, but the pattern varies: 'tvx_launch' is just a verb, while others combine verb+noun or are noun phrases. Still mostly predictable.

Tool Count5/5

Five tools is well-scoped for a TradingView chart control MCP server. Each tool serves a core function without redundancy.

Completeness4/5

Covers essential chart operations (launch, health check, get/set symbol and timeframe). Minor gaps like indicator manipulation or data retrieval, but core workflow is complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gainium-mcp
io.gainium
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Cryptocurrency Finance
22
openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
agentmailrooms-mcp
com.clauxel.agentmailrooms
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Agent Orchestration Autonomous Agents
2

Related MCP Servers

tradingview-mcp
Finance Autonomous Agents
harshil1502
A
license
A
quality
C
maintenance
A type-safe MCP server that enables AI agents to control TradingView Desktop via Chrome DevTools Protocol, allowing chart state reading, symbol/timeframe changes, and OHLCV data fetching.
Updated 4 months ago (2026-05-07 04:24 UTC)
11
552
1
MIT
TradingView MCP Jackson
Finance Developer Tools Browser Automation
nimit791
F
license
Not graded
quality
D
maintenance
An MCP server that connects to TradingView Desktop via Chrome DevTools Protocol, enabling chart control, Pine Script development, and a morning brief workflow with AI-driven analysis.
Updated 3 months ago (2026-06-08 06:16 UTC)
552
tradingview-mcp-thaqif
Finance Developer Tools AI & Machine Learning
TZ24cloud
A
license
Not graded
quality
A
maintenance
A local MCP server that connects TradingView Desktop to AI assistants via Chrome DevTools Protocol, enabling Pine Script development, multi-timeframe analysis, and Wyckoff scanning with a rules engine.
Updated 3 months ago (2026-06-04 21:20 UTC)
44
1
MIT
tradingview-mcp
Finance Browser Automation Developer Tools
lexasanych1984-ux
F
license
Not graded
quality
B
maintenance
MCP server that connects AI assistants to TradingView Desktop via Chrome DevTools Protocol, enabling chart analysis, Pine Script development, and workflow automation through natural language.
Updated a month ago (2026-08-03 18:50 UTC)
552

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gagahkharismanuary/tradingview-mcp-codex'

If you have feedback or need assistance with the MCP directory API, please join our Discord server