TradingView MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes focused on different technical analysis patterns (candle patterns, Bollinger Bands, volume analysis, gainers/losers), but some overlap exists between 'smart_volume_scanner' and 'volume_breakout_scanner' as both combine volume and price analysis. The descriptions clarify differences, but an agent might need to carefully choose between them.
Naming Consistency4/5
Tool names consistently use snake_case and descriptive verb_noun patterns (e.g., 'advanced_candle_pattern', 'bollinger_scan'), with minor deviations like 'coin_analysis' (noun_noun) and 'rating_filter' (noun_verb). The naming is highly readable and follows a clear convention throughout.
Tool Count5/5
With 10 tools, the count is well-scoped for a TradingView server covering various technical analysis scans and detailed analyses. Each tool serves a specific purpose in market scanning and coin evaluation, making the set comprehensive without being overwhelming.
Completeness4/5
The toolset provides strong coverage for scanning and analyzing cryptocurrency markets, including pattern detection, volume analysis, and rating filters. A minor gap is the lack of tools for managing alerts or backtesting strategies, but core analysis workflows are well-supported.
Average 3.1/5 across 10 of 10 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'detailed analysis' but doesn't specify what the analysis returns, whether it's computationally intensive, if it requires specific data availability, or any rate limits. For a 3-parameter tool with no annotations, this leaves significant behavioral gaps.
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 appropriately concise with a clear purpose statement followed by parameter explanations. The Args section is well-structured and front-loaded. Every sentence serves a purpose, though the parameter explanations could be slightly more informative.
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?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis returns, what 'volume confirmation' means in practice, or provide enough context about parameter constraints. For a financial analysis tool with multiple siblings, this leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It provides basic parameter explanations in the Args section (e.g., 'Coin symbol (e.g., BTCUSDT)'), which adds some semantic meaning beyond the schema's bare titles. However, it doesn't explain valid values for 'exchange' or 'timeframe' beyond examples, leaving important parameter details undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Detailed volume confirmation analysis for a specific coin' which provides a clear purpose (analyzing volume confirmation for a coin) but is somewhat vague about what 'volume confirmation analysis' entails. It distinguishes from siblings like 'volume_breakout_scanner' and 'smart_volume_scanner' by focusing on confirmation rather than scanning, but doesn't explicitly contrast them.
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. The description doesn't mention when volume confirmation analysis is appropriate, what scenarios it addresses, or how it differs from sibling tools like 'coin_analysis' or 'volume_breakout_scanner'. The agent receives no usage context beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'analysis' and 'returns coins,' implying a read-only operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, data freshness, or error handling. For a financial analysis tool with zero annotation coverage, this is a significant gap in transparency.
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 appropriately sized and front-loaded, starting with the core purpose. The 'Args' and 'Returns' sections are structured clearly, though the 'Args' section could be more integrated. Every sentence contributes, with no redundant information, making it efficient overall.
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?
Given the complexity (financial pattern analysis with 5 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on output format (e.g., structure of returned coins), error cases, or performance considerations. For a tool with zero structured support, the description should provide more contextual depth to aid the agent.
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 0%, so the description must compensate. It lists all 5 parameters with brief explanations (e.g., 'Exchange name,' 'Base timeframe for analysis'), adding meaning beyond the schema's titles. However, it doesn't provide detailed semantics like valid enum values for 'exchange' or 'base_timeframe,' or clarify 'min_size_increase' as a percentage. The description adds value but doesn't fully bridge the coverage gap.
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 clearly states the tool performs 'advanced candle pattern analysis using multi-timeframe data' and identifies it returns 'coins with progressive candle size increase patterns.' This specifies both the action (analysis) and resource (candle patterns/coins), though it doesn't explicitly differentiate from sibling tools like 'consecutive_candles_scan' or 'volume_breakout_scanner' which may have overlapping purposes.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'multi-timeframe data' and 'progressive candle size increase patterns,' but doesn't specify scenarios, prerequisites, or exclusions. Without comparison to siblings like 'bollinger_scan' or 'volume_confirmation_analysis,' the agent lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns data but does not describe output format, rate limits, authentication needs, or potential side effects. The mention of 'bollinger band analysis' adds some context, but key behavioral traits are missing.
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, efficient sentence that is front-loaded with the core purpose. There is no wasted text, making it highly concise and well-structured for quick understanding.
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 complexity (financial analysis with parameters), no annotations, and an output schema present, the description is minimally adequate. It states the purpose and method but lacks details on usage, parameters, and behavioral context, relying on the output schema for return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It mentions 'exchange and timeframe' but does not explain parameter meanings, valid values, or how they affect the analysis. The 'limit' parameter is not referenced at all, leaving three parameters inadequately documented.
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 clearly states the tool's purpose with a specific verb ('Return') and resource ('top losers'), and mentions the analytical method ('using bollinger band analysis'). However, it does not explicitly distinguish this tool from its sibling 'top_gainers' or other analysis tools like 'bollinger_scan', leaving some ambiguity in 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?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'bollinger band analysis' but does not specify scenarios, prerequisites, or exclusions, nor does it reference sibling tools like 'top_gainers' or 'bollinger_scan' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the analysis method ('bollinger band analysis') and a constraint ('max 50' for limit), but lacks critical details: it doesn't specify what 'top gainers' means (e.g., price percentage change?), whether this is a read-only operation, potential rate limits, or data freshness. For a financial analysis tool with no annotations, this is insufficient.
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 well-structured and appropriately sized. The first sentence states the purpose clearly, followed by a bullet-point-like 'Args' section that efficiently documents parameters. There's no redundant information, and the content is front-loaded with the core functionality.
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 complexity (financial analysis with 3 parameters), no annotations, but an output schema exists, the description is moderately complete. It covers the purpose and parameters adequately, but lacks behavioral context (e.g., how 'top gainers' is calculated, data sources). The output schema likely handles return values, so that gap is mitigated, but overall it's minimal for a tool with no annotations.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: it explains 'exchange' with examples (KUCOIN, BINANCE, BYBIT), 'timeframe' with allowed values (5m, 15m, etc.), and 'limit' with its max constraint (50). This goes beyond the schema's basic titles and defaults, providing practical context for all three parameters.
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 clearly states the tool's purpose: 'Return top gainers for an exchange and timeframe using bollinger band analysis.' It specifies the verb ('return'), resource ('top gainers'), and methodology ('bollinger band analysis'), which distinguishes it from generic analysis tools. However, it doesn't explicitly differentiate from sibling tools like 'top_losers' beyond the obvious gainers vs. losers distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'bollinger_scan' or 'volume_breakout_scanner', nor does it specify scenarios where this tool is preferred or excluded. The only contextual information is the parameter descriptions, which don't constitute usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what the tool does but lacks critical behavioral details: no information about rate limits, authentication requirements, data freshness, or what constitutes 'normal level' for volume. The description doesn't contradict annotations (none exist), but it's insufficient for a mutation/analysis tool.
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 appropriately sized and well-structured. The purpose is stated concisely in the first sentence, followed by a clearly formatted Args section. Every sentence earns its place, though the purpose statement could be slightly more specific about the detection mechanism.
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 5 parameters with 0% schema coverage and no annotations, the description does a decent job explaining parameters but lacks behavioral context. The existence of an output schema means the description doesn't need to explain return values, but for a financial analysis tool with siblings, more guidance about when to use it 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?
Schema description coverage is 0%, so the description must compensate. It provides clear explanations for all 5 parameters in the Args section, adding meaning beyond the bare schema. Each parameter gets a brief semantic explanation (e.g., 'How many times the volume should be above normal level' for volume_multiplier). The only gap is not explaining what 'normal level' means operationally.
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 clearly states the tool's purpose: detecting coins with both volume breakout and price breakout. It specifies the verb 'detect' and the resource 'coins' with specific conditions. However, it doesn't explicitly differentiate from sibling tools like 'smart_volume_scanner' or 'volume_confirmation_analysis', which appear related.
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 about when to use this tool versus alternatives. The description doesn't mention sibling tools or suggest scenarios where this scanner is preferable over others like 'smart_volume_scanner' or 'bollinger_scan'. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions scanning and filtering based on BBW threshold, but doesn't describe what the scan returns (e.g., list of coins, data format), potential rate limits, authentication needs, or whether it's a read-only operation. For a tool with no annotation coverage, this is a significant gap in transparency.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clear 'Args:' section listing parameters with brief explanations. Every sentence earns its place without redundancy, making it efficient and easy to parse.
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 complexity (technical analysis scan with 4 parameters), no annotations, and an output schema (which reduces need to describe return values), the description is moderately complete. It covers parameter semantics well but lacks behavioral context and usage guidelines. This is adequate as a minimum viable description but has clear gaps.
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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'exchange' accepts names like KUCOIN, BINANCE, BYBIT; 'timeframe' includes specific intervals (5m to 1M); 'bbw_threshold' is a maximum value for filtering; and 'limit' caps rows returned. This compensates well for the schema's lack of descriptions, though it doesn't detail parameter interactions or validation rules.
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 clearly states the tool's purpose: 'Scan for coins with low Bollinger Band Width (squeeze detection).' It specifies the verb ('scan'), resource ('coins'), and technical indicator ('Bollinger Band Width'), making the intent understandable. However, it doesn't explicitly differentiate this squeeze detection tool from sibling tools like 'advanced_candle_pattern' or 'volume_breakout_scanner', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this scan is preferred over other analysis tools (e.g., 'coin_analysis' or 'rating_filter'), nor does it specify prerequisites or exclusions. This leaves the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool returns ('Detailed coin analysis with all indicators and metrics') but provides no information about rate limits, authentication requirements, data freshness, error conditions, or whether this is a read-only operation versus one that might trigger computations.
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 efficiently structured with a clear purpose statement followed by organized Args and Returns sections. Every sentence earns its place: the first establishes the core function, while the parameter and return explanations provide essential context without redundancy. The formatting with clear section headers enhances readability.
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?
For a 3-parameter tool with no annotations and no output schema, the description provides adequate basic information about what the tool does and what parameters it accepts. However, it lacks important contextual details about the analysis methodology, what 'all indicators and metrics' includes, whether there are limitations on historical data, or how this differs from the sibling tools.
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?
With 0% schema description coverage, the description compensates well by explaining all three parameters in the Args section. It provides concrete examples for 'symbol' (ACEUSDT, BTCUSDT), lists possible exchanges, and enumerates timeframe options. This adds significant value beyond the bare schema, though it doesn't specify whether exchange names are case-sensitive or if additional timeframes might be supported.
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 clearly states the tool's purpose with a specific verb ('Get detailed analysis') and resource ('for a specific coin'), making it immediately understandable. However, it doesn't explicitly differentiate this coin analysis tool from its siblings like 'rating_filter' or 'volume_confirmation_analysis', which might also provide coin-related insights.
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?
The description provides no guidance on when to use this tool versus the nine sibling tools listed. It mentions the required parameters but gives no context about when this analysis is appropriate compared to alternatives like 'top_gainers' or 'bollinger_scan', leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the scanning function but lacks details on performance (e.g., rate limits, latency), data freshness, error handling, or authentication needs. The return format is mentioned but not elaborated, leaving gaps in understanding how results are structured or limited.
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 appropriately sized and front-loaded, starting with the core purpose followed by a structured list of args and returns. Every sentence adds value, with no redundant information, though it could be slightly more concise by integrating the purpose with the parameter explanations.
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 complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and parameters well but lacks behavioral context (e.g., performance, errors) and detailed output explanation. Without an output schema, the brief return statement ('List of coins with consecutive candle patterns') is insufficient for full understanding, leaving gaps in how results are formatted or what data they include.
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?
Schema description coverage is 0%, so the description must compensate. It effectively adds meaning by explaining each parameter's purpose (e.g., 'pattern_type: "bullish" (growing candles) or "bearish" (shrinking candles)'), including constraints like 'candle_count: Number of consecutive candles to check (2-5)' and clarifying units like 'min_growth: Minimum growth percentage for each candle'. This provides essential context beyond the bare schema.
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 with specific verbs ('scan for coins') and resources ('consecutive growing/shrinking candles pattern'), distinguishing it from siblings like 'bollinger_scan' or 'volume_breakout_scanner' by focusing on consecutive candle patterns rather than technical indicators or volume analysis.
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 explicit guidance on when to use this tool versus alternatives is provided. While the purpose implies it's for identifying coins with specific candle patterns, there's no mention of when it's preferable over siblings like 'advanced_candle_pattern' or 'coin_analysis', nor any prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the rating scale and limit constraint ('max 50'), which adds some context. However, it lacks details on permissions, rate limits, error handling, or what the output contains (though an output schema exists). The description provides minimal behavioral insight beyond basic parameter info.
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 appropriately sized and front-loaded with the purpose, followed by a structured parameter list. Each sentence earns its place by clarifying parameters, though it could be more concise by integrating the purpose with parameter details. No wasted text, but minor room for optimization.
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?
Given 4 parameters with 0% schema coverage and an output schema present, the description does well by fully explaining parameters and their semantics. It covers the tool's core functionality adequately. However, it lacks context on when to use it versus siblings, and behavioral details are minimal, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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. It adds significant meaning beyond the schema by explaining each parameter: exchange examples, timeframe options, rating scale with interpretations, and limit constraint. This fully documents all 4 parameters, making it highly valuable for understanding inputs.
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 clearly states the tool's purpose: 'Filter coins by Bollinger Band rating.' It specifies the verb ('filter') and resource ('coins'), though it doesn't explicitly differentiate from siblings like 'bollinger_scan' or 'coin_analysis' which might have overlapping functionality. The purpose is specific but lacks sibling comparison.
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. The description lists parameters but doesn't explain scenarios or prerequisites for filtering by Bollinger Band rating, nor does it mention sibling tools like 'bollinger_scan' for comparison. Usage is implied only through the parameter details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a 'scanner,' implying a read-only operation that returns filtered results, but doesn't specify whether it requires authentication, has rate limits, returns real-time or historical data, or what happens with invalid inputs. The description adds minimal behavioral context beyond the basic function.
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 appropriately sized and front-loaded, starting with a high-level purpose followed by detailed parameter explanations in a structured 'Args:' section. Every sentence earns its place by clarifying the tool's function or parameters. It could be slightly more concise by integrating defaults into the parameter descriptions more seamlessly, but overall it's efficient.
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?
Given the complexity (5 parameters, 0% schema coverage, no annotations, but with an output schema), the description is reasonably complete. It fully documents all input parameters, which compensates for the lack of schema descriptions. Since an output schema exists, the description doesn't need to explain return values. However, it lacks behavioral context (e.g., error handling, data sources), which is a minor gap for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate by explaining all parameters. It successfully documents all 5 parameters with clear semantics: 'exchange' (exchange name), 'min_volume_ratio' (minimum volume multiplier with default), 'min_price_change' (minimum price change percentage with default), 'rsi_range' (oversold/overbought/neutral/any categories), and 'limit' (number of results with max). This adds significant value beyond the bare schema.
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 clearly states the tool's purpose as a 'smart volume + technical analysis combination scanner,' which indicates it scans for trading opportunities using volume and RSI metrics. However, it doesn't explicitly differentiate itself from sibling tools like 'volume_breakout_scanner' or 'volume_confirmation_analysis,' which likely have overlapping functionality. The verb 'scanner' is specific, but the exact resource (e.g., stocks, cryptocurrencies) is implied rather than stated.
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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling scanning tools available (e.g., 'volume_breakout_scanner,' 'bollinger_scan'), there's no indication of what scenarios favor this tool, what prerequisites exist, or when other tools might be more appropriate. Usage is implied through parameter descriptions but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tradingview-mcp MCP server](https://glama.ai/mcp/servers/patch-ridermg48/tradingview-mcp/badges/card.svg)](https://glama.ai/mcp/servers/patch-ridermg48/tradingview-mcp)

Score Badge

Copy to your README.md:

[![tradingview-mcp MCP server](https://glama.ai/mcp/servers/patch-ridermg48/tradingview-mcp/badges/score.svg)](https://glama.ai/mcp/servers/patch-ridermg48/tradingview-mcp)

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/patch-ridermg48/tradingview-mcp'

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