Loading ToolBench
MCP server to search TradingView indicators and strategies and fetch their Pine Script source. Works with Claude Code, Claude Desktop and Cursor. No API key required.
Strong tool definitions with excellent naming, comprehensive parameter schemas, and detailed descriptions. All 7 tools follow verb_noun naming convention (search_, list_, get_, harvest_, query_, fetch_). Descriptions are substantive (100-400 chars) and explain WHEN and WHY to use each tool. Input schemas are fully declared with types, enums, and constraints. Output documentation is implicit but inferable from code. Main gaps: (1) output schemas not formally documented in tool definitions, (2) no tool annotations (readOnlyHint present via Risk metadata but not MCP-native), (3) error handling strategies not pre-documented in descriptions. Response-size discipline is evident (snippets vs full sources, pagination support). Tool composition is sound: search_scripts → get_script_source → harvest_scripts → query_corpus forms a natural progression.
Show rate-limit health and corpus size: requests used against the daily budget, whether the circuit breaker has tripped, current pacing settings, and how many scripts and sources are stored locally. Makes no network request.
Fetch the full Pine Script source for one script, ready to backtest or port. Pass `script_id_part` from any search result (form "PUB;<hash>"), or paste a TradingView `chart_url` and it will be resolved. Sources are cached permanently per version, so repeat calls cost no request. Closed-source scripts return a clear error rather than junk.
Bulk-collect many scripts AND their Pine sources into the local corpus in one go, for example "100 trend-following strategies". This is the efficient way to build a backtesting library: pay the network cost once here, then use query_corpus offline. Runs within a wall-clock budget and checkpoints as it goes; if it returns status="paused" that is normal, just call again with the same harvest_id to continue. Returns counts and a small preview, never the source bodies.
List every public script published by one TradingView author, for example "TraderlifestyleYT", "LuxAlgo", "ZenAndTheArtOfTrading". Use this when you have a favourite author and want their catalogue. Optionally narrow with `query`.
Output schemas not formally documented in tool definitions. Descriptions reference 'items', 'source_chars', 'from_cache' etc., but no JSON Schema output specs are visible in tool registration. LLM must infer response structure from description text rather than machine-readable schema.
Tool annotations missing. All tools are READ_ONLY (no mutations), but MCP schema lacks readOnlyHint in tool definitions. This forces clients to infer safety from description text. Risk metadata in comments is not machine-parseable by MCP clients.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
TradingView's editors' picks: the hand-curated, highest-quality community scripts. Best starting point when you want proven, well-built indicators rather than a broad sweep.
Search everything already collected locally. Zero network requests, instant, and it can search INSIDE Pine source code, which the TradingView site cannot do. Use `source_contains` for literal code tokens such as "ta.supertrend" or "strategy.entry", and `query` for full-text over names, authors and descriptions. Always try this before hitting the network again.
Search TradingView for public indicators and strategies by topic, for example "trend following", "scalping", "order blocks", "mean reversion", "volume profile". Topic search is curated by TradingView and gives far better results than free-text keyword matching. Omit `query` to get the top/trending feed. Only open-source scripts are returned, so everything listed can have its Pine code fetched with get_script_source. Returns description snippets, not full descriptions.
Error handling guidance not pre-documented in descriptions. Description for get_script_source mentions 'Closed-source scripts return a clear error' but does not specify what error message LLM should expect or how to recover (e.g., 'try a different script'). Similarly, harvest_scripts status='paused' behavior is mentioned but recovery procedure is implicit in description rather than explicit error recovery guide.
fetch_status naming is ambiguous. Tool name does not start with a clear verb. 'fetch_status' could mean 'fetch (download) the status' or 'get the status of a fetch operation'. More precise name: 'get_fetch_status' or 'get_rate_limit_status'. Current name requires LLM to read description to disambiguate.
harvest_scripts parameter `query` is optional but behavior differs by `source`. When source='author', `query` is a filter; when source='search', empty query harvests trending feed (allowed per description). This conditional dependency is documented in prose but not formalized in parameter relationships or enum constraints. LLM may not recognize that source='author' + no query is invalid.