TradingView MCP

by moeuu

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are grouped by domain (market, chart, tradingview) and each targets a distinct resource and action. Some overlap exists (e.g., market_get_price vs market_get_quote, chart_analyze vs tradingview_analyze_symbol) but the descriptions make them distinguishable, and the set is mostly well-separated.
Naming Consistency4/5
All tools follow a snake_case style with domain prefixes (market_, chart_, tradingview_). Most use verb_noun structure (e.g., get_quotes, add_indicator), with a few compound names (stock_snapshot, apply_overlays). Overall pattern is coherent and predictable.
Tool Count2/5
38 tools is too many for this server's scope. The chart_* toolkit alone includes many near-identical add/remove operations for each overlay type, which could be consolidated (e.g., a single overlay manager). The large API surface adds complexity and increases the chance of misuse.
Completeness4/5
The server covers market data retrieval, technical analysis, chart interaction (local and official), and the ability to export and record state. It includes lifecycle operations for overlays (add/remove/replace) and provides one-call workflows for common tasks. Minor gaps like batch analysis or historical date fetching for multiple symbols exist, but they are not critical for typical use.
Average 3.7/5 across 34 of 38 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 19, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is very brief and does not disclose behavioral details beyond what the annotations already imply. Annotations indicate readOnlyHint=false, destructiveHint=false, which suggests a mutation but not destructive, but the description does not clarify what happens to the chart state or whether the removal is reversible. No additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action. It has no wasted words and is easy to read. However, brevity comes at the cost of missing important details, but as a standalone sentence, it is efficiently structured.
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 tool's simplicity (one parameter, no output schema), the description might be minimally sufficient, but it lacks context about the chart state and how it interacts with other chart tools. Without annotations providing safety details, the description should offer more about the removal effect. It is not complete enough for an agent to invoke confidently.
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 only says 'by id', but the schema already defines 'id' as a string with length constraints. The description adds minimal value: it implies the id refers to an indicator, but does not explain how to obtain the id, its format, or its relationship to other chart elements.
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 'Remove an indicator by id.' clearly identifies the action (remove) and the resource (indicator), but it does not distinguish it from sibling tools like chart_remove_series or chart_remove_level, which also remove chart elements. The mention of 'by id' helps but is not enough to differentiate fully.
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. There is no mention of prerequisites, such as needing an existing indicator or the ID format. Sibling tools with similar removal functions are not referenced, so the agent cannot determine when to use this specific tool.
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 provide readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context. It doesn't explain what happens when an indicator is replaced (e.g., whether existing indicators are overwritten), whether the operation requires a valid chart state, or any side effects. With no additional behavioral information, the description fails to add value beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently lists the supported indicator types. It is appropriately short and front-loaded, with no redundant information. However, it could be slightly more structured, perhaps by explicitly noting that different indicator types use different parameters, but it's still very tight.
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 tool's complexity (8 parameters, multiple indicator types with different parameter requirements), the description is insufficient. There is no explanation of which parameters apply to which indicator type, no mention of output or side effects, and no guidance on how 'replace' works relative to 'add'. The annotation set is minimal, and there is no output schema, so the description must carry more weight for both usage and behavior.
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%, meaning the description provides no parameter details. The schema itself defines parameters like kind, period, fastPeriod, etc., but the description only lists the acceptable indicator types without explaining which parameters apply to each kind. For example, 'standardDeviations' is only relevant to Bollinger Bands, but the description doesn't clarify this, leaving the agent to guess. The description should compensate for the low 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's function: 'Add or replace an SMA, EMA, Bollinger Bands, RSI, or MACD study.' It uses a specific verb (add or replace) and specifies the resource (chart indicator). It distinguishes from siblings like chart_remove_indicator and chart_apply_overlays, though it doesn't explicitly differentiate between 'add' and 'replace' in terms of when one happens.
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 over alternatives, such as when to use a specific indicator type or how to choose between 'add' and 'replace'. It is clear that this is for adding indicators, but there is no mention of prerequisites (e.g., chart must be open), nor any exclusions or alternative tools that might be more appropriate for other scenarios.
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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description doesn't add context about what happens on removal (e.g., whether it's reversible, if it affects other series, or if it requires a chart to be open). The description is minimal and doesn't disclose any behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It front-loads the action and object. No wasted words, but it could be slightly more informative without becoming verbose.
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 tool has one parameter, no output schema, and minimal annotations, the description is insufficient. It doesn't explain how to obtain the id, whether the series must be custom (as opposed to built-in), or any side effects. The context signals show low schema coverage, so the description should compensate but doesn't.
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 schema has one parameter 'id' with no description (0% coverage). The description mentions 'by id' but doesn't explain what the id refers to (e.g., the id from chart_add_series or chart_get_state). Since there's only one parameter and the description gives a hint, it's slightly above baseline but still lacks detail.
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 action (remove) and the resource (custom line or histogram series) identified by id. It distinguishes from sibling tools like chart_add_series and chart_remove_indicator by specifying 'custom line or histogram series'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing to add a series first or that it only applies to custom series, not built-in ones. Sibling tools like chart_remove_indicator and chart_remove_level exist, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Add or replace,' which implies overwriting or replacing an existing zone, but annotations declare destructiveHint=false. This directly contradicts the annotation and no additional behavioral details are disclosed beyond what the annotations already 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?
The description is a single front-loaded sentence with no filler. Every phrase adds meaning, including the resource type and the intended use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no output schema and no parameter descriptions, one sentence is insufficient. It omits replacement mechanics, required-field rationale, time/price format, and relationship to sibling zone tools.
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 for undocumented parameters. It only hints at time/price dimensions and 'add or replace,' but does not explain startTime, endTime, lower, upper, label, color, or id semantics.
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 ('Add or replace') and resource ('shaded time/price zone') with clear use cases (demand, supply, expected ranges, invalidation areas). This distinguishes it from sibling tools like chart_add_level or chart_add_marker.
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 provides context for when to use the tool ('for demand, supply, expected ranges, or invalidation areas') but does not explicitly mention alternatives or when not to use it. Sibling tools are not referenced, so differentiation is only implied by the word 'zone'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Remove', which is a destructive action, but the annotations declare destructiveHint: false, meaning the operation is not considered destructive. This directly contradicts the description. The description also does not disclose any other behavioral traits (e.g., what happens if the id doesn't exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and target. There is zero extraneous information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description omits crucial context: no mention of error behavior, id requirements beyond schema, or interaction with other zone operations. The annotation contradiction further reduces completeness, as the agent cannot reliably infer the operation's safety profile.
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 only parameter is 'id', and the description literally says 'by id', which adds minimal semantic value beyond the schema's type and constraints. Since schema description coverage is 0%, the description does not explain the id format or purpose beyond the obvious reference, so it falls short of compensating.
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 'Remove a shaded chart zone by id' clearly states the action (remove), the resource (shaded chart zone), and the identifier (by id). It distinguishes from sibling tools like chart_remove_level and chart_remove_marker, which target different chart elements.
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 (when you want to remove a zone by its id) but provides no explicit context about when not to use it or alternatives. While the sibling list suggests other removal tools, no exclusions are mentioned, so the guidance is implicit rather than explicit.
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 readOnly, openWorld, idempotent, and non-destructive behavior, so the description does not need to repeat safety. It adds useful context that matching is by ticker or company name, but it does not disclose result-set behavior, limits, or grouping semantics that could affect interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no padding and is front-loaded with the verb 'Search'. It earns its place, though it could be more informative without becoming bloated.
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?
With 7 parameters, no output schema, and no parameter documentation, the description is too minimal. It makes basic invocation possible (just `query`), but the agent will be lost when choosing or leveraging optional filters, grouping, sorting, or language/exchange constraints, which are critical for non-trivial searches.
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, but it only conveys the meaning of `query` ('tickier or company name'). The six optional parameters (`hl`, `lang`, `filter`, `exchange`, `enable_grouping`, `sort_by_country`) remain unexplained, leaving the agent with insufficient information to use them correctly.
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 uses a specific verb ('Search') with a clear resource ('instruments') and the search criteria ('by ticker or company name'). It is clearly distinct as rubuiet it is clearnot what returns is returned and it does not contrast with sibling `market_screen`, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use vs. alternatives is provided. The context implies you use this tool when you have a ticker or company name to search for, versus `market_get_quote` or `market_creen`, but exclusion/alternatives are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Remove', which is a destructive operation on chart state, but annotations include destructiveHint: false. This is an Annotation Contradiction: a delete/remove operation should be marked destructive. The description provides no additional behavioral context beyond the contradictory annotation.
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 sentence with no unnecessary words. It front-loads the action and target, which is ideal for a simple one-parameter removal tool.
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 one-parameter, simple removal tool, the description is minimally viable: it states what is removed and by what identifier. However, it omits where the id comes from, any return/error behavior, and the annotation contradiction lowers confidence. It is adequate but has clear 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% for the only parameter, 'id'. The phrase 'by id' adds minimal meaning and does not explain the id format, how to obtain it, or what happens if the id does not exist. More parameter-level context is needed.
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 ('Remove') and a specific resource ('labeled horizontal price level'), clearly distinguishing it from sibling tools like chart_remove_indicator, chart_remove_series, and chart_remove_zone. The title and schema align on the 'id' parameter.
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 removing a horizontal price level by id, but it does not explicitly state when to use this tool versus alternatives or mention that the id should come from chart_add_level or chart_get_state. No exclusionary guidance is provided.
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 are present but unhelpful (all hints false). The description adds the behavioral trait that no data fetching occurs, but for a mutating tool it does not disclose side effects, persistence behavior, or whether changes apply to the current chart view. No contradiction with annotations is present.
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 sentence that conveys the core purpose and scope with no wasted words. It is front-loaded and easy to parse.
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?
For a simple tool with three optional parameters, no output schema, and no nested objects, the description plus schema cover the essential behavior. The main gap is the absence of usage alternatives, but the tool complexity is low enough that the description is largely complete.
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 67%, with symbol and interval already documented in the schema. The description broadly groups parameters as 'metadata or theme' but does not add meaningful semantics beyond that grouping. This is adequate but not exceptional.
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 states a clear action—'Change chart metadata or theme'—and adds a scope qualifier 'without fetching data' that helps distinguish it from data-fetching siblings. It is not quite a 5 because 'metadata' is somewhat vague and does not explicitly name symbol/interval/theme fields.
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 phrase 'without fetching data' implies when not to use this tool, but there is no explicit when-to-use guidance, no exclusion of alternatives, and no mention of related tools like chart_set_data or chart_get_state. The agent must infer the intended use case from the description alone.
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 readOnly, idempotent, and non-destructive behavior. The description adds one useful behavioral detail ('Local mode returns the currently loaded symbol') but does not explain remote mode or any other runtime behavior, leaving the safety and mode semantics partially uncovered.
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 short sentences with no filler. It front-loads the core action and adds the only meaningful behavioral detail, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good annotations and schema coverage, the tool has no output schema and a nested request object. The description leaves the remote-mode behavior and expected response format unspecified, which is a notable gap for an agent selecting and invoking the 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 coverage is 100% and the only parameter has a meaningful schema description ('Compatible /api/screener/scan JSON body'). The description does not add further parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('Run a market screener request') and the concept of a screener clearly distinguishes it from sibling quote/search tools. However, it closely echoes the title and adds only one behavioral note about local mode, so it stops short of a full 5.
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?
There is no explicit guidance about when to use this tool versus siblings like market_get_quotes, market_search, or market_get_capabilities. The phrase 'Local mode returns the currently loaded symbol' hints at behavior but does not clarify intended use cases or exclusions.
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?
The description adds valuable context beyond the annotations: authentication is loaded only from a configured local state/cookie file and is never returned. This clarifies privacy and side-effect behavior without contradicting 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 sentences, front-loaded with the core action and resource, followed by a necessary authentication note. Every word earns its place with no repetition or filler.
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?
Despite clear purpose and a useful auth caveat, the description does not explain return behavior, layoutId, interval options, or when to use this tool over chart_open. With no output schema and low parameter coverage, this leaves important gaps for an agent.
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 only 33%, and the description mentions symbol and interval but does not explain the interval format, defaults, or layoutId semantics. The full burden is on the description, and it does not compensate for the undocumented 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 uses a specific verb ('Open') and identifies the exact resource ('official TradingView Supercharts UI') for a validated symbol and interval. It is clear, though it does not explicitly differentiate from the sibling 'chart_open' tool.
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 given about when to use this tool versus alternatives like chart_open or the other tradingview_* tools. The intended usage is implied by the action verb, but no exclusions, prerequisites, or alternative recommendations are stated.
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?
The annotations already declare destructiveHint=false and readOnlyHint=false. The description adds that the data is 'deterministic synthetic OHLCV', which clarifies it's a safe demo/reset function. However, the word 'reset' could imply destructive behavior, but it's consistent with the non-destructive demo purpose. No additional behavioral details like what gets cleared or what happens to existing data are disclosed.
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 directly states the action and purpose. It is concise and contains no fluff, earning full marks for efficiency.
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?
Despite having 4 parameters and no output schema, the description provides minimal context. It does not explain return values, the relationship between parameters and the generated data, or how this tool interacts with the chart state. For a testing/onboarding tool, the lack of parameter and behavior details makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to compensate by explaining what seed, count, symbol, and interval do. It does not mention any parameters at all, leaving the agent with no understanding of how these affect the synthetic data generation. This is a critical gap.
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 specific verbs 'Reset' and 'load' with a clear resource ('the chart' and 'deterministic synthetic OHLCV'), indicating it loads demo data. This clearly distinguishes it from sibling tools like chart_import_csv (import real data) and chart_set_data (set specific data). The purpose is immediately clear.
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 phrase 'for testing and onboarding' provides some context for when to use this tool, but it does not explicitly state when not to use it or mention alternatives. No exclusions or comparisons to other chart_* tools are provided, leaving the agent to infer usage boundaries.
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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that data comes from a configured data source or loaded local bars, which is a useful source context but does not disclose further behavioral traits such as return format or failure modes. 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?
The description is a single concise sentence that directly states the action and source. Every word earns its place, and the key information is front-loaded with 'Get one current quote'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description provides a basic understanding of what it does and its data source. However, the lack of parameter explanations for fields and session, combined with no output schema, leaves some gaps. Annotations fill the safety context, but a more complete description would clarify the fields parameter.
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 coverage is only 33% (only symbol has a description), leaving fields and session undocumented. The description mentions 'snapshot fields', which loosely relates to the fields parameter, but it does not explain the valid values or the meaning of the session parameter. The description only partially compensates for the low schema 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 retrieves a single current quote and snapshot fields, and the word 'one' differentiates it from the sibling tool market_get_quotes. However, 'snapshot fields' is somewhat vague and does not specify what fields are included or how they are selected.
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 a single quote, contrasting with the plural sibling 'market_get_quotes', but it does not explicitly state when to use this tool over alternatives like market_get_price or market_get_capabilities. No exclusions or alternative recommendations are provided, only the implied context of a single quote.
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 establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context: output is 'normalized', news is optional, and filters are applied server-side. However, it does not explain what normalization means or what happens when news scraping is enabled.
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. Every phrase carries meaning: normalized, snapshots, optional news, server-side filters. There is no wasted text.
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?
Despite having five parameters, a nested customFilters object, no output schema, and many sibling tools, the description provides only a one-line summary. It does not describe return values, filter behavior, news output, or how this snapshot tool relates to similar market tools.
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 needs to compensate. It vaguely alludes to 'optional news' and 'server-side filters' but does not map these to scrapeNewsHeadlines, customFilters, exchange, proxy, or the symbols format. This leaves the agent without meaningful parameter semantics.
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 and resource: 'Get normalized symbol snapshots'. It also distinguishes the tool from sibling quote/price tools by mentioning normalized snapshots, optional news, and server-side filters.
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 offers no guidance on when to use this tool versus alternatives like market_get_quotes, market_get_price, or market_screen. It states what the tool does but not the conditions or use cases that call for it.
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 readOnly/openWorld/idempotent/non-destructive behavior, and the description adds useful context that authentication details are excluded from the result. However, it does not disclose the output format or whether the snapshot reflects current chart state and overlays, leaving some 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and target, with no filler or redundancy. The second sentence adds important auth-exclusion context and earns its place.
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?
With no output schema, the description should clarify what the returned snapshot is, such as an image URL, base64 data, or file reference, but it only mentions that auth details are excluded. For a simple capture tool with strong annotations and optional size parameters, it is adequate but incomplete around return semantics.
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 has 3 parameters with 0% description coverage, and the description does not explain width, height, or chartOnly. The phrase 'chart region or viewport' only weakly maps to chartOnly, so the description fails to compensate for the missing parameter documentation.
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 states it captures the official TradingView chart region or viewport for visual analysis, providing a clear verb and resource. However, it does not explicitly distinguish itself from sibling tools like chart_snapshot or tradingview_export_chart, so it stops short of 5.
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 phrase 'for visual analysis' implies when to use the tool, and the chart/viewport scope helps clarify intent. But no explicit when-not guidance or alternatives are provided despite many closely related sibling tools, leaving usage guidance minimal.
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 include readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which already convey that this is a mutating, non-idempotent operation. The description adds the 'replace' behavior, but does not elaborate on side effects (e.g., whether an existing marker with the same id is replaced) or any state changes beyond that. Since annotations are present, the description adds moderate extra context but does not fully disclose behavior like does not clarify if replace is keyed by id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action ('Add or replace a marker') and immediately lists the event types. Every word adds value, with no filler or redundant phrasing.
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 tool has 6 parameters, no output schema, and no parameter descriptions in the schema, the description is critically incomplete. It does not explain the format for 'time' (number vs string), how 'replace' works with the 'id' parameter, or the semantics of 'position' relative to bars. The description fails to provide enough context for the agent to correctly invoke the tool, especially given the low schema coverage.
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 has 0% description coverage, meaning the description must explain the parameters. However, the description only mentions event types ('SQ, signal confirmation, participant-flow events, or scenario triggers') but does not map them to specific parameters. None of the six properties (id, text, time, color, shape, position) are explained in the description, leaving the agent to infer meaning only from the schema's type/enum/default constraints, which is insufficient.
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 action: 'Add or replace a marker' and specifies the resource: a chart marker for specific event types (SQ, signal confirmation, participant-flow events, or scenario triggers). This distinguishes it from sibling tools like chart_remove_marker or chart_add_indicator, making the purpose explicit and specific.
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 indicates the tool is for adding or replacing certain types of markers, but it does not explicitly state when to use this tool versus alternatives (e.g., chart_add_indicator, chart_add_level). No guidance is given on prerequisites or exclusions, leaving the usage context only implied by the marker-specific terminology.
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?
The description discloses the atomic apply behavior ('clients never observe a half-updated analysis workspace'), which adds value beyond the annotations. However, it does not mention the 'replace' parameter's default true behavior or what happens to existing overlays, leaving a meaningful behavioral gap. 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?
The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose and key behavioral guarantee.
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 tool with six parameters, nested objects, and no output schema, yet the description provides only one sentence. It omits replace semantics, default behaviors, and any guidance for constructing valid overlay bundles, making it insufficient for reliable invocation.
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?
With 0% schema description coverage, the description must compensate for parameter semantics, but it only names five of the six parameters (indicators, levels, custom series, zones, markers) and omits 'replace' entirely. It adds no detail about parameter formats, defaults, or relationships.
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 ('apply') and resource ('analysis overlay bundle'), enumerates the five overlay categories, and the atomicity phrase distinguishes it from individual chart_add_* siblings. The title reinforces the bundle concept, making the tool's purpose immediately clear.
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 atomicity and bundle wording imply batch use versus the individual chart_add_* tools, but there is no explicit guidance on when to use this tool instead of those alternatives, nor any exclusions. Usage context is implied rather than 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?
Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive), but the description adds no behavioral context beyond 'Remove'. It does not clarify irretrievability, permissions required, or side effects on related data. With minimal annotation coverage, the description should carry more weight, but it remains terse.
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 entire description is a single, clear sentence with zero redundant words. It is front-loaded and achieves its purpose without any fluff.
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 simple tool with one parameter and no output schema, the description is minimally sufficient. However, it lacks context about the need for an open chart, whether the id is chart-scoped, or any error conditions. Given sibling tools like chart_open and chart_add_marker exist, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by id', which confirms the id parameter is the marker identifier, but adds no details about format, constraints, or behavior. The schema already defines type and length, so the description offers only marginal value. Given the single parameter and complete schema, a baseline of 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 action ('Remove') and the object ('chart marker') with a specific method ('by id'). This distinguishes it from sibling removal tools like chart_remove_indicator or chart_remove_level, as it explicitly targets markers.
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 (when you have a marker id and want to remove it), but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites such as having a chart open or owning the marker. For a straightforward removal tool, this is acceptable but not informative.
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 indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds context about using the official dialog and exact name matching, which is useful. However, it does not disclose potential side effects (e.g., modifying chart state) or any prerequisites, but the annotations already cover the safety profile partially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and context. It contains no fluff and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly adequate. However, it could benefit from mentioning that the indicator is added to the currently active chart or specifying any limitations (e.g., only works with certain chart types). The lack of output schema means the description doesn't need to explain return values, but it could clarify the effect on the chart state.
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. The description mentions 'exact built-in or user-visible indicator by name', which clarifies the 'name' parameter's semantics. However, it does not provide details on name format, case sensitivity, or how to find valid names, leaving some ambiguity.
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: using the official Supercharts indicator dialog to add an exact built-in or user-visible indicator by name. It specifies the verb 'add' and the resource 'indicator', and distinguishes it from sibling tools like chart_add_indicator by mentioning the official dialog and exact name matching.
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 context (adding indicators via the official dialog) but does not explicitly state when to use this tool versus alternatives like chart_add_indicator. It lacks guidance on when not to use it or mention of alternative tools for similar tasks.
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's 'Get the current chart summary' aligns without adding significant new behavioral detail. It does add the conditional note about includeBars, which hints that the response size grows when bars are requested, but it doesn't disclose what 'summary' contains or any potential quirks. No contradiction between description and 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 short sentences, with the most important info first. Every word earns its place. The parameter guidance is front-loaded. Perfect length for a simple getter.
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 tool's low complexity (1 optional boolean, no required params, no output schema), the description covers the essential aspects: what it does and when to set the optional parameter. Annotations cover safety. A few more details about what constitutes a 'summary' would push it higher, but for this complexity level it's sufficiently complete.
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 input schema only has includeBars as an optional boolean with 0% coverage, so the description carries the full burden. The line 'Set includeBars only when raw OHLCV is needed' directly clarifies when to set the parameter to true, effectively compensating for the schema's silence. It could be more detailed (e.g., what 'raw OHLCV' implies about response size) but gives the essential meaning.
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 uses the verb 'Get' with the resource 'current chart summary', which is specific and distinct from most sibling tools. It doesn't explicitly contrast with similar state getters like tradingview_get_state, but within the chart_* family it stands out by focusing on the summary. The phrase 'current chart summary' adds enough scope.
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 provides no explicit when-to-use guidance or mention of alternatives. However, the instruction 'Set includeBars only when raw OHLCV is needed' implies the tool has an optional bar-fetching mode, which gives some usage context. This is more than nothing but still leaves the agent to infer when to choose this over siblings.
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 the tool as read-only, idempotent, and non-destructive, so the safety profile is clear. The description adds the batch limit (50) and the 'one call' behavior, but does not disclose response format, error handling, or the meaning of the 'fields' and 'session' parameters. Some behavioral transparency is provided beyond annotations, but it's minimal.
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, direct sentence with no filler. It front-loads the action and limit, making it highly concise and easy to scan.
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?
With 3 parameters, no output schema, and a minimal description, the tool leaves key aspects unexplained. The optional 'fields' and 'session' parameters have no documentation, and the response format is unknown. While the core purpose is clear, the missing parameter semantics and output details make the description incomplete for safe and effective use.
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 description does not elaborate on the 'fields' or 'session' parameters, which are also undocumented in the schema (0% coverage). Only the symbols array has a description inline. Since schema coverage is low, the description should compensate but doesn't, leaving the optional parameters ambiguous. The mention of 'symbols' is generic and adds no specificity beyond the 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?
Clearly states it retrieves quotes for up to 50 symbols in a single call, using the specific verb 'Get' with resource 'quotes' and a clear scope. This distinguishes it from singular counterparts like market_get_quote and market_get_price, which presumably handle single symbols.
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 implies batch usage with 'up to 50 symbols in one call,' which strongly signals use for multiple symbols. It does not explicitly mention alternatives or exclusions, but the context is clear enough that a user needing multiple quotes would choose this tool over singular variants.
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?
While annotations already indicate a mutating operation (readOnlyHint=false), the description adds that the level is horizontal and labeled, describing the visual result. However, it does not disclose any potential side effects like duplicate levels, whether the chart must be open, or how id affects the operation.
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 13-word sentence, front-loaded with the verb, and every word adds value. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for the simple operation of adding a level, but lacks explanation of id and color parameters and does not mention the interaction with chart_remove_level or the current chart state. Given the sibling tools and no output schema, more detail would improve completeness.
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 has 0% description coverage, so the description carries the burden. It mentions 'labeled' (label) and 'horizontal' (price position), but does not explain the id parameter (likely for later removal) or the color parameter. This is incomplete for a 4-parameter tool.
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 specific verb 'Add' and identifies the resource: a labeled horizontal support/resistance/stop/target level. This clearly distinguishes from sibling tools like chart_add_zone or chart_add_marker.
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 implies the use case: adding a labeled horizontal price level. It does not explicitly name alternative tools or give exclusions, but the context is clear. Sibling tools like chart_add_zone and chart_add_marker indicate different shapes, making the usage unambiguous.
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 indicate destructiveHint=false, readOnlyHint=false, so it's a mutation but not destructive. The description says 'Add or replace' which implies it updates existing series. However, it doesn't clarify the effect on existing data, authorization needs, or whether it's reversible. With annotations already flags, the description adds minimal extra behavioral detail.
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?
Description is a single, concise sentence that states the action, resource, and supported types. 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?
Given the tool has 8 parameters (3 required), a rich schema, and an output schema absent, the description is reasonably complete. It lists supported series types and clarifies scope. Although it doesn't explain return values or error behavior, the schema is self-explanatory and the tool is focused. It could mention behavior for replacement or id usage, but it's adequate.
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 provides full parameter definitions with enums and defaults frequenciesing. The description adds context about supported series types (price overlays, CVD panes, etc.) which hints at how pane/kind might relate. But it doesn't explain parameter interplay or data structure beyond what schema shows. Schema coverage is 0% per signal, but the schema itself is fairly descriptive with types and enums, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add or replace a time-aligned line or histogram series.' It specifies the action (add/replace), the resource (chart series), and the allowed types (line/histogram). The mention of supported series types (price overlays, CVD panes, etc.) adds context and distinguishes it from siblings like chart_add_indicator, which would add indicators rather than raw data series.
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 gives context on what kinds of series are appropriate (price overlays, CVD panes, expected paths, etc.), which helps the agent decide when to use this tool vs. alternatives like adding indicators or levels. However, it doesn't explicitly state when not to use it or mention sibling tools like chart_add_indicator or chart_set_data for comparison.
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 indicate readOnlyHint=false, but the description adds the specific side-effect of loading data into the chart viewer by default. It also mentions the flexibility of using a configured data source or local dataset, providing useful behavioral context beyond 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, front-loaded with the primary purpose, and no filler. Every word contributes to understanding the tool's function and its default behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and side-effect but lacks details on output format or how parameters like 'type' and 'range' affect results. Given the tool has 6 parameters and no output schema, more explanation would be helpful, though the essential function is clear.
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 coverage is only 33% (symbol and timeframe have descriptions). The tool description does not explain other parameters like 'to', 'type', 'range', or 'loadChart'. It adds minimal value beyond the schema, especially for the four undocumented parameters.
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 retrieves OHLCV bars for a symbol, specifying the data source (configured or local). It also mentions the default side-effect of loading into the chart viewer, which distinguishes it from quote-only tools like market_get_quotes.
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 gives context about data sources (configured vs local) but does not explicitly advise when to use this tool over siblings like market_get_quotes or market_get_quote. The distinction between OHLCV history and quotes is implied but not stated.
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 are strong: readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds context that the tool reflects chart changes, which is useful, but annotations already cover the safety profile.
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?
One concise sentence, no filler, perfectly scoped to the tool's single responsibility.
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?
For a zero-parameter getter with output schema and solid annotations, description is complete. It doesn't specify what happens if viewer is unavailable, but that's out of scope.
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?
Zero params, schema fully covers it; no additional param explanation needed.
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?
Description uses a specific verb (Return) and resource (local TradingView Lightweight Charts viewer URL) and states that the viewer reflects chart changes made by other tools. It doesn't name alternative sibling functions, but the operation is clear enough to route correctly.
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 implied use case is to retrieve the viewer URL after chart mutations. It lacks explicit when-to-use vs alternatives guidance, but mentions its role relative to other tools.
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 mark it readOnly, openWorld, idempotent, and non-destructive; the description adds valuable details about exactly which state is read and explicitly states that cookies are not exposed—an important privacy-relevant behavior not covered by 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?
One sentence efficiently conveys purpose, content, and a safety guarantee. Every word serves a purpose, and the most important information is front-loaded.
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?
For a zero-parameter inspection tool, the description covers all exposed state attributes and the key negative (no cookies). While it doesn't specify output format, the lack of an output schema makes that extra detail unnecessary.
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 has zero parameters, so the baseline of 4 applies. The description adds no ambiguity, and the empty input schema is fully self-contained.
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 uses a specific verb 'Read' and details the exact state fields (chart URL, symbol, interval, authentication state, delayed-data flag), making it clear what the tool accesses. However, it does not explicitly distinguish itself from similar siblings like chart_get_state, though the field list helps narrow it down.
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 verb 'Read' and the annotations imply this is for safe, non-mutating inspection, but the description offers no explicit 'when to use this vs. that' guidance. Users must infer from the field list when this particular state reader is needed.
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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already convey the safety profile. The description adds the trait 'deterministic', which is useful behavioral context, and lists exact computations (SMA/EMA, RSI, etc.). The disclaimer about investment advice, while not a behavior, is extra context. No contradiction 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 a single, well-structured sentence of what it computes, followed by a brief disclaimer. No superfluous words, and the most important action ('calculate' + indicator list) is front-loaded.
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 zero parameters, no output schema, and a clear 'current chart' context, the description provides a reasonable enumeration of all the indicator families it returns, which is fairly complete. However, it could mention the output format or any side-context like the chart needing to be open (implied by 'current bars') but that is minor. The completeness is adequate for an analysis tool.
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 has zero parameters, so baseline is 4 per guidelines. The description clarifies it operates on 'current bars' and lists the calculated indicators, which is helpful beyond the empty schema. No parameter-specific details are needed.
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 'calculate' and a clear resource 'current chart' with a detailed list of indicators (trend, SMA/EMA, RSI, MACD, etc.). It clearly distinguishes from siblings like tradingview_analyze_symbol by focusing on the current chart, and no ambiguity is present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description only states what it does and disclaims investment advice, but does not mention when it should be preferred over sibling tools like tradingview_analyze_symbol or chart_get_state. The 'current chart' context is implied but not explicitly compared.
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 mark the tool as read-only, idempotent, and non-destructive. The description adds the isolated headless browser context and the ephemeral viewer lifecycle ('browser and ephemeral viewer close afterward unless keepRuntimeOpen is true'), which is valuable beyond 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 tight sentences; the first immediately states the action and output, the second adds the lifecycle caveat. No redundant wording.
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?
For a simple, read-only snapshot with optional parameters, the description covers the core behavior, output type, and runtime side effect. It does not detail PNG encoding or compare with tradingview_snapshot, but that is a minor gap given the tool's simplicity and strong annotations.
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?
With 0% schema description coverage, the description only explains keepRuntimeOpen's side effect; width and height are left to their names and schema constraints. This is partial compensation, not full semantic 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 ('render') and resource ('the local chart viewer'), states the output ('return a PNG for visual analysis'), and the qualifier 'local chart viewer' distinguishes it from tradingview-based siblings like tradingview_snapshot.
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 phrase 'for visual analysis' hints at a use case, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as chart_analyze or tradingview_snapshot.
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=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the behavior is mutable, non-idempotent, but not destructive. The description adds that the browser closes unless keepBrowserOpen is true, and that it archives data, which is useful context beyond annotations. However, it doesn't disclose potential side effects like creating files (archive) or impact on chart state when keepBrowserOpen is true. The description provides some value but could be richer.
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, tightly front-loaded with the primary purpose and then the key behavioral note about browser closing. Every sentence adds value, no fluff or repetition. Excellent conciseness.
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 7 parameters, no output schema, and moderate annotation coverage, the description is fairly complete. It explains the end-to-end workflow, mentions the archive function, deterministic analysis, and metadata, and the browser behavior. It doesn't detail what the 'technical analysis' includes or the exact return format, but the absence of an output schema raises the burden slightly. It covers most critical context for an agent to decide use.
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 86%, so the description's parameter explanations largely cover the fields. The tool description itself only mentions the keepBrowserOpen parameter (by name) and hints at bars/interval via OHLCV and analysis, but does not add much beyond what the schema provides. Since coverage is high, the baseline is 3, and the description adds a small increment by explaining the intended use of includeHistoryBars indirectly (conserving context) and the archive file, which are not explicit in schema descriptions. Overall, the description complements the schema adequately.
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 fetches and archives official TradingView OHLCV, loads it into the local chart, and returns deterministic technical analysis, with a specific verb (analyze) and resource (official TradingView symbol). It is distinct from siblings like tradingview_get_history (which likely only fetches history) and chart_analyze (which might analyze existing chart data).
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 positions this as a 'Recommended one-call workflow' but does not explicitly state when NOT to use it or mention alternatives explicitly. It implies a one-stop analysis workflow, but lacks exclusions like 'for raw data only, use tradingview_get_history' or 'for existing chart analysis, use chart_analyze'. Provides some context but no direct sibling differentiation.
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 indicate readOnlyHint=false and openWorldHint=true, and the description adds transparency by explaining side effects: it uses the chart-data export UI and optionally loads OHLCV into the local chart. This goes beyond the annotations, though it does not mention file output location or return behavior.
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 main action and optional behavior. Every word earns its place with no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and one side effect, but lacks prerequisites (e.g., chart must be open), what the output format is, and what 'loadChart' does to existing data. Without an output schema, this leaves important gaps for an autonomous agent.
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 explain parameters. It implicitly explains loadChart via 'Optionally load OHLCV into the local chart', but outputName is not mentioned at all. For a 2-param tool, this incomplete compensation is insufficient.
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 that the tool downloads chart data currently loaded in official Supercharts via its chart-data export UI, including visible indicator columns. This specific verb+resource+scope distinguishes it from sibling tools like tradingview_get_history or tradingview_snapshot.
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 implies when to use the tool: when you need the currently loaded chart data with indicators, and optionally to load OHLCV for deterministic analysis. It provides context but does not explicitly mention alternative tools or exclusion cases, earning a 4.
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 provide readOnlyHint=false and destructiveHint=false, indicating the tool modifies state but is not considered destructive. The description adds the list of overlay types removed, but does not disclose additional behavioral aspects like idempotency or permanence. It does not contradict the annotations, but adds limited transparency beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully captures the action and scope. No redundant wording or unnecessary details. It is front-loaded with the verb 'Remove' and lists the overlay types efficiently.
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?
For a simple tool with no parameters and no output schema, the description covers the essential action and the types of overlays affected. It does not explicitly mention that it applies to the current chart, but the chart_* naming convention implies that context. It is complete enough, though a mention of 'current chart' could enhance clarity.
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 has no parameters, so the description does not need to document them. The schema covers 100% of the (absent) parameters. Per the rubric, a 0-parameter tool receives a baseline 4, and there is no additional parameter information needed.
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: removing all analysis overlays including indicators, levels, custom series, zones, and markers. It uses specific verbs and lists the affected elements, distinguishing it from sibling tools that remove individual overlay types.
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 implies usage for clearing all overlays in one operation, but does not explicitly contrast with individual removal tools. While the purpose is clear, explicit guidance on when to choose this over chart_remove_* tools would improve it. The context is sufficient for an agent to infer the correct use.
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?
The description makes clear that this operation loads CSV data into the chart and lists the required columns, but it does not disclose side effects such as whether existing chart data is replaced, appended, or whether errors occur for malformed files. Annotations provide no read-only/idempotency assurances, and the description does not fill that gap beyond the basic load behavior.
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 one focused sentence with no filler. It front-loads the core action and then adds only the essential column requirements.
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?
For a straightforward import tool, the description combined with the schema covers the source path, required parameters, and CSV content requirements. It does not explain return values or behavior on invalid data, but those are not strongly necessary for a simple CSV import given the context provided.
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 schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds useful file-content semantics above the schema by noting the time column can be 'timestamp/date' and that volume is optional, which helps agents prepare valid CSV inputs.
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 + resource: 'Load a CSV under MARKET_CHART_DATA_ROOT into the chart' and identifies the required OHLCV columns. It clearly distinguishes this import tool from chart viewing or indicator tools among the siblings.
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 clear context about when to use the tool by specifying the source location (CSV under MARKET_CHART_DATA_ROOT) and target (the chart). It does not explicitly name alternative tools for situations where CSV import is not appropriate, but the path restriction and column requirements imply the intended use.
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 indicate readOnlyHint: false, suggesting this is a state-changing operation, which aligns with 'Replace the chart'. The description adds that it's user-provided data and caps at 10,000 bars, which is useful. However, it doesn't disclose side effects like whether existing chart state is lost, or if this triggers a data fetch. The description adds a bit but doesn't fully disclose behavioral implications beyond what annotations hint.
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, compact sentence with no fluff. It conveys the action, input type, and constraint in under 15 words. Every word earns its place.
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?
For a data-setting tool with 4 parameters and no output schema, the description is fairly complete for its purpose. It clarifies the core action and the primary constraint (max 10,000). However, it could mention that it's a full replacement (not merge) and what happens to existing chart state, which would make it a 5.
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 50%, and the description adds visible semantics by specifying 'OHLCV bars' and the 10,000 maximum, which directly relates to the 'bars' parameter. However, the schema already provides maxItems/minItems constraints and parameter descriptions for symbol and interval. The description adds value by clarifying the data origin (user-provided) and the bar limit, but it doesn't elaborate on all parameters (e.g., source) beyond 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 'Replace the chart with inline, user-provided OHLCV bars' uses a specific verb ('Replace'), names the resource ('chart'), and clearly differentiates from siblings by emphasizing 'inline, user-provided' data. It stands out from sibling chart tools like chart_import_csv or chart_open by implying this takes data directly rather than from a file or URL.
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 implies usage: use this when you want to set chart data from inline user-provided OHLCV bars. It provides a maximum limit (10,000) which is useful context. However, it doesn't explicitly mention alternatives (e.g., chart_import_csv) or when not to use it, but the naming and description are clear enough within the sibling context.
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 the tool is readOnly, openWorld, and idempotent. The description adds behavior about two output modes ('recommendation summary' vs 'detailed indicators') and mentions 'Local mode calculates deterministic indicators from loaded bars'. While it adds useful context, 'Local mode' is not fully explained, which slightly limits transparency. 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?
The description is two sentences long, front-loads the main action, and avoids unnecessary words. Every phrase adds value: the distinction between summary and detailed indicators, and the note about local mode. It is concise without sacrificing essential information.
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 tool's moderate complexity (two params, no output schema) and the presence of annotations, the description covers the core behavior adequately. It explains what the tool returns and the role of the interval parameter. However, the undefined 'Local mode' and lack of details on output structure could leave some gaps, suggesting a slight need for more context.
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 coverage is 100%, with both parameters described (symbol and interval). The description adds semantic meaning to the interval parameter by indicating that setting it changes the output to 'detailed indicators', which is beyond the schema's generic 'Bar interval' description. This helps the agent understand the impact of specifying an interval, though it could be more explicit about syntax or examples.
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 gets a 'multi-timeframe recommendation summary' or 'detailed indicators' depending on interval, making the primary purpose clear. It differentiates from siblings like market_get_quotes or market_get_price by emphasizing technical analysis and recommendation summaries. The verb 'Get' with the resource 'technical analysis' is specific and actionable.
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 when to use the tool: for a recommendation summary by default, or detailed indicators when interval is set. However, it does not explicitly mention alternatives or contrast with sibling tools like tradingview_analyze_symbol or market_screen. The phrase 'Local mode' is ambiguous and lacks clear context on when to use this vs. other modes.
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 cover readOnly, openWorld, idempotent, and non-destructive traits, so the description only needs to add extra context. It usefully discloses that the browser closes by default and that authentication remains local, which are meaningful behavioral details beyond 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 two tightly written sentences that front-load the core action and output type, then add one essential behavioral note. Every clause earns its place with no filler.
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?
For a tool with nine parameters and no output schema, the description is reasonably complete: it states the main inputs, the output format (PNG), the single-call behavior, and browser/auth behavior. It does not detail every optional parameter, but the schema supplies defaults and types for most.
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 descriptions cover only 33% of parameters, so the description needs to compensate. It clarifies the role of symbol, interval, from/to dates, and indirectly keepBrowserOpen via 'browser closes by default,' but leaves width, height, chartOnly, and layoutId unexplained.
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 names a specific verb-plus-resource action: open TradingView symbol/interval, apply a custom date range, and return the chart as PNG in one call. It clearly distinguishes this from sibling snapshot/export tools by emphasizing exact YYYY-MM-DD range capture.
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 clear context for when to use the tool: when a chart PNG for an exact date range is needed in a single call. It does not name alternatives or explicit exclusions, but the exact-range and one-call focus is sufficient practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (openWorldHint=true, readOnlyHint=false), the description adds essential behavioral context: it navigates the TradingView Supercharts UI and exports data, aggregates intraday bars based on interval, includes prior/next bars, and explicitly returns no_session_bar for non-trading days instead of substituting a date. This significantly enriches understanding of side effects and edge cases.
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 sentences, front-loaded with a clear recommendation. The first sentence is concise, the second is a long list of return values but still efficient, and the third adds a key edge-case behavior. There is no fluff, but the long middle sentence could be streamlined. Overall, it is appropriately sized for the complexity.
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 no output schema, the description needs to explain the return content, which it does comprehensively (session/intraday aggregate, prior/next bars, price changes, gaps, ranges, volume, rolling performance, TA). It also covers the non-trading day behavior. It does not discuss limits beyond lookbackBars or error handling beyond no_session_bar, but given the complexity, it is quite complete.
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 75% (6 of 8 parameters have descriptions). The tool description does not add parameter semantics beyond what the schema already provides; it mentions interval aggregation but that is already in the schema. With high coverage, a baseline of 3 is appropriate, as the description does not compensate with extra parameter details for the undocumented parameters (layoutId, keepBrowserOpen).
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: one-call retrieval of comprehensive data for a single date, including OHLCV, prior/next bars, price changes, ranges, volume, and TA. It distinguishes itself from siblings by being the 'recommended one-call historical-date workflow' and explicitly handling non-trading days with a no_session_bar status.
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 frames itself as the 'recommended one-call historical-date workflow', giving strong contextual guidance for when to use it. However, it does not explicitly mention alternatives or when not to use it, such as when multi-day history is needed. This is clear but lacks explicit exclusions or alternative tool references.
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 provide basic flags (openWorld, not read-only), but the description adds valuable behavior: the browser closes unless keepBrowserOpen is true, CSV is archived locally, default return is a compact summary, and no account upgrade is attempted. This exceeds the annotation-only information without contradicting them.
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 tight paragraph with no filler. Each sentence contributes: main action, includeBars note, browser keep-alive, interval support, and a non-goal. Front-loaded with the key 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 8 parameters, no output schema, and annotations present, the description covers the default return format, raw bar inclusion, browser lifecycle, and interval scope. It does not mention rate limits or error cases, but it is sufficiently complete for selection and invocation.
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 high (88%), so baseline is 3. The description adds extra meaning for includeBars ('only when raw OHLCV must enter model context') and keepBrowserOpen (browser lifetime), enriching the parameter understanding beyond the 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 opens a TradingView symbol/interval, exports chart data via Supercharts, archives the CSV, and returns a compact summary by default. This distinguishes it from siblings like tradingview_get_day or market_get_quotes by explicitly covering multiple intervals and the archival/export behavior.
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 practical guidance: 'Set includeBars only when raw OHLCV must enter model context' and clarifies browser lifetime with keepBrowserOpen. It does not explicitly name alternative tools, but the context signals and sibling names make the role clear, and the guidance is actionable.
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 indicate this is not read-only, not idempotent, and not destructive. The description adds value by specifying exactly what is closed (browser, context, page) and reassuring that 'Authentication files remain local and untouched.' This is useful behavioral context beyond the structured 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 two short sentences. The first states the core action and scope; the second adds a key safety clarification. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter close operation with no output schema, the description is complete: it names the exact resources affected and clarifies that authentication files are preserved. No additional context is necessary for correct invocation.
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 has zero parameters and the schema confirms this with an empty properties object. Description adds nothing about parameters because none exist, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Close', and identifies the exact resources: 'managed TradingView browser, context, and page.' This clearly distinguishes the tool from sibling tools like tradingview_open_chart or chart_get_state, none of which perform a close operation.
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 clear context: it closes the managed TradingView browser/context/page, implying it is the counterpart to an open/session tool. However, it does not explicitly state when to use it vs. alternatives or mention prerequisites like 'after opening a chart.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. Description supplements with current chart state and browser auth checks, adding important context. 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 sentences, frontloading: reports first, then the specific use. All words are information-dense.
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 no-parameter inspection tool of market capabilities, coverage of internal capabilities and workflow placement is fully present; the output shape is not needed here.
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?
Tool uses zero parameters; the schema contains no properties and params are captured at 100% coverage, so the baseline for zero-parameter tools is 4.
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 specific verbs and resources ('Report configured providers, browser authentication availability, lazy runtime state, and currently loaded chart') and gives distinct capability from market data tools. Use of 'Use this before choosing a data pipeline' reinforces intent.
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?
States when to use: 'Use this before choosing a data workflow.' It does not clearly spell out when to use alternatives, but among siblings like market_get_quotes and chart tools, this is a meta-inspection tool for providers/auth/chart state and is appropriately positioned.
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/moeuu/tradingview-mcp/badges/card.svg)](https://glama.ai/mcp/servers/moeuu/tradingview-mcp)

Score Badge

Copy to your README.md:

[![tradingview-mcp MCP server](https://glama.ai/mcp/servers/moeuu/tradingview-mcp/badges/score.svg)](https://glama.ai/mcp/servers/moeuu/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/moeuu/tradingview-mcp'

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