Provides access to Binance public market data (crypto spot) for quotes, OHLCV, and symbol search.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tradinview-mcp search for AAPL symbol"
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.
Provider-based TradingView-style market research and charting MCP server.
This project does not scrape TradingView, does not use undocumented TradingView APIs, and does not execute trades. It exposes MCP tools for market-data research, indicator calculation, watchlists, and local chart HTML rendering.
pnpm install
cp .env.example .env
pnpm devThe default provider is mock, so the server works without API keys.
For the ChatGPT/Vercel-style remote endpoint locally:
pnpm dev:httpEndpoint:
http://localhost:3000/api/mcpRelated MCP server: TradingView MCP Server
mock is the safe offline default. To use real public crypto market data, enable Binance:
ENABLE_BINANCE=true
DEFAULT_PROVIDER=binance
BINANCE_BASE_URL=https://data-api.binance.visionTo make sure the server never starts accidentally with mock data:
REQUIRE_REAL_PROVIDER=trueThen run:
pnpm devUse the verify_provider MCP tool with:
{ "provider": "binance", "symbol": "BTCUSDT", "interval": "1h" }That tool performs real quote and OHLCV calls and returns realProvider: true when the selected provider is not mock.
After building:
pnpm buildAdd a stdio MCP server entry similar to:
{
"mcpServers": {
"tradinview-mcp": {
"command": "node",
"args": ["C:/Users/mobol/Downloads/tradinview-mcp/dist/index.js"],
"env": {
"DEFAULT_PROVIDER": "mock"
}
}
}
}Deploy the remote MCP endpoint:
npx vercel --prodSet Vercel env vars for real Binance data:
ENABLE_BINANCE=true
DEFAULT_PROVIDER=binance
REQUIRE_REAL_PROVIDER=true
BINANCE_BASE_URL=https://data-api.binance.vision
WATCHLIST_PATH=/tmp/watchlist.jsonThen connect ChatGPT Developer Mode to:
https://your-project.vercel.app/api/mcpSee Setup for the full ChatGPT connection flow.
For development, use:
{
"mcpServers": {
"tradinview-mcp": {
"command": "pnpm",
"args": ["dev"],
"cwd": "C:/Users/mobol/Downloads/tradinview-mcp"
}
}
}search_symbols: search configured providers.
get_quote: get latest normalized quote.
get_ohlcv: get OHLCV bars.
calculate_indicators: calculate SMA, EMA, RSI, MACD, and Bollinger Bands.
render_chart_html: render safe local Lightweight Charts HTML from supplied bars.
get_watchlist: read local watchlist.
add_to_watchlist: add or update a watchlist symbol.
remove_from_watchlist: remove a watchlist symbol.
verify_provider: perform a provider quote/OHLCV smoke check.
Example tool inputs:
{ "query": "BTC", "provider": "mock" }{ "symbol": "BTCUSDT", "interval": "1h", "limit": 100, "provider": "mock" }{
"bars": [
{ "time": "2026-06-23T00:00:00.000Z", "open": 100, "high": 105, "low": 99, "close": 103, "volume": 1000 }
],
"indicators": [{ "type": "SMA", "period": 20 }]
}market://schema
market://provider-status
market://compliance-notes
analyse_symbol
compare_assets
build_watchlist
Binance is disabled unless configured:
ENABLE_BINANCE=true
DEFAULT_PROVIDER=binanceOnly public crypto spot market data endpoints are used. The default Binance URL is https://data-api.binance.vision, Binance's market-data-only base endpoint.
pnpm typecheck
pnpm test
pnpm buildRun the live provider smoke test only when you want an internet-backed check:
pnpm test:liveMore details:
Add or update a symbol in the saved local watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It mentions 'add or update' implying upsert behavior, but does not detail what happens when a symbol already exists, any side effects, or persistence guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks necessary detail to be fully effective. It is efficient but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters and no output schema, the description is still incomplete. It does not explain the return value, error handling, or how the watchlist is persisted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameters. The description only names 'symbol' and 'note' implicitly, without explaining their formats, the purpose of 'note', or the constraint on 'symbol' (minLength 1).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add or update' and the resource 'symbol in saved local watchlist'. It distinguishes from sibling tools like get_watchlist (read) and remove_from_watchlist (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as when to add vs update, or when to use remove_from_watchlist. The description lacks context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate SMA, EMA, RSI, MACD, and Bollinger Bands from OHLCV bars.
| Name | Required | Description | Default |
|---|---|---|---|
| bars | Yes | ||
| indicators | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as 'calculate' but does not disclose potential side effects, data requirements (e.g., minimum number of bars per indicator), or that the operation is read-only with no destructive behavior. The 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 12-word sentence that efficiently conveys the core purpose without extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple indicator types, parameter dependencies), the description is incomplete. It lacks information about output format, required bar count per indicator, and any performance considerations. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters have no descriptions in the schema. The tool description adds no parameter-level detail, such as required order of bars, frequency, or format constraints. It only lists indicator types, which is already implied by the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates SMA, EMA, RSI, MACD, and Bollinger Bands from OHLCV bars. It uses a specific verb 'calculate' and lists the exact indicators, distinguishing it from sibling tools that fetch raw data or generate charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for computing technical indicators but does not explicitly state when to use this tool versus alternatives like get_ohlcv for raw data or render_chart_html for visualization. No guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get normalized historical OHLCV bars for a symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| interval | Yes | ||
| limit | No | ||
| provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'normalized' and 'historical', but lacks details on data source, rate limits, error handling, or the meaning of 'normalized'. This is insufficient for an agent to predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is so concise that it omits critical information, which slightly reduces the score from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required) and no output schema, the description is too brief. It does not explain return format, error scenarios, or parameter details. This leaves significant gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does not explain any parameter beyond the field names. For example, 'symbol' format, 'interval' units, 'limit' meaning, or 'provider' role are left ambiguous. No added value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns normalized historical OHLCV bars for a symbol. The verb 'Get' and resource 'OHLCV bars' are specific, and it distinguishes from sibling tools like get_quote (current price) and calculate_indicators (derived data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_quote for current data or search_symbols for symbol lookup. There is no mention of constraints, 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.
Get a normalized latest quote for a symbol from a configured provider.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions 'normalized' but fails to disclose side effects, error conditions, rate limits, or data freshness. For a read-like operation, more safety context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, efficient, no wasted words. Could be slightly more informative but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too sparse. The agent lacks information about return format, error handling, and how to interpret the 'normalized' quote.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It names 'symbol' and 'provider' but does not explain the provider parameter (optional, what values, what 'configured' means). Minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a 'normalized latest quote for a symbol from a configured provider.' It uses a specific verb ('Get') and resource ('quote'), and distinguishes itself from siblings like get_ohlcv (historical) and search_symbols (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_ohlcv for historical data). No prerequisites or when-not-to-use are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the saved local watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only implies a read operation via 'Read' and notes the watchlist is 'saved local', but lacks details about caching, staleness, or any side effects. Minimal disclosure beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is very brief. It tells that the tool reads a local watchlist but does not describe the format or properties of the returned data. For a simple read operation, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the input schema is empty. The description adds nothing beyond the schema, but the baseline for zero parameters is 4. No additional meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the saved local watchlist', using a specific verb and resource. It distinguishes from siblings like add_to_watchlist and remove_from_watchlist, which are write operations. However, it does not elaborate on what a watchlist contains or if multiple watchlists exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Siblings exist for adding/removing symbols, but the description does not explicitly say to use this for viewing and the others for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a symbol from the saved local watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does not indicate whether removal is permanent, reversible, or what happens if the symbol is not found. The statement 'Remove a symbol from the saved local watchlist' is too brief for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally viable but misses critical context like usage boundaries and behavioral implications. It is not complete for an agent to safely invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it merely repeats the parameter name 'symbol' in context, without specifying format, case sensitivity, or any validation hints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('a symbol from the saved local watchlist'). It effectively distinguishes the tool from its sibling 'add_to_watchlist'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it specify preconditions or limitations. It lacks explicit 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render safe local HTML using TradingView Lightweight Charts and caller-provided data.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| bars | Yes | ||
| indicators | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only says 'safe local HTML' without explaining side effects, permissions, or whether it is read-only. It does not disclose any limitations or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence) but lacks essential detail. It is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters including optional indicators) and lack of output schema, the description is severely incomplete. It fails to explain return values (e.g., rendered HTML) or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no property descriptions in schema) and the description does not mention any parameters. The agent must rely solely on names and schema types, which are insufficient for understanding data formats and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes the verb 'Render' and identifies the resource as 'safe local HTML using TradingView Lightweight Charts and caller-provided data'. The name and context clearly distinguish it from sibling tools (watchlists, quotes, searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or when not to use it. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search configured market data providers for matching symbols.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| market | No | ||
| provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as match type (prefix, fuzzy), case sensitivity, pagination, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but under-informative due to lack of detail; could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters and no output schema, the description should provide more context on matching behavior, parameter interactions, and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the meaning or usage of parameters like query, market, or provider beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for symbols across configured market data providers, distinguishing it from sibling tools that retrieve specific data like quotes or OHLCV.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose, but no explicit guidance on when to use this tool versus alternatives like get_quote or verify_provider, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a quote and OHLCV smoke check against a configured provider.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | ||
| symbol | No | BTCUSDT | |
| interval | No | 1h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions 'smoke check' but does not explain whether it modifies data, what it returns, or how failures are handled. Minimal behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is so brief that it sacrifices clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and three parameters with zero description coverage, the description is insufficient for an agent to reliably invoke the tool. Missing expected return format and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify parameter meaning beyond their names. For instance, 'provider' is not described, and 'symbol' default is mentioned in schema but not in description. Little added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a smoke check using quote and OHLCV data, distinguishing it from sibling tools like get_quote or get_ohlcv which merely fetch data. However, it could be more explicit about what a 'smoke check' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings such as get_quote or get_ohlcv. Missing context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_to_watchlistcalculate_indicatorsget_ohlcvget_quoteget_watchlistremove_from_watchlistrender_chart_htmlsearch_symbolsverify_providerScored across 9 tools
Each tool targets a distinct operation: watchlist management (add, remove, get), data retrieval (OHLCV, quote), calculations (indicators), search, verification, and rendering. No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., add_to_watchlist, get_quote, render_chart_html). Naming is predictable and uniform.
9 tools is well-scoped for a market data and watchlist server. Each tool serves a clear function without unnecessary bloat or missing essentials.
The surface covers watchlist CRUD core data retrieval, indicator calculations, search, and verification. Minor gaps exist (e.g., batch watchlist operations, advanced OHLCV filtering), but the main workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
Real-time market events, sentiment, and technical analysis as MCP tools, backed by real data.
Hosted MCP for stocks, options, Greeks, brokers, order previews, alerts, and workflows.
