tradingview-mcp-server

Server Quality Checklist

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

Latest release: v0.7.1
Disambiguation4/5
Most tools are distinct by asset class and action (e.g., screen_stocks, screen_forex, screen_crypto, screen_etf). However, list_fields and get_market_metainfo both expose available fields, and lookup_symbols vs search_symbols overlap in symbol-finding, which may cause misselection without careful reading.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (screen_*, list_*, get_*, lookup_*, search_*, rank_*). The naming is predictable and uniform across the entire set.
Tool Count5/5
With 12 tools, the server is well-scoped for a TradingView screener and TA analysis service. Each tool addresses a clear need, and the count feels appropriate without being bloated or thin.
Completeness4/5
The surface covers core workflows: screening across asset classes, preset discovery, field/metadata exploration, symbol lookup, and TA ranking. Minor gaps exist such as no create/update/delete for custom presets or a unified screening tool across all asset types, but these are not critical for the main purpose.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 5 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description's 'Returns forex pairs' aligns with a read-only operation. The description adds minimal behavioral context beyond the annotations, such as the fact that it filters based on criteria, but does not disclose any edge cases like default limits or sorting behavior. No contradiction.
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 extremely concise at two sentences with no filler. It is front-loaded with the primary action and result. However, its brevity comes at the cost of missing usage context, so it earns a 4 rather than 5.
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?
This is a complex screening tool with a rich filter schema, multiple operators, and examples in the schema. The description provides only a high-level one-liner and does not orient the agent to the available filter fields, operators, or general workflow. Despite the output schema and annotations, the description is not sufficient for a tool of this complexity.
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%, with detailed parameter descriptions for limit, columns, filters, sort_by, and sort_order. The description adds no extra parameter semantics, but the schema carries the full burden. Baseline 3 is appropriate as the schema is self-explanatory.
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 identifies the tool as a screener for forex pairs using technical criteria. The verb 'screen' and the resource 'forex pairs' make the purpose unambiguous, and it differentiates from sibling tools that screen other asset classes. However, 'technical criteria' is generic and could be more specific about the indicators involved.
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?
The description implies the tool is used for screening forex pairs, but it does not explicitly state when to use this tool versus alternatives like screen_stocks or screen_crypto. No exclusions or comparison to siblings are provided, leaving the agent to infer the asset class from the name 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not add meaningful behavioral context beyond restating that it screens and returns results. It provides no additional details about default limits, result structure, rate limits, or any side effects, which would have added value on top of the annotations.
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, front-loaded sentence that immediately communicates the tool's purpose and primary output. Every word earns its place; there is no fluff or redundancy.
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 a rich input schema with examples and a dedicated output schema, the description need not explain mechanics. It correctly identifies the tool's domain and filter-based behavior, which is sufficient context for an agent to select the tool. The only minor gap is the lack of explicit guidance on sorting or default columns, but these are covered in the schema.
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%, so the schema fully documents parameters like filters, limit, columns, sort_by, and sort_order. The description mentions 'specified filters' but adds no parameter-specific meaning, which matches the baseline of 3 for high schema coverage.
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 ('Screen') with an explicit resource ('cryptocurrencies') and scope ('technical and market criteria'). It also states the outcome ('Returns cryptocurrencies matching the specified filters'), clearly distinguishing it from sibling tools like screen_stocks and screen_forex by asset class.
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?
The description clearly implies this tool is for screening cryptocurrency assets, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. It lacks any mention of sibling tools such as screen_stocks or rank_by_ta, so guidance on when-not-to-use is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, non-mutating behavior is covered. The description adds that this tool 'Discovers exact symbol identifiers' and searches by name/ticker/description, but doesn't elaborate on output shape, rate limits, or search behavior beyond that. This is adequate baseline transparency given the annotations, but not exhaustive.
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 three short, front-loaded sentences. The first states the primary action, the second mentions result types, and the third gives usage context. No wasted words exist, though the second sentence is slightly redundant with the asset_type enum. Overall, it's concise and readable.
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?
The description covers the essential use case, references asset types, and tells the user to use it before screening. With an output schema available, the absence of a return-value description is acceptable. The only gap is the failure to differentiate from the similarly named sibling 'lookup_symbols', leaving some ambiguity for an AI agent in edge cases.
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 coverage is 100% and all parameters already have descriptions in the input schema (query, limit, start, exchange, asset_type). The tool description reinforces the concept of searching by name/ticker/description, but adds no new parameter semantics. Thus it meets the baseline for schema-heavy behavior but doesn't go beyond it.
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 a specific verb and resource: 'Search for TradingView symbols by name, ticker, or description.' It also frames the purpose relative to screening ('Use this before screening'), which distinguishes it from screen_* siblings. However, it does not differentiate it from the closely named sibling 'lookup_symbols', so it doesn't fully meet the strict 5 criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use this tool: 'Use this before screening when you need to find the correct symbol format.' This clearly signals a discovery/disambiguation role before other operations. It does not explicitly mention alternatives like lookup_symbols, so it lacks the when-not/alternative clarity of a top-tier guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds the detail that metadata includes field names and types, which is more about content than behavior. No additional behavioral traits like rate limits or auth are disclosed, but the annotation coverage lowers the bar.
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 two sentences, front-loaded with the primary purpose and followed by a practical use case. Every word earns its place with no redundancy or fluff.
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?
With a full output schema and annotations covering safety and idempotency, the description is sufficiently complete for an agent to select and invoke the tool. It adds useful context about how the metadata relates to screening queries, which is not in the schema.
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%, so each parameter is well-documented in the schema. The description doesn't add meaningful parameter-level detail beyond the schema, so the baseline 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 clearly states the tool gets metadata about a TradingView market screener, including available fields and types. It distinguishes from siblings by specifying 'market screener' context, though it doesn't explicitly contrast with similar tools like list_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage scenario: 'Useful for discovering what fields can be used in screening queries.' This gives context for when to use it, but doesn't explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent behavior, and the description adds useful context by specifying the return content (labels, scores, oscillator/MA basis) and the multi-symbol/multi-timeframe scope. It does not contradict the annotations.
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?
Two concise, front-loaded sentences with no redundant or promotional language. Every clause adds information about scope, return format, or the basis of the scores.
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 rich input schema, output schema, and read-only/idempotent annotations, the description is largely complete for a summary API. It omits explicit guidance on when to choose this over rank_by_ta or screen_stocks, but that is more of a usage-guideline gap than a completeness gap.
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 already documents all three parameters with defaults, valid values, and maximum symbol count, so the description adds minimal parameter-level detail. Mention of oscillators and moving averages links loosely to include_components but does not exceed the schema's coverage.
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 returns TradingView-style buy/sell/neutral labels and recommendation scores for one or more symbols across multiple timeframes. It is specific about the resource and output, though it does not explicitly contrast itself with sibling tools like rank_by_ta.
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?
Usage context is implied: use when you need a technical analysis summary for specified symbols. There is no explicit when-to-use statement, exclusions, or guidance on when to prefer this over alternatives like rank_by_ta or screen_stocks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds minimal behavioral context beyond purpose—it does not mention default behavior when no filters are provided, pagination, or rate limits. No contradiction with annotations exists.
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 two sentences, front-loaded with the core action, and contains no filler or redundant information. Every word contributes to understanding the tool's purpose.
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 rich input schema, output schema, and annotations, the description is sufficient as a high-level summary. It could mention default behavior or explicit alternatives, but the structured data carries the necessary detail for a complex screening tool.
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%, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the input schema already provides. The schema itself richly documents filters, operators, markets, sorting, and limits.
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 function with a specific verb ('Screen'), a specific resource ('stocks'), and the criteria type ('fundamental and technical criteria'). It also states the outcome ('Returns stocks matching the specified filters'), and the resource 'stocks' distinguishes it from sibling tools like screen_forex, screen_crypto, and screen_etf.
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?
The description implies usage for stock screening but does not explicitly state when to use this tool versus alternatives such as screen_etf or screen_forex. There are no exclusions, prerequisites, or alternative tool mentions, so guidance is only implicit through the word 'stocks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds modest value by explaining the weighting/timeframe methodology, but does not disclose additional behavioral traits such as output ordering or limitations beyond what schemas/annotations provide.
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?
Two short, front-loaded sentences deliver the core action and purpose without filler. Every word earns its place, and the structure makes the tool's function immediately clear.
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 detailed input schema, annotations, and output schema, the description provides sufficient context for an agent to understand the tool's purpose and main usage. The only minor gap is a lack of direct differentiation from sibling screening tools, but this is not a serious omission.
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%, so the input schema already documents all three parameters. The description's mention of 'weighted' and 'across timeframes' reinforces the role of weights and timeframes, but it adds no parameter-specific detail beyond what the schema already 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?
Description uses a specific verb ('Rank') and clearly identifies the resource ('symbols') and the method ('weighted technical analysis scores across timeframes'). It also states the intended comparison use case ('strongest overall TA signals'), which helps distinguish it from sibling screening/lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: useful for comparing which symbols have the strongest overall TA signals. It does not explicitly name alternative tools or exclusions, but the stated use case makes it reasonably clear when to use this ranking tool versus the sibling screen/lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety expectations. The description adds only that the tool returns ETFs matching filters, which is basic behavior. No additional behavioral traits (e.g., pagination, rate limits, data ties) are disclosed, but with this tool's simple read-only nature, a 3 is appropriate.
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 two concise sentences that immediately state the tool's purpose and return behavior. No filler or redundant details; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only screening tool with a fully documented input schema and an output schema present, the description is complete enough. It conveys the core purpose and result, while the schema covers parameter details and the output schema covers return structure.
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%, so the input schema already documents all parameter meanings and valid values. The description's phrase 'performance and technical criteria' provides a high-level hint but doesn't add details beyond the schema, so the baseline 3 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 clearly states the tool screens ETFs based on performance and technical criteria and returns matching ETFs. The verb 'Screen' and specific resource 'ETFs' make its purpose unambiguous, and it is naturally distinguished from sibling tools like screen_stocks and screen_forex by the asset class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly identifies the context: use when screening ETFs. No explicit when-not or alternative tool references are given, but the ETF-specific scope makes usage obvious. It lacks direct mentions of when to prefer other screen_* tools, so it doesn't reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds that fields are intended for filtering and display, which is useful context, but it does not add much beyond that. No contradiction with annotations.
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?
Two concise sentences with no filler. The purpose and usage are front-loaded, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema with full descriptions, an output schema, and safe annotations, the description fully covers what an agent needs to understand and invoke the tool correctly.
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% with both parameters fully documented via descriptions and enums. The tool description adds no additional semantics beyond what the schema provides, so baseline 3 is appropriate.
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 lists available fields for filtering and display, distinguishing it from sibling screening and lookup tools. The verb 'List' and resource 'fields' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this to discover filterable/sortable fields, providing clear when-to-use context. However, it does not mention when not to use or name alternative tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, so the description does not need to reaffirm safety. It adds no behavioral detail beyond what is in the annotations (e.g., pagination or sorting), but the tool is simple and non-destructive, so this is acceptable.
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 two concise sentences, front-loaded with the purpose. Every sentence adds value: the first defines the operation, the second explains the return and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters)Skip the description fully explains what is returned and how to consume the results. The presence of an output schema covers return details, and the description means the tool is complete for its simple purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, and the schema has none. The description effectively covers the only relevant aspect—what the list contains and how to use the entries. The baseline for 0 params is 4, and the description meets that.
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 'List all available preset screening strategies' and specifies what each entry contains (key, name, description). It differentiates from siblings by mentioning the presets and how to use them with get_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to use the returned key with get_preset, providing a clear follow-up action. It does not explicitly exclude other contexts, but the guidance is sufficient for a simple enumeration tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description does not contradict these. It adds useful context by enumerating preset meanings and by drawing the boundary for market_indexes ('use lookup_symbols'), while clearly stating the tool returns filter configuration rather than executing a screen. This is more than a bare repeat of the annotations, though no deeper side-effect/rate-limit/auth notes are provided.
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 front-loaded with a one-sentence purpose, followed by a scannable bullet list of presets. Each bullet is compact and directly functional—there is no fluff, redundant text, or padding. The length is justified by the need to enumerate the presets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with read-only annotations and an output schema, the description is fully sufficient. It provides the complete set of accepted preset keys, each with descriptive context, and even supplies a cross-reference for the market_indexes edge case. Nothing material is missing for correct invocation.
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 coverage is 100%, and the schema itself refers to the tool description for available preset keys. The description fully compensates by listing all valid preset_name values and explaining their screening focus, which makes parameter selection straightforward and unambiguous.
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 an explicit verb and resource: 'Get a pre-configured screening strategy' and further clarifies the return value ('Returns filter configuration'). The phrase 'pre-configured screening strategy' distinguishes it from screen execution tools like screen_stocks, and the preset list makes the exact scope of the tool obvious.
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?
Usage context is implied by the listing of available presets and by the note to 'use lookup_symbols' for market_indexes, but there is no explicit explanation of when to use get_preset versus alternatives such as list_presets. The description does not state exclusions or recommend a workflow like 'retrieve a preset, then apply it to screen_stocks.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is established. The description adds valuable behavioral context by stating it 'Returns comprehensive data including ATH, 52-week highs/lows,' which is useful for output expectations. No contradictions with annotations.
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?
Two sentences: first clearly states purpose, second provides usage guidance and return info. Front-loaded and concise, with zero redundant phrasing. Every sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters (fully described in schema), an output schema, and strong annotations, the description covers purpose, usage, and return data. It also addresses the indexing edge case, providing enough context for an agent to decide appropriately. Complete for its scope.
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%, with both parameters (symbols and columns) fully described in the schema via descriptions. The description itself adds no parameter-level detail. Baseline of 3 is appropriate since the schema carries the burden.
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 action ('Look up specific symbols by ticker') and the resource (stocks, indexes, ETFs). It explicitly distinguishes from screening tools by noting it handles indexes not found via screening, providing context on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this for direct symbol lookup including market indexes... that cannot be found via screening.' This gives specific when-to-use context and implicitly contrasts with screening tools. Alternative search_symbols is not mentioned, but the direct lookup focus is clear.
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-server MCP server](https://glama.ai/mcp/servers/fiale-plus/tradingview-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/fiale-plus/tradingview-mcp-server)

Score Badge

Copy to your README.md:

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

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/fiale-plus/tradingview-mcp-server'

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