TVControl

by FerroxLabs

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v2.2.1
Disambiguation2/5
With 101 tools, many have overlapping purposes, such as tv_health_check, tv_compatibility_check, tv_capability_matrix, and tv_compatibility_snapshot, plus multiple data retrieval tools (data_get_study_values, data_get_indicator, chart_vision_read). Agents will struggle to choose the correct tool due to unclear boundaries.
Naming Consistency3/5
Most tools use snake_case and follow a verb_noun pattern (chart_set_symbol, watchlist_add), but there are notable deviations like symbol_info, replay_status, tv_ui_state, tab_new, and state_snapshot that break the pattern, making the set inconsistent though still readable.
Tool Count1/5
With 101 tools, this far exceeds the 50+ threshold defined as an extreme mismatch. Even for a comprehensive TradingView control server, the count is excessive and many tools could be consolidated or are overly granular.
Completeness5/5
The tool surface is remarkably complete, covering chart management, indicators, Pine scripting, drawings, alerts, watchlist, replay, layouts, UI automation, snapshots, and diagnostics. There are no obvious gaps in the lifecycle of TradingView operations.
Average 3.6/5 across 100 of 101 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on July 15, 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?
No annotations are provided, so the description carries the full burden. It discloses the destructive action ('delete') but does not explain the context menu behavior, what happens to specific alerts, or any required confirmation/permissions. The dual nature ('delete all' or 'open context menu') is under-specified.
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 the primary action front-loaded. It contains no fluff, but the second clause is vague and could be seen as under-specification rather than true 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?
For a deletion tool with no annotations and no output schema, the description is incomplete. It does not clarify the difference between 'delete all' and 'open context menu', nor how the parameters map to these behaviors. Sibling tools like 'alert_delete_by_id' exist, making the lack of usage context a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for each parameter, so the description does not need to add parameter details. However, the description's 'or open context menu for deletion' does not align with the parameter-based deletion paths, adding slight confusion rather than value.
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 identifies the action ('Delete all alerts') and resource ('alerts'), but the 'or open context menu for deletion' clause is ambiguous and does not cover the schema's support for deleting specific alert IDs via 'alert_id' and 'alert_ids'. It also fails to distinguish this tool from the sibling 'alert_delete_by_id'.
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 on when to use 'delete_all' versus individual IDs, nor when to prefer 'alert_delete' over 'alert_delete_by_id'. The phrase 'open context menu for deletion' hints at a UI interaction but does not explain conditions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It provides no information about side effects, whether shapes are overwritten, validation rules, or the response format. This is a critical gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and immediately conveys the core purpose. However, it is extremely terse and lacks any supporting details, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with nested objects, no annotations, and no output schema, the description is severely incomplete. It fails to mention return values, error conditions, prerequisites, or how to construct valid point objects. This is inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as every property in the input schema has a description. The description itself adds no parameter-specific meaning, but since the schema already documents parameters thoroughly, the baseline of 3 applies.
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 ('Draw') and the resource ('shape/line on the chart'). It distinguishes from sibling tools like draw_clear or draw_remove_one by identifying this as the drawing operation. However, it does not enumerate the specific shape types, relying on the schema for that detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of how this relates to sibling draw tools (e.g., draw_clear, draw_remove_one) or any prerequisites such as having a chart open. The usage is only implicitly understood from the action verb.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It offers none—no mention of side effects, chart state changes, symbol validation, or whether the chart must be open. This is a complete lack of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the action clearly. It is appropriately concise for a simple tool with a single parameter.
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 the tool's simplicity, the description lacks essential context: it does not mention that a chart must be active, what happens to the current symbol, or how the change affects other chart state. With no output schema or annotations, the description leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'symbol' parameter with examples, so schema description coverage is 100%. The description text adds no additional parameter semantics beyond the schema, which is acceptable given the baseline for high 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 action: changing the chart symbol. It uses a specific verb and resource, and is distinguishable from sibling tools like chart_set_timeframe and chart_set_type, though it closely mirrors the tool name itself.
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 such as symbol_search or pane_set_symbol. There are no prerequisites, exclusions, or context about when a symbol change is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Change chart type' without detailing side effects, validation behavior, or persistence of changes, which is insufficient for a tool that modifies chart state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but this borders on under-specification rather than effective brevity. While it is front-loaded and to the point, it omits useful context that could be conveyed in a single additional sentence without sacrificing clarity.
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 low complexity (single parameter with rich schema) and absence of an output schema, the description is minimally sufficient but not complete. It lacks details on expected outcomes or interaction with chart state, though the parameter schema mitigates some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive documentation for the single parameter, including accepted names and numbers with 100% coverage. The description itself does not add any additional meaning beyond what the schema conveys, so a 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 'Change chart type' clearly states the action (change) and the resource (chart type), distinguishing it from sibling tools like chart_set_symbol and chart_set_timeframe. It is specific enough to understand the tool's primary function, though it lacks elaboration on what 'chart type' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, conditions, or references to other tools, leaving the user to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Get' implies a read-only operation, but the description does not mention potential edge cases (e.g., what happens if entity_id is invalid), return format, permissions, or any side effects. It adds no behavioral context beyond the verb itself.
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 wasted words. It efficiently communicates the core operation without extraneous content. This is well-structured for a simple getter.
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, the description is still incomplete. It does not explain what 'info' includes, how this relates to chart state, or how it differs from similar tools like data_get_study_values. With no output schema and no annotations, the agent lacks enough context to invoke this tool confidently in all scenarios.
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% since the single parameter entity_id has a description ('Study entity ID (from chart_get_state)'). The tool description itself does not elaborate on the parameter, but because the schema already provides sufficient meaning, a baseline score of 3 is appropriate. No additional value is added by the description for parameter understanding.
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 'Get' and clearly identifies the resource: 'indicator/study info and input values'. This distinguishes it from tools like data_get_study_values (which likely returns computed values) but does not explicitly mention that distinction. It is clear and non-tautological, though it could be more explicit in naming the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as data_get_study_values or chart_get_state. The description simply states what it does without context for selection. The only contextual clue comes from the parameter description in the schema, but the tool description itself fails to offer usage direction.
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 absent, so the description alone must convey safety and behavior. It only says 'change the chart grid layout' without mentioning side effects, whether it resets existing panes, or if it requires any preconditions.
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.
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 one parameter and no output schema or annotations, the description is too minimal to be fully complete. It doesn't explain the behavior of layout changes on existing content, nor what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the layout parameter with all accepted codes. The description's examples ('single, 2x2, 2h, 3v') overlap with the schema but don't add additional meaning or clarify ambiguous codes.
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 changes the chart grid layout, with examples of layout codes. This distinguishes it from pane_focus (focusing a pane) and pane_set_symbol (setting a symbol), though it doesn't explicitly differentiate from layout_switch.
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 on when to use this tool versus alternatives. The description simply states the action; an agent must infer from sibling names that this handles specific grid codes while layout_switch may handle saved layouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the function 'search' without mentioning return format, result limits, case sensitivity, wildcard behavior, or whether the search covers all symbol types. This leaves significant behavioral ambiguity.
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 succinct sentence that immediately conveys the core action. It is front-loaded and efficient, though somewhat sparse for a tool with two parameters and no output schema.
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?
The tool is simple, but without an output schema, the description should explain what the search returns and any constraints (e.g., supported symbol types, result ordering). This information is missing, making the description incomplete for an agent to fully understand the tool's behavior.
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% (both parameters have descriptions). The description adds minimal extra meaning beyond 'by name or keyword' which maps to the query parameter, but it does not clarify the type parameter's role beyond the schema's existing explanation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) and the resource (symbols) with a specified method (by name or keyword). It is specific enough to distinguish from related tools like symbol_info, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other search-related tools like indicator_search or tv_discover. There are no usage contexts, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It mentions 'bounded privacy-safe' but gives no details about what the history contains, whether the watchdog must be running, or if the returned data is cleared or limited. This is insufficient for a history-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It is not verbose, but its brevity may sacrifice necessary detail, making it slightly under-specified rather than optimally concise.
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 absence of an output schema and annotations, the description should explain the return format or semantics of state-transition history. It does not, leaving the agent uncertain about what data will be received and how to interpret it.
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 covers 100% of the parameter, including default and max values. The description adds the word 'bounded,' which aligns with the limit parameter but does not provide any additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns watchdog state-transition history, using a specific verb and resource. It distinguishes itself from related watchdog tools like status, sample, start, stop, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other watchdog tools or any exclusion criteria. The sibling list includes similar tools, but no differentiation is made, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It says 'Check' but doesn't explain whether this is read-only, what network operations occur, what the output looks like, or whether any side effects (e.g., opening connections) are involved. The acronym 'CDP' is ambiguous and could lead to misinterpretation.
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, front-loaded sentence listing the key check areas. It's concise and transparent, though the term 'CDP' could be expanded for clarity. Every word contributes to the overall intent.
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 health check tool, the description lacks critical context: it doesn't explain what constitutes a healthy state, what output or status indicators to expect, how to interpret results, or how it relates to the many sibling diagnostic tools. No output schema exists, so the description must carry more, but it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema coverage is 100% (empty schema). According to the baseline, no parameter explanation is needed. The description's mention of the checked areas adds some context but is not required for parameter understanding.
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 specific verb ('Check') and lists the resources: CDP, TradingView market-data connection, compatibility, and current chart state. This gives a clear general purpose, but it doesn't distinguish itself from specialized sibling tools like tv_compatibility_check or chart_get_state, and 'CDP' is an unexplained acronym.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tv_compatibility_check, chart_get_state, or tv_watchdog_sample. It does not specify prerequisites, exclusions, or which scenarios favor this comprehensive check over individual checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, yet it only states the action without mentioning side effects, prerequisites, or failure modes. It does not disclose that removal requires an entity_id from chart_get_state or that indicator names must be full names, leaving critical behavioral details to the schema descriptions.
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 immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary words 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 is sufficient for a basic understanding but lacks context about prerequisites and the source of entity_id. Since there is no output schema, a brief note about expected behavior or return values would improve completeness, but the schema partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter semantics, but the schema effectively explains the parameters including enums, required fields, and naming constraints. The tool description adds no additional meaning beyond that.
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 (add or remove) and the resource (indicator/study on the chart). It is specific enough to convey the tool's core function, though it does not explicitly distinguish it from sibling tools like indicator_add_from_search or indicator_toggle_visibility.
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 such as indicator_add_from_search or indicator_set_inputs. The schema hints at usage (e.g., entity_id for remove, indicator for add), but the description itself provides no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Focus a specific chart pane' without explaining side effects (e.g., which pane becomes active, whether the UI scrolls, or what happens if the index is invalid). The '0-based' indexing and reference to pane_list are helpful but do not disclose the underlying behavioral semantics.
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, focused sentence that immediately states the action and parameter. It is front-loaded with the verb and resource, contains no filler or redundant wording, and is appropriately concise for a simple 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 tool with one parameter and no output schema, the description conveys the basic operation and references the index source via the schema. However, it lacks broader context such as when to use this tool, how it fits into the pane-management workflow, and what the expected result is (e.g., active pane selection). This makes it minimally viable but not fully 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?
The input schema provides 100% coverage with a clear description of the 'index' parameter ('Pane index (0-based, from pane_list)'). The tool description repeats this information ('by index (0-based)') without adding additional meaning. Since the schema already documents the parameter effectively, the description meets the baseline but does not go beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Focus') and the resource ('specific chart pane'), with the index parameter specifying the target. It is distinct from sibling tools like pane_set_layout or pane_set_symbol, which perform different operations on panes. However, 'focus' could be more explicit about the resulting behavior (e.g., making the pane active for subsequent commands), so it stops short of a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like calling pane_list first, or how this relates to pane_set_layout or pane_set_symbol. There is no context on whether this is needed before other pane operations. The user must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys the destructive nature via 'Delete', but does not disclose permanence, side effects, or failure conditions. The agent is left to infer that deletion is irreversible.
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 wasted words. It efficiently captures the essential action and object.
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 one-parameter delete operation with no output schema, the description covers the core functionality. However, it omits any mention of return behavior, error handling, or precondition that the snapshot must exist, leaving minor gaps. The tool's simplicity keeps the impact low, so a 3 is appropriate.
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% with 'name' described as 'Snapshot name to delete'. The description echoes this by saying 'named chart state snapshot', adding no further meaning. The baseline of 3 applies because the schema already fully documents the parameter.
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 verb 'Delete' and the resource 'named chart state snapshot', making the tool's purpose unambiguous. It distinguishes from sibling tools like state_snapshot (create) and state_restore (restore) through the action word, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, with no mention of prerequisites, exclusions, or alternative tools like state_list for listing snapshots.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure, but it only states 'iterate'. It reveals nothing about side effects (e.g., chart modifications, caching, parallelism, restore behavior) or operational characteristics (e.g., long-running, error handling, resource usage). This is a significant transparency gap.
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, front-loaded sentence that directly states the core function without filler. It is appropriately concise, though for a tool with 14 parameters it could arguably carry more contextual weight 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?
This is a complex sweep tool with 14 parameters, no annotations, and no output schema. The description only names the dimensions being swept, omitting crucial context about execution, side effects, caching behavior, error handling, result delivery, or how it integrates with the other chart/strategy tools. It is far from complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter semantics; it relies entirely on the detailed per-parameter descriptions in the input schema. No extra meaning is conveyed beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Iterate a strategy across symbols × timeframes × indicator input combinations' uses a specific verb (iterate) and identifies the exact resource (strategy) and the three sweep dimensions. This clearly distinguishes it from siblings like data_get_strategy_results (which retrieves results) and batch_run (generic execution).
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 its usage for sweeping multiple parameter combinations but never explicitly states when to choose it over alternatives, nor does it mention exclusions or complementary tools. It offers only a terse purpose without contextual guidance on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It reveals the tool performs a mapping and reports availability, but does not mention potential side effects of probing the live runtime, whether it is read-only, or that it may be slow. The `probe` parameter implies runtime interaction, but the description omits this.
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 conveys the core function and output without any filler or redundant phrasing. 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?
The tool has two optional parameters and no output schema. The description explains the purpose and outcome at a high level, but lacks detail about the returned matrix structure, the meaning of 'available or blocked', and any runtime behavior like caching or probing. It is adequate but leaves gaps for a diagnostic tool in a large sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters `force` and `probe` are fully documented. The tool description adds no additional meaning beyond the schema, but given the high coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Map every TVControl tool to its required TradingView APIs') and the output ('report which tools are currently available or blocked'). It distinguishes itself from sibling tools like tv_health_check by focusing on the tool-to-API capability matrix, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as tv_compatibility_check or tv_discover. The description only states what the tool does, with no context for choosing it over other diagnostic tools or mention of prerequisites.
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?
The description only states the action 'hover' without disclosing behavioral traits such as whether the element is scrolled into view, how multiple matches are handled, or error behavior when the element is not found. With no annotations provided, the description carries the full burden and falls short of meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core action and target. There is no redundant information or filler, making it optimally concise and front-loaded.
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 tool is simple with two parameters and no output schema, so a brief description is somewhat sufficient. However, it lacks details about failure scenarios and does not mention the 'class-contains' selector option. It also provides no context on how hover behaves in the broader UI automation workflow, making it only minimally 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?
The schema already provides full coverage (100%) for the two parameters with descriptions for 'by' and 'value'. The description partially repeats the enum values (aria-label, data-name, text) without adding new meaning, and it omits 'class-contains'. Thus, 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 clearly states the tool's purpose: hovering over a UI element using specific selector strategies. It distinguishes itself from sibling tools like ui_click and ui_find_element by naming the action. However, it omits the 'class-contains' selector strategy that is present in the schema, making it slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or exclusions, and does not reference sibling tools like ui_click or ui_find_element. This leaves the agent without contextual direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the basic scroll action but does not say whether it scrolls the chart viewport or the page, what side effects occur, or whether the amount parameter is optional. This is a notable gap.
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 redundant words. It efficiently conveys the core behavior 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 full parameter schema and no output schema, the description is minimally adequate but has a notable ambiguity ('chart or page') and lacks behavioral context that the absence of annotations would require. It is not fully complete for an agent to understand the exact effects.
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%, so the parameters are already documented with descriptions (direction enum, amount default). The description adds no additional meaning beyond what the schema provides, matching the baseline for high 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 action ('Scroll') and the resource ('chart or page'), with explicit direction options. It distinguishes from chart_scroll_to_date (which scrolls to a specific date) but could be more specific about whether it targets the chart viewport or the page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like chart_scroll_to_date or chart_set_visible_range. There is no context about intended scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the search action without disclosing return format, pagination behavior, or query matching semantics. Additional context like default limit is left to the schema, and no behavioral traits are surfaced.
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, front-loaded sentence listing the search scope with no fluff. It is appropriately concise for the simplicity of the tool, though it provides no additional structural benefits like examples or context.
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 (2 params, no output schema), the description covers the core purpose but omits return value details and usage context. It is minimal viable, adequate for selection, but leaves room for clarification about what the search returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (query and limit), so the schema already provides adequate parameter meaning. The tool description adds no extra semantic value beyond the schema, keeping the baseline at 3.
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 'Search' and clearly identifies the resource as TradingView studies (built-in, community, strategy, saved-script). This distinguishes it from symbol_search and other search-like tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that results could feed into indicator_add_from_search, nor does it state any exclusions or prerequisites. The context for use is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and prerequisites. It does not mention whether the operation is destructive, whether it replaces an existing indicator, what happens if no script is present, or what the result/return value is. This is a significant transparency gap for a mutation-like action.
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 the meaning, and the action is stated efficiently.
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 zero-parameter tool, the description is minimally adequate but leaves out important context. It does not clarify what 'current Pine Script' refers to (e.g., the script in the editor), whether the operation can fail, whether it adds a new instance or replaces an existing one, or what the output/return behavior is. This is a simple tool, but the description could be more 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 tool has zero parameters, and the input schema is empty. Per the rubric, the baseline for 0 params is 4. The description adds no parameter-specific information, but none is needed since there are no parameters to document.
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 with a specific verb ('Compile / add') and resource ('current Pine Script') and target ('to the chart'). It distinguishes from sibling tools like pine_smart_compile or pine_check by emphasizing the add-to-chart behavior, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as pine_smart_compile, pine_check, or chart_manage_indicator. There are no prerequisites, exclusions, or contextual hints beyond the bare action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full responsibility for disclosing side effects. It only states 'Create a new blank Pine Script' without explaining whether this replaces the current editor content, opens a new tab, or returns some identifier. This lack of detail is a significant gap for a creation tool.
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 one-sentence, front-loaded statement with no unnecessary words. It efficiently communicates the core purpose and is highly concise.
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 simple create operation, but the description is too sparse to be considered complete without annotations or an output schema. It fails to mention critical details such as the effect on the current script, return value, or any prerequisites, leaving the agent with incomplete information about how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'type' has full schema coverage (100%) with a clear description and enum values. The description does not add extra parameter semantics, but the schema already provides adequate detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new blank Pine Script', which uses a specific verb and resource to clearly convey the tool's function. It is easily distinguished from sibling tools like pine_open (which opens existing scripts) and pine_compile (which compiles), so there is no ambiguity.
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 usage context is provided. The description does not mention when to use this tool versus alternatives like pine_open or pine_set_source, nor does it specify prerequisites or typical workflow steps. The agent is left to infer this from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'set' without revealing whether the source is overwritten, whether compilation is triggered, or whether the editor must already be open. This is a significant gap for a mutating 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, efficient sentence that wastes no words. It is front-loaded with the action and resource, making it easy to parse quickly.
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 mutation tool with no annotations, no output schema, and a minimal description. It lacks context about prerequisites (e.g., whether an editor must be active), side effects, or return behavior. Given the simplicity of the tool, more behavioral context is needed for reliable use.
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 already provides a full description for the single parameter 'source' as 'Pine Script source code to inject', and schema coverage is 100%. The description adds no extra meaning beyond what the schema states, so 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 verb 'set' and the resource 'Pine Script source code' within the 'editor', making it distinct from siblings like pine_get_source (get) and pine_compile (compile). It explicitly identifies the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as pine_new, pine_open, or pine_compile. There are no mentions of prerequisites (e.g., an open editor) or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only adds the qualifier 'privacy-safe' without explaining what that means, what the status contains, or whether any side effects occur. This is insufficient for a tool with zero annotation coverage.
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 efficiently conveys the core function. Every word adds value, especially 'privacy-safe' which hints at an important non-obvious property.
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 simplicity of the tool (no params, no output schema), the description is minimally viable but leaves key details unresolved: what 'status' includes, what a 'sample' represents, and how this relates to other watchdog tools. This is particularly relevant due to the absence of annotations and output schema.
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 schema completely covers the input interface. Per the baseline for 0-parameter tools, the description need not add parameter details, and it does not.
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 specifies the action 'Return' and the resources 'watchdog runtime status' and 'latest privacy-safe sample', clearly identifying it as a status/sample retrieval tool. It is semantically distinct from sibling tools like tv_watchdog_start/stop, though it doesn't explicitly contrast with tv_watchdog_sample.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tv_watchdog_sample, tv_health_check, or tv_watchdog_history. The description is purely declarative and lacks use-case context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Import' without mentioning that this can modify/overwrite the existing watchlist (replace mode) or that dry_run exists. The schema covers these details, but the description itself fails to warn about potential destructive side effects, which is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that concisely captures the tool's core purpose. Every word earns its place 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?
Despite having a 3-parameter schema with no annotations and no output schema, the description is overly terse. It does not explain the import behavior, mention that the file should come from watchlist_export (though the schema does), or clarify any return values or effects. A more complete description would at least note the merge/replace distinction and dry-run capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema. It does not mention mode, dry_run, or file_path, but the schema already thoroughly documents each parameter and their defaults.
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 (import), the target (symbols into the TradingView watchlist), and the source (from a JSON file). It distinguishes itself from sibling tools like watchlist_add or watchlist_add_bulk by emphasizing the JSON file source.
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. Unlike the calibration example that explicitly names alternative tools, here there is no mention of scenarios or exclusions, leaving the agent to infer usage from the tool name and file_path schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'authenticated API' but does not disclose side effects, permissions beyond authentication, reversibility, or failure behavior. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It captures the essential action and context efficiently.
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 tool is moderately simple with well-documented parameters, but lacks usage guidance and behavioral transparency. While the schema covers parameters, the description does not fully address the absence of annotations, making it minimally 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 description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, such as parameter interactions or format details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'price alert', specifying the context 'on the current chart'. It distinguishes from sibling alert tools like alert_list and alert_delete by indicating this tool creates alerts.
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, no prerequisites, and no exclusions. It only implies usage through its verb, but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without revealing side effects, persistence across chart changes, scope, or what happens if the entity_id is invalid. This is a minimal disclosure, not a transparent one.
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 short sentence that is front-loaded with the verb and resource. It contains zero extraneous words and is perfectly sized for the tool's simplicity.
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 tool is simple and the schema fully documents both parameters, but the description lacks any usage guidance or behavioral context. Without annotations, an agent would not know about potential side effects or limitations, making this merely adequate rather than 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 100% with both parameters already clearly described ('true to show, false to hide' and 'Entity ID of the study (from chart_get_state)'). The description adds no additional parameter semantics, but the schema fully handles this duty, making the baseline score of 3 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 uses a specific verb ('Show or hide') and names a clear resource ('indicator/study on the chart'). This immediately distinguishes it from sibling tools like indicator_add_from_search or chart_manage_indicator, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or preferred contexts, leaving the agent to infer usage solely from the tool's name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It mentions only the action and doesn't address side effects, prerequisites, validity of index, or post-conditions. For a mutating operation, this is 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?
A single, front-loaded sentence that delivers the essential meaning without wasted words.
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 simple operation is reasonably well-specified by the description and schema, but lacks information about error handling, valid pane indices, and how it relates to chart_set_symbol. No output schema means the return value is also unaddressed.
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 100% description coverage for both parameters (index and symbol). The description clarifies their roles ('set symbol on pane by index') but adds no additional formatting or constraints beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set'), identifies the resource ('symbol on a specific pane'), and specifies the mechanism ('by index'). It clearly distinguishes from sibling tool chart_set_symbol by targeting panes rather than the chart itself.
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 like chart_set_symbol. The description only states what it does, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not mention what happens if multiple elements match, if no element is found, whether it waits for interactability, or what the return value is. This is a significant gap for a UI automation tool.
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 sentence, front-loaded with the verb, and every word adds value. It is appropriately brief with no filler or redundant phrasing.
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 two-parameter tool with no output schema, the description is minimally adequate, but it lacks important context such as error handling, matching behavior (first vs. all matches), and how it relates to sibling tools like ui_mouse_click. Clear gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already describes both parameters. The description essentially restates the enum values without adding extra meaning about matching behavior (e.g., exact vs. substring), so it does not materially exceed schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Click a UI element' and lists the selector strategies, clearly distinguishing this from sibling interaction tools like ui_hover and ui_scroll. The 'by' clause makes the target and method precise.
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 such as ui_mouse_click or other UI interaction tools. It simply states the action, leaving the agent to infer appropriate usage context with no exclusions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does, not how it behaves (e.g., whether it requires focus, simulates key down/up, or may trigger platform shortcuts). There is no mention of side effects, prerequisites, or potential failures, leaving significant behavioral ambiguity.
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 front-loads the primary action ('Press keyboard keys or shortcuts') and includes useful examples. Every word earns its place, with no wasted text.
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 tool is simple (2 params, no output schema), and the description provides a basic understanding of its purpose and examples. However, given the absence of annotations and the presence of sibling tools with overlapping functionality, the lack of usage guidance and behavioral details makes the description only minimally 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 100%, so the parameters are already documented. The description adds examples of combined shortcuts (e.g., 'Alt+S', 'Ctrl+Z') that illustrate how the 'modifiers' array interacts with 'key', which is helpful. However, this is marginal value beyond the schema descriptions, 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.
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: 'Press keyboard keys or shortcuts'. It uses a specific verb (Press) and resource (keyboard keys or shortcuts), and provides concrete examples like 'Enter, Escape, Alt+S, Ctrl+Z' that distinguish it from sibling tools such as ui_click (mouse) or ui_type_text (text input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. While the tool name and description imply it is for keyboard input, there is no mention of exclusions or comparisons to siblings like ui_type_text or ui_hover. Users must infer that this tool is for pressing keys, not for typing text or mouse actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the possible actions and panel names from the schema, without disclosing side effects, dependencies (e.g., TradingView must be launched), or state-related nuances of toggling.
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 concise sentence that front-loads the main action and resource, with no wasted words. It efficiently communicates the tool's scope.
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 tool is simple, and the description covers its core behavior. However, it lacks usage context and behavioral caveats that would help an agent decide when to use it, especially given the many sibling UI tools. Without annotations, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description lists the panel names and actions, reinforcing the enums but not adding substantial new meaning beyond the schema. The parameter descriptions in the schema are minimal, but the enums themselves provide the core 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 clearly states the tool's function with specific verbs (open, close, toggle) and a specific resource (TradingView panels) with an explicit enumeration of panel names. This differentiates it from sibling tools like ui_click or tv_ui_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites, exclusion cases, or suggest alternative tools for similar tasks, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic typing action, omitting what happens if no element is focused, whether text replaces or appends existing content, and potential side effects. This is a significant transparency gap.
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 unnecessary words. All information provided is relevant and concise.
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, the description covers the core action but lacks edge-case context like what happens when no element is focused or whether the tool works on contenteditable elements. This leaves some ambiguity for the agent, so it's adequate but not fully 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?
The single parameter 'text' is fully described in the schema, and the tool description adds no extra parameter detail. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (type text) and the target (focused input/textarea), making it specific. It doesn't explicitly differentiate from sibling tools like ui_keyboard or ui_click, but the element-type scoping provides useful distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the element must be focused before use, offering some usage context. However, it doesn't mention alternatives such as ui_keyboard or ui_click, nor does it state when not to use this 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?
With no annotations, the description carries full burden. It only states the primary action, adding a symbol, but does not disclose any behavioral traits such as duplicate handling, watchlist selection context, or potential side effects. This is insufficient for a mutation tool.
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, front-loaded with the action, and contains no unnecessary wording. It is a model of conciseness.
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 one-parameter tool, the description is adequate but leaves gaps such as how to target a specific watchlist, what happens on duplicates, and whether the operation is reversible. No output schema is present, so return values are not explained. Overall, it meets the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'symbol' parameter, including examples. The description itself adds no additional parameter information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a symbol') and the resource ('TradingView watchlist'), with 'a symbol' implying singular operation, distinguishing it from sibling watchlist_add_bulk. The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like watchlist_add_bulk or watchlist_remove. There is no mention of prerequisites, limitations, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the export action and target, but does not disclose whether existing files are overwritten, whether directories are created, what the return value is, or any prerequisites. This lacks critical side-effect 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?
The description is a single concise sentence, front-loaded with the verb and resource. Every word contributes to the core meaning, with no redundancy or 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 tool is simple (one optional param, no enums), but there is no output schema and no annotations. The description covers the basic action and target, but it does not explain what the tool returns (e.g., success message or file path) or any prerequisites. This is minimally adequate but leaves notable gaps.
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 100% coverage for the single parameter (file_path), so the baseline is 3. The description does not add any additional parameter-level meaning; it omits any mention of the parameter entirely. The schema already explains the parameter and default, so the description adds no extra value here.
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 ('Export'), the object ('the current watchlist'), and the output ('to a JSON file on disk'). This distinguishes it from sibling tools like watchlist_get or watchlist_import, which have different verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that watchlist_get might be used for in-memory retrieval, or that watchlist_import is the inverse. No exclusions or contextual cues are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the action ('Remove') but does not mention what happens if the symbol is not present, whether the operation is permanent, or any side effects. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and immediately conveys the tool's purpose.
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 single-parameter tool with no output schema, the description is minimally adequate. However, it lacks a note about using watchlist_remove_bulk for multiple removals, which would improve completeness given the sibling context.
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% with the parameter 'symbol' described as 'Symbol to remove (e.g., AAPL)'. The tool description adds little beyond the schema, but the baseline of 3 is appropriate since the schema already fully documents the parameter.
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 symbol from the TradingView watchlist' uses a specific verb ('Remove') and a clear resource ('symbol from the TradingView watchlist'). It distinguishes itself from sibling tools like watchlist_remove_bulk by mentioning a single symbol.
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 like watchlist_remove_bulk for removing multiple symbols. There is no mention of exclusions, prerequisites, or recommended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Run an action' without revealing iterative behavior, delays, state cleanup, or error handling. The restore_start_state and delay_ms parameters imply important side effects that the description does not surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the core purpose. It is concise and free of filler or redundant content.
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 full parameter schema coverage, the tool is a complex batch orchestrator with 7 parameters and no output schema or annotations. The description does not explain the execution flow, cleanup behavior, or how it relates to same-purpose siblings like strategy_sweep, leaving significant gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'symbols and/or timeframes' maps directly to the symbols and timeframes parameters, but it adds no extra semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and clearly identifies the resource ('an action across multiple symbols and/or timeframes'). It distinguishes the tool from single-symbol/timeframe siblings by emphasizing multi-symbol iteration.
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 a clear use case—execute an action for many symbols or timeframes—but does not explicitly state when to use this tool over alternatives like data_get_ohlcv or capture_screenshot. There are no when-not-to-use caveats or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior (retrieving date and bars ranges) and implies a read-only operation through the verb 'Get.' However, it omits specifics such as whether unix timestamps are in seconds or milliseconds, whether the bars range is inclusive, and whether the returned values are in a particular format. These gaps limit the agent's ability to anticipate the exact output.
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 tool's purpose without any redundant phrasing. Every word contributes to the meaning, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must fully explain what the agent can expect. It states the two key pieces of data (date range and bars range) but does not describe the return structure, such as whether it is an object with specific field names. This ambiguity could lead to incorrect assumptions about the response format, making it only minimally 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 tool has zero parameters, and the schema coverage is 100% by default. The description does not need to explain parameter meanings since none exist. The baseline of 4 is appropriate here because there is no parameter information to add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and specifies the resource as 'visible date range (unix timestamps) and bars range on the chart.' This clearly conveys the tool's function as a getter for chart visible range data. It implicitly differentiates from sibling tools like chart_set_visible_range (which sets) and chart_scroll_to_date (which scrolls), though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what it does, with no context about typical use cases, prerequisites, or exclusions. For example, it does not mention that this tool is useful for capturing the current view before making changes or that it should be used instead of chart_get_state for range-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It indicates a mutating action ('Change') but does not mention potential side effects, idempotency, or whether the chart must be loaded or active. This is a significant gap for a tool with no annotation support.
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 redundancy. It is front-loaded with the core action, efficient, and easily parsed. However, it could be slightly more informative without sacrificing brevity, so it does not earn a 5.
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 tool is simple with one well-documented parameter, so the minimal description is somewhat adequate. However, there are no annotations and no output schema, and the description does not mention any prerequisites (e.g., chart must be open) or confirm the absence of return values. For a mutating tool in a large sibling set, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single parameter 'timeframe' with examples (1, 5, 15, 60, D, W, M), and schema coverage is 100%. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Change the chart timeframe/resolution'. It uses a specific verb ('Change') and resource ('chart'), and the object (timeframe/resolution) distinguishes it from sibling tools like chart_set_symbol or chart_set_type. The 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?
The description implies usage (when you want to alter the chart's timeframe), but it provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It is minimally adequate but lacks clear context for when to invoke it among related chart tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'List' and 'bounded pagination,' which largely mirrors the schema's limit/offset fields. It does not mention side effects, return structure, or any caveats, leaving the agent without essential context for a read 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 concise sentence that front-loads the primary action and object. Every word earns its place, with no filler or redundant information.
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 tool is simple, but with no output schema and no annotations, the description should provide more context about expected results. It does not indicate what fields will be returned, how layouts are identified, or ordering behavior, leaving the agent partially uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33%, with only include_details described. The tool description provides no parameter-level detail, failing to compensate for the gap. The phrase 'bounded pagination' hints at limit/offset but does not explain their semantics or defaults.
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 ('List') and identifies the resource ('saved chart layouts'), making the tool's function immediately clear. It also adds 'with bounded pagination,' which distinguishes it from related tools like layout_switch that perform a different operation.
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 guidance is given on when to use this tool versus alternatives. The usage is implied by the verb 'List,' but there is no mention of exclusions or when to prefer another tool such as layout_switch or chart_get_state.
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?
Without annotations, the description carries the burden of behavioral disclosure. It does list four main actions (detect button, compile, check errors, report study changes), which gives some transparency. However, it lacks detail on what 'detects button' entails, what happens on compilation errors, or whether it modifies any state beyond the report.
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 concise sentence, front-loaded with the core action ('Intelligent compile') and followed by a compact list of secondary actions. No unnecessary words or redundant details.
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 no parameters, the description covers the main functional steps, but it leaves key aspects unexplained: what 'detects button' refers to, what 'reports study changes' means, and whether this tool is preferred over standard compile. More context would help the agent select and invoke it correctly.
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 input schema is empty and the description need not explain any parameters. Baseline is 4 per the rubric, and the description does not attempt to add parameter information beyond what is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a compile operation with extra intelligence ('detects button, compiles, checks errors, reports study changes'). It distinguishes itself from plain compile tools by listing a multi-step workflow, though the phrase 'detects button' is vague and could be more explicit about what button is detected.
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 explicit guidance on when to use this tool versus alternatives like pine_compile or pine_check. The word 'intelligent' implies it is a more comprehensive version, but no direct comparison or exclusion criteria are given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that a snapshot is restored but does not mention that the current chart state will be overwritten, whether the operation is reversible, or error behavior for missing snapshots. This is a significant gap for a mutation-like 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, well-structured sentence that is front-loaded with the action verb and resource. No unnecessary words or repetition.
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 one-parameter tool, the description adequately conveys the core purpose and parameter. However, it could be more complete by noting that restoring overwrites the current chart state or how to find valid snapshot names, though the absence of an output schema and the tool's simplicity reduce the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'name', describing it as 'Snapshot name to restore'. The description adds no additional semantic context beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restore') and the resource ('previously saved chart state snapshot by name'). It distinguishes itself from sibling tools like state_snapshot, state_list, and state_delete by specifying the restore operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., snapshot must exist) or contrast with state_snapshot/state_list/state_delete, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state what happens with an invalid index, whether the tab must already exist, or any side effects of switching. This is a significant gap for a mutating UI 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, clearly worded sentence with no wasted words. It is appropriately concise, though it could include a bit more context without becoming verbose.
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 well-described parameter and no output schema, the description plus schema is mostly sufficient. However, the description alone does not mention the need to use tab_list to obtain a valid index, which is a relevant contextual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'index' parameter has a description indicating it is 0-based and from tab_list). The tool description adds nothing beyond the schema, so it meets the baseline but does not enhance parameter understanding.
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 'Switch to a chart tab by index' uses a specific verb ('Switch'), identifies the resource ('chart tab'), and specifies the method ('by index'). This clearly distinguishes it from sibling tools like tab_new, tab_close, and tab_list.
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 'by index' implies the agent must have a tab index, likely obtained from tab_list, but the description does not explicitly state when to use this tool versus alternatives or mention any prerequisites. It offers implied guidance rather than explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool reports (Desktop version and missing capabilities) but does not mention whether it makes API calls that could fail, whether it requires specific permissions, whether any side effects occur, or what the output structure looks like. For a diagnostic tool, this lack of safety context is a notable gap.
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 and uses no filler. The first sentence orients the tool as a canary for critical APIs, and the second precisely states the output (version + missing capabilities). Every word earns its place; it is front-loaded and efficient.
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 tool with no parameters, no output schema, and no annotations, the description gives a fundamental sense of what it does. However, it leaves out important contextual details: it does not explain the format of the report, how to interpret results, or how it differs from closely related tools like tv_capability_matrix and tv_compatibility_snapshot. The term 'Canary' and 'TVControl' are jargon that may confuse an agent unfamiliar with the system.
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 has zero parameters, so the baseline is 4. The description does not need to explain parameters because there are none. It also makes sense that a compatibility check would take no input, relying on environment state. The description adds sufficient context about what the tool checks without needing parameter details.
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 is a 'Canary for critical TradingView internal APIs' and that it 'Reports the Desktop version and exactly which required capabilities are missing.' This gives a specific verb ('Reports') and resource (TradingView internal APIs / TVControl). It is distinct enough from siblings like tv_health_check, but does not explicitly differentiate from tv_capability_matrix or tv_compatibility_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 'Canary' implies it is used as an early check for compatibility before using TVControl, but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternative tools for compatibility checks, leaving the choice among tv_compatibility_check, tv_capability_matrix, and tv_compatibility_snapshot ambiguous.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, error handling, or return value. For a destructive delete operation, the lack of such context is a notable gap.
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, focused sentence that immediately conveys the action and scope. There is no redundant wording or unnecessary detail, making it highly concise and well-structured.
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 low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It does not explain the response/error behavior or differentiate from 'alert_delete', which would be valuable context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter alert_id is already documented as 'Alert ID from alert_list'. The description adds no extra meaning beyond this, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a single alert by ID' uses a specific verb (Delete) and resource (alert), and explicitly notes both 'single' and 'by ID'. This clearly distinguishes it from the sibling tool 'alert_delete', which likely handles batch or filter-based deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the parameter description 'Alert ID from alert_list' suggests a workflow of listing alerts first. However, the description does not explicitly state when to use this tool versus the sibling 'alert_delete', nor does it provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only restates the basic action without disclosing side effects, reversibility, return values, or whether any prior conditions are needed. 'Zoom' implies a view change, but it adds little beyond the name and schema.
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 conveys the core action efficiently. Every word is necessary and no redundant information is present.
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 tool has only two simple parameters and no output schema, so the description is mostly sufficient. However, it lacks any mention of behavioral context (e.g., side effects) and does not differentiate itself from chart_scroll_to_date, making it slightly incomplete for an agent choosing among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented as 'Start of range' and 'End of range' in unix timestamps. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Zoom the chart to a specific date range (unix timestamps)'. It uses a specific verb ('Zoom') and resource ('chart'), and the scope ('specific date range') distinguishes it from related tools like chart_scroll_to_date and chart_get_visible_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to set the visible range, but it does not explicitly state when to use it versus alternatives like chart_scroll_to_date or chart_get_visible_range. No when-not or alternative tools are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the removal action but does not disclose irreversibility, possible side effects (e.g., chart redraw), error behavior for invalid IDs, or any prerequisites like an open chart. This is a significant gap for a destructive 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, front-loaded sentence with no filler. Every word 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?
The tool is simple with a fully described parameter, but the absence of annotations and any behavioral detail (e.g., error handling, undo possibility) makes this minimally complete. It covers what it does but not the full context a careful agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter (entity_id) has a description indicating it comes from draw_list. The description adds no extra param details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove'), resource ('drawing'), and method ('by entity ID'). It clearly distinguishes from siblings like draw_clear (which likely clears all drawings) and draw_list (which lists them).
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 does not explicitly mention alternatives or when-not-to-use. However, the schema's parameter description ('from draw_list') implies you should first list drawings to obtain the entity ID, providing some usage context. No explicit exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the action but does not disclose potential side effects, failure modes (e.g., no match found), whether the indicator is added to the active chart, or any authentication requirements. The mention of types (built-in, strategy, community, saved) adds context, but important behavioral details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and the target. Every word contributes to understanding the tool's purpose. No filler or redundancy.
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 relatively simple tool with three parameters and no output schema, the description provides a basic understanding. However, it lacks specifics about what happens after adding (e.g., does it open the dialog, require a chart), how the 'match' parameter interacts with 'query', or the behavior when multiple matches exist. These gaps are notable, but the description is adequate for a basic use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'matching' and result types, but it does not add substantive meaning beyond the schema. The schema already documents query, match, and section with clear descriptions, so the description neither enhances nor compensates for parameter understanding.
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: 'Search the TradingView Indicators dialog and add a matching built-in, strategy, community, or saved study'. It specifies the action (search and add), the resource (TradingView Indicators dialog), and the scope (built-in, strategy, community, saved study), which distinguishes it from sibling tools like indicator_search (search only) and chart_manage_indicator (manage added indicators).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: adding an indicator by searching. However, it does not explicitly state when to use this tool versus alternatives like indicator_search (which only searches without adding) or chart_manage_indicator (manages existing indicators). No exclusions or prerequisites are mentioned, leaving the guidance 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and requirements. It merely states the action without mentioning possible side effects (e.g., chart refresh), validation behavior, or what happens if the entity_id is invalid. The lack of any behavioral context beyond the mutation itself is a significant gap for a mutating tool.
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, front-loading the verb and object. It includes useful examples without unnecessary verbosity. Every word contributes to understanding the tool's core function.
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 2-parameter mutation tool with no output schema, the description captures the core action but leaves out important operational context such as prerequisite indicator existence, error behavior, or reversibility. While the low complexity doesn't demand extensive detail, the absence of annotations raises the bar for completeness, which this description only partially meets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions, including the JSON format for 'inputs' and the source of 'entity_id'. The description adds modest value by giving examples of input keys, but this is largely redundant with the schema's example. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and the target ('indicator/study input values') with concrete examples ('length, source, period'). This unambiguously differentiates it from sibling tools like chart_manage_indicator or indicator_toggle_visibility, which handle indicator lifecycle and visibility rather than input parameter modifications.
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 adjusting study inputs, and the required entity_id from chart_get_state in the schema suggests a prerequisite. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any constraints like the indicator needing to exist or how to obtain the entity_id beyond the schema hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects, error behavior, or prerequisites like existence of the layout. The lack of any safety/caveat disclosure makes it insufficient.
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?
A single clear sentence with no redundant words; highly concise and front-loaded.
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 one-parameter switch tool, the description is minimal but adequate in isolation. However, given the existence of closely related sibling tools (layout_list, pane_set_layout, tab_switch) and lack of annotations or output schema, it does not fully help an agent understand when to pick this over alternatives or what happens after switching.
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 already fully documents the single parameter with 100% coverage; the description's 'by name or ID' adds no additional semantic information 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 uses a specific verb ('Switch to') and resource ('saved chart layout'), clearly indicating it changes the current layout to a saved one. It distinguishes from siblings like layout_list (listing) and pane_set_layout (pane-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 implies the tool is used when you want to change to a saved chart layout, but it does not mention alternatives like layout_list for discovering layouts or pane_set_layout for pane layouts, nor any exclusions. No explicit when-to-use 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain what happens on success/failure, whether the script is loaded into the editor, or any side effects or prerequisites, leaving a significant transparency gap.
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 of seven words that front-loads the action and object. It contains no unnecessary words or repetition, making it optimally concise.
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 tool is simple with one fully documented parameter, and the description adequately states the core action. However, the lack of annotations and output schema means the description does not convey the operational outcome, potential errors, or any special behavior, leaving it only minimally 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?
The input schema already provides 100% coverage of the single parameter 'name', including the case-insensitive matching detail. The description adds no additional parameter semantics beyond what the schema documents, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') with a clear resource ('saved Pine Script') and the means of identification ('by name'), effectively distinguishing it from sibling tools like pine_new, pine_save, and pine_get_source.
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 intended usage is implied—opening an existing saved script by name—but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The context is clear but limited.
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?
With no annotations provided, the description carries the full burden. It proactively discloses that a non-blank symbol causes a temporary chart switch, serializes concurrent calls, and restores the original chart. This is valuable beyond what the schema explains. It does not cover all possible side effects (e.g., errors, rate limits), but the key structural behavior is transparent.
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: first states the purpose, second packs the critical side effects. Every word earns its place, with no filler or repetition. It is front-loaded and appropriately sized for a simple one-parameter 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?
The tool is simple with one parameter and no output schema, but the description does not explain what data is actually returned (e.g., bid, ask, volume). Since there is no output schema to fill that gap, the description should provide some indication of the response structure. The side effects are well-documented, but the return value is left ambiguous, making the description slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage of the 'symbol' parameter, including the blank-means-current-chart behavior. The description adds one extra detail not in the schema—serialization of concurrent calls—which is useful. However, most of the description's parameter-related content is redundant with the schema, so it only marginally exceeds the baseline.
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 'Get quote data' with a specific verb and resource, making the core purpose evident. It also adds a distinguishing behavioral note about temporary chart switching, which differentiates it from generic data tools. However, 'quote data' is somewhat broad and does not explicitly contrast with siblings like symbol_info, so it's not a perfect 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?
No explicit guidance is given on when to use this tool vs alternatives. The behavioral note about symbol changes is useful but does not address selection criteria, prerequisites, or exclusions. An agent must infer usage context solely from the phrase 'Get quote data'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It explains the step increment ('one bar') but omits important details such as whether replay must be active, what happens if called outside replay mode, or any side effects on the chart view.
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 redundant words. It efficiently conveys the action and resource, fitting the simple nature of the 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?
The description is minimally sufficient for a parameterless step action, but it lacks contextual details about replay state requirements and how it fits into the broader replay workflow. Given the simplicity of the tool, it is adequate but not rich.
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 input schema is empty, so there is no parameter semantics to explain. The baseline score of 4 applies because the schema coverage is trivially complete and the description needs no compensation.
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 ('Advance') and the resource ('one bar in replay mode'), making the tool's purpose specific and unambiguous. It also distinguishes from siblings like replay_autoplay by emphasizing the manual single-bar step.
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 such as replay_autoplay or replay_stop. It does not mention any prerequisites like replay mode being active or the expected context for invocation.
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?
Without annotations, the description discloses the scope of state captured (symbol, timeframe, studies, drawings, visible range) and that it writes to a named file. However, it does not describe behavior when a snapshot with the same name exists (despite overwrite parameter in schema) or any potential errors.
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?
A single, focused sentence that is front-loaded with the action and lists included components without 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 explains the tool's basic function and scope, but lacks a pointer to companion tools like state_restore and does not clarify the outcome when a snapshot already exists without overwrite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about what is captured but does not elaborate on the 'name' or 'overwrite' parameters 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 uses a specific verb 'Capture' with a clear resource 'full chart state' and destination 'named snapshot file', listing included elements (symbol, timeframe, studies, drawings, visible range). This distinguishes it from siblings like state_restore and state_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus state_restore or state_list. The context is implied by the verb 'Capture', but there is no mention of alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention whether closing the tab discards unsaved work, whether it is reversible, or how 'current' is determined. For a potentially destructive action, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target. No unnecessary words 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?
For a simple zero-parameter tool, the description covers the basic purpose but lacks context about edge cases (e.g., closing the last tab, behavior with unsaved data). Given no annotations or output schema, some additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not elaborate on parameter semantics. The baseline of 4 applies, and the description does not introduce confusion.
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 resource ('current chart tab'), clearly distinguishing it from sibling tools like tab_new, tab_switch, and tab_list. It unambiguously states the operation performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions (e.g., last tab, unsaved changes) or offer alternatives like tab_switch or tab_new. Usage context is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions auto-detection of install location, but omits significant behavioral traits such as side effects (killing existing instances may discard unsaved state), what happens if TradingView is already running, or what the tool returns. The kill_existing warning is only in the schema, not the tool description.
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 exactly two sentences, front-loaded with the primary action and resource, and includes only necessary detail. No filler 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?
For a launcher tool, the core purpose is clear, but the description lacks context about behavior when an instance already exists, return values, and prerequisites like port availability. With no annotations or output schema, a bit more guidance would make it more 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?
The input schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds nothing about parameters, but that's acceptable because the schema already documents them 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 launches TradingView Desktop with Chrome DevTools Protocol enabled, using a specific verb and resource. It naturally distinguishes itself from siblings like tv_health_check or tv_update by describing the launch process, and adds cross-platform auto-detection detail.
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 this is the entry point for launching TradingView with CDP, but it does not explicitly say when to use it relative to other tools, such as 'run before tv_health_check' or 'only if not already running.' No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Take a screenshot' implies a non-destructive read operation, but it does not explain what happens to the image (e.g., saved to disk, returned as base64), whether it blocks until complete, or how the wait_for_render parameter affects the outcome. This is a significant gap for an agent invoking the tool.
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 unnecessary words. It conveys the core action efficiently and is easy to parse.
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 no output schema and no annotations, the description leaves out critical details such as return format, file saving behavior, and potential side effects. For a tool with four parameters and a rendering wait option, more context is needed for an agent to fully understand the tool's impact and output.
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 describes all four parameters (method, region, filename, wait_for_render) with clear descriptions, giving 100% coverage. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'take' with a clear resource 'screenshot of the TradingView chart'. It clearly distinguishes from sibling tools like chart_get_state (state reading) and chart_vision_read (visual analysis), which are not capture tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended usage obvious: use this tool to capture a chart screenshot. No exclusions or alternatives are mentioned, but since no other sibling tool serves this exact purpose, the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only states a list operation, which implies a read-only action, but it does not disclose what information is returned, whether the list is sorted, or any potential side effects. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully conveys the tool's purpose without any waste. It is front-loaded and appropriately sized for a simple list operation.
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 (no parameters, no output schema), the description is mostly sufficient. However, lacking an output schema, it would benefit from clarifying what the list contains (e.g., script names, IDs). For a simple list tool, this is a minor gap, so a 4 is reasonable.
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 all parameter schemas are trivially covered. The description adds no parameter-specific meaning, but with no parameters to document, a baseline score of 4 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 verb "List" and the resource "saved Pine Scripts", making the tool's purpose unambiguous. It distinguishes itself from sibling Pine Script tools like pine_get_source, pine_save, and pine_compile, which focus on other operations.
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, nor any exclusions or prerequisites. Usage is only implied by the tool name and description, but no explicit context is given relative to the many sibling Pine Script tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only query but does not explicitly state that it has no side effects, nor does it describe return format or any caveats. The examples give some idea but fall short of full behavioral disclosure.
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 efficient sentence, front-loaded with the main verb and object. It wastes no words and is easily scannable.
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 it is a simple no-parameter getter without an output schema, the description provides sufficient conceptual detail about what is returned (panels, buttons, visibility/enabled state). While it might not enumerate every UI element, it is adequate for a tool of this simplicity.
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 0 parameters, so the baseline is 4. The description does not need to explain parameters, and the schema is empty, leaving no ambiguity.
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 what the tool does: 'Get current UI state' and specifies the scope by listing examples (panels, buttons, enabled/disabled states). This is a specific verb+resource and distinguishes it from chart_get_state or tv_health_check, which cover other aspects.
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 on when to use this tool versus alternatives. It does not mention exclusions or indicate whether to use it over ui_find_element or other UI inspection tools. The agent is left to infer usage from the purpose, which is not explicit enough.
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?
With no annotations, the description must convey behavior. 'Click at specific x,y coordinates' accurately states the core action, but it does not disclose potential side effects like window activation, whether a synthetic event is used, or how out-of-bounds coordinates are handled. This is adequate but not rich.
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 is front-loaded and immediately communicates the 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?
For a simple click action with fully documented parameters, the description is largely sufficient. It is missing usage context relative to sibling tools and any prerequisites, but the core operation is clear and uncomplicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all four parameters, including enums and defaults. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (click), the precise target (TradingView window), and the method (specific x,y coordinates). This clearly differentiates it from sibling tools like ui_click, which likely operates on elements rather than raw coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as ui_click or ui_hover. There is no mention of prerequisites (e.g., window must be visible/focused) or coordinate system details beyond what the schema supplies.
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?
The description states the action but does not disclose potential side effects, permanence, or whether the action is undoable. Since no annotations are provided, the description carries the full burden, and for a destructive clear-all operation, more transparency (e.g., 'this cannot be undone') would be valuable.
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 zero wasted words. It states exactly what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless mutation tool, the description adequately covers the operation. It clearly indicates scope ('all drawings') and requires no additional 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?
The tool has zero parameters, so the schema coverage is trivially 100%. Baseline 4 is appropriate; the description does not need to explain 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 'Remove all drawings from the chart' uses a specific verb ('Remove') and resource ('all drawings from the chart'), clearly distinguishing it from sibling tools like draw_remove_one (which removes a single drawing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not explicitly say 'use this to clear all drawings at once' or 'do not use this for individual removals', leaving the agent to infer from the name compared to draw_remove_one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get properties and points', which implies a read-only operation, but it does not disclose behavior such as whether the drawing must exist, what happens on invalid ID, or if any state changes occur. The lack of explicit safety or error context leaves transparency 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?
The description is a single, clear sentence that efficiently conveys the tool's purpose. Every word contributes value, and it is front-loaded with the action verb.
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 one-parameter getter, this is minimally viable. However, without an output schema, the description does not specify what 'properties and points' include, nor how they are structured. It could mention return format or error behavior, but given the tool's simplicity, the current level is acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter entity_id, with a description that says 'Entity ID of the drawing (from draw_list)'. The tool description adds no additional parameter semantics beyond that. Since the schema fully documents the parameter, 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 ('Get') and the specific resource ('properties and points of a specific drawing'). It distinguishes itself from siblings like draw_list (which lists drawings) and draw_remove_one (which removes) by focusing on a single drawing's data.
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?
Though the description itself doesn't explicitly mention alternatives, the parameter schema instructs that entity_id comes from draw_list, providing a clear prerequisite. The context of sibling tools makes the intended usage obvious: use draw_list to obtain an ID, then this tool to fetch its details. No exclusions are stated, but the guidance is sufficient for a simple getter.
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 adds the source 'Monaco markers,' which provides context beyond the name. However, with no annotations, it does not disclose whether this is a read-only operation, whether it requires a prior compile, or what happens if no errors exist. The word 'Get' implies safety but is not explicit.
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. It is concise and free of unnecessary words, perfectly sized for the tool's simplicity.
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 clear but incomplete due to the lack of an output schema. It does not mention the return format (e.g., an array of error strings or structured objects), which is significant for an agent deciding how to use the result. The overall simplicity of the tool keeps it from being a lower score.
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 trivially covers 100%. Per the baseline for 0-parameter tools, the description does not need to elaborate on parameters, and it adds no contradictions.
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 Pine Script compilation errors from Monaco markers. It distinguishes from sibling tools like pine_get_console and pine_compile by specifying the exact source and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., after compilation) or when not to use it, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool toggles autoplay and optionally sets speed, but it does not specify the effect of the toggle (e.g., whether it starts or stops playback, or the current state dependence). This is acceptable for a simple toggle but lacks deeper behavioral details.
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?
A single, front-loaded sentence that communicates the action and optional adjustment. Every word is informative, and there is no redundancy or 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 tool with one optional parameter and no output schema, the description is minimally adequate. It does not mention how to check the current autoplay state (e.g., via replay_status) or any dependencies, but given the low complexity, this is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the speed parameter fully documented including valid values and unit. The description adds no extra meaning beyond restating that speed can be set optionally, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Toggle') and names the resource ('autoplay in replay mode'), clearly distinguishing it from sibling tools like replay_step or replay_start. The optional speed setting is also mentioned, fully capturing the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for enabling/disabling autoplay in replay mode, but it does not explicitly state when to use it over alternatives or provide exclusions. There is no guidance on prerequisites like being in replay mode first, which is a gap for a tool with many replay-related 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a safe read operation via 'get', but does not describe what the returned status looks like, whether it can fail, or any side effects. It is minimally transparent.
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, front-loaded sentence with no filler words. It clearly communicates the tool's function in just six words.
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?
This is a simple getter with no parameters and no output schema. The description is adequate for the core function but omits information about the return value format or possible statuses, which would be useful given the output schema is absent.
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 input schema is empty. The baseline score of 4 applies, as there is nothing to document and the description adds no parameter information.
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 'get' with a resource 'replay mode status', clearly indicating this tool queries the current replay mode state. It distinguishes from sibling tools like replay_start, replay_stop, and replay_step, which are actions rather than status queries.
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. It does not mention whether it should be called before starting replay, or how it relates to replay_autoplay or other replay tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and does not reveal what happens after execution, whether it requires an active replay session, what side effects occur on position state, or potential errors. This is a significant transparency gap for a mutation-like tool.
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, front-loaded with the core verb 'Execute' and resource 'trade action in replay mode'. It contains no filler and every phrase earns its place, including the parenthetical list of actions.
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 tool with one parameter and no output schema, the description conveys the core purpose adequately. However, it omits important context such as the requirement for an active replay session and the outcome of the trade action, leaving some gaps for the agent to infer. More detail 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 schema already provides 100% coverage for the single 'action' parameter with a description listing buy, sell, close. The tool description repeats the same values without adding new meaning, so it meets the baseline but does not enhance 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's function: 'Execute a trade action in replay mode' and explicitly lists the allowed actions (buy, sell, or close position). It distinguishes itself from replay control siblings like replay_start and replay_step by focusing on trade execution, not replay navigation.
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 establishes clear usage context: this is for trade actions during replay mode. It implies the tool is used when the user wants to simulate a trade in a replay session. However, it does not explicitly exclude alternatives or mention prerequisites (e.g., replay must be active), so it lacks the full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention side effects (e.g., whether the new tab becomes active, whether an existing TradingView session is required), permissions, or what happens when no layout is specified. For a tool that creates a tab, these details are important for successful invocation.
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 immediately states the main purpose and the optional capability. There is no redundant information or extraneous detail, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers the core action and optional layout loading. However, it lacks context about prerequisites (e.g., must TradingView be open?) and any expected behavior or return values. Since there is no output schema, some additional context would improve completeness, but the tool is relatively straightforward and the description is minimally 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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it simply restates that a saved layout can be optionally loaded. The parameter descriptions in the schema already explain the values for 'layout' and the role of 'name'. Thus, the description adds minimal value here.
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 and resource: 'Open a new TradingView tab'. It also specifies the optional behavior of loading a saved layout. This differentiates it from sibling tools like tab_switch and tab_list, which handle switching and listing tabs, respectively.
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 for when to use the tool: to open a new tab. It does not explicitly mention alternatives or exclusions, but the purpose is straightforward and the optional layout parameter implies flexibility. The phrase 'Open a new' naturally implies this is not for switching or listing tabs, though it could be more 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?
No annotations are provided, so the description carries the transparency burden. It discloses that baselines are immutable and that results are reported separately for critical failures and informational drift. However, it does not explain state-changing behavior (e.g., whether 'record' persists data, side effects, or reversibility), which is important for a tool with a 'record' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately convey the tool's core function and a key reporting distinction. No filler or repetitive content; every phrase 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?
The description adequately covers the high-level purpose but lacks details on expected return values, output structure, or when the 'overwrite' flag matters. Given the absence of an output schema, the description could be more complete about what 'reported separately' means in practice, though the tool is relatively simple with only two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('action' and 'overwrite'), with clear descriptions in the schema. The tool description adds no additional parameter-level detail beyond what the schema already provides, so a baseline score 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 tool records, compares, or lists immutable per-version TradingView API compatibility baselines, using specific verbs and resource. It distinguishes itself from siblings like tv_compatibility_check and tv_capability_matrix by emphasizing the snapshot/immutability aspect and separate reporting of critical failures vs informational drift.
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 its usage for recording, comparing, or listing baselines, but provides no explicit guidance on when to choose this over related tools like tv_compatibility_check or tv_capability_matrix. There are no clear exclusions or alternatives mentioned, so the agent must infer the appropriate context.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose an important behavioral trait: removal of 'identifiers, source code, URLs, titles, and secret-like values'. However, it does not explain what the bundle actually contains (beyond what is removed), whether it is returned as a file or path, or any side effects. The claim of 'compressed' adds some detail but lacks specifics.
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, focused sentence that leads with the action and resource, and immediately conveys the key privacy attribute. There is no wasted text or repetition. It is appropriately sized for a tool with one optional parameter.
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 has one optional parameter with good schema documentation and no output schema, the description is adequate but leaves gaps. It explains the purpose and a key behavioral aspect (privacy-safe), but does not describe what the resulting bundle looks like, how it is delivered, or any additional context needed to use the tool effectively. The lack of output schema means the description should have explained the return format, but it remains silent.
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%, with the single parameter 'telemetry_lines' documented as 'Recent bounded telemetry records to include (default 100)'. The description does not mention this parameter at all, but the schema already provides full semantics. Since coverage is high, a baseline of 3 is appropriate; the description adds no additional parameter meaning.
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: 'Create a privacy-safe compressed diagnostics bundle'. It uses the specific verb 'Create' and identifies the resource as a diagnostics bundle, with the added scope of privacy-safe removal of sensitive data. This distinguishes it from sibling tools like tv_health_check or tv_watchdog_sample, which focus on health checks or watchdog sampling rather than bundle creation.
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 support/diagnostics via the phrase 'diagnostics bundle', but it does not explicitly state when to use this tool versus alternatives. There is no exclusion guidance or mention of alternative tools. The context of 'privacy-safe' hints at scenarios where sensitive data must be redacted, but this is not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states that it stops the watchdog, but does not mention idempotency, what happens if the watchdog is not running, or any side effects. The addition of 'in-process' clarifies scope but not behavioral consequences.
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, focused sentence that directly conveys the tool's purpose with no unnecessary words or repetition. It earns its place by being maximally concise.
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 tool is simple (no parameters, no output schema), but the description lacks information about return behavior or edge cases like calling stop when the watchdog is already stopped. While not necessary for trivial operations, the absence of any behavioral caveats leaves a small gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully coverage. Baseline for 0 params is 4, and the description does not need to elaborate on parameters. It adds no irrelevant parameter information.
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 ('Stop') and clearly identifies the resource ('the in-process health watchdog'), making it unambiguous and distinct from sibling tools like tv_watchdog_start and tv_watchdog_status.
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 wording implies usage as the counterpart to tv_watchdog_start, but it does not explicitly state when to use or not use this tool, nor does it mention alternatives. The context provides some implicit guidance, but no explicit exclusion or preference.
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?
With no annotations, the description carries full burden. It clearly implies a read-only operation via the verb 'Get', which is a behavioral disclosure, but it does not mention potential errors (e.g., no chart open), performance characteristics, or side effects. For a zero-parameter getter, this is adequate but not rich.
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 element (resource and fields) earns its place, making it highly efficient and scannable.
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 low complexity (no parameters, no output schema), the description covers the key return values at a high level. However, it does not state whether the chart must be open or whether indicator details include settings/how they are returned, leaving minor ambiguity for invocation contexts.
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 no parameter syntax is needed. The description adds value by conceptually defining what the returned state includes (symbol, timeframe, chart type, indicators), which helps the agent interpret results even without an output 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?
Description uses a specific verb ('Get') and resource ('current chart state') and enumerates the returned fields (symbol, timeframe, chart type, indicators). This clearly distinguishes it from sibling setter tools like chart_set_symbol and chart_set_timeframe, and from the more specific chart_get_visible_range.
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 explicit guidance on when to use this tool versus alternatives. It implies a read operation, but does not differentiate from other getter tools such as tv_ui_state or chart_get_visible_range, nor does it give context like 'use when you need current chart settings before modifying them'.
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?
No annotations are provided, so the description must fully disclose behavior. It states that the chart view is centered on a date, implying a view mutation, but does not detail edge cases, prerequisites, or whether the visible range is adjusted. For a simple navigation action, this provides some transparency but lacks depth.
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 unnecessary words, perfectly concise.
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 low complexity (1 parameter, no output schema), the description sufficiently explains the tool's function. It could benefit from noting prerequisites or behavior relative to sibling tools but is adequate for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'date' is fully documented in the schema with formats (ISO string or unix timestamp). The description does not add additional information about parameter semantics, so it meets the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'jump' and 'center' with the resource 'chart view', clearly indicating the action of navigating to a date. This distinguishes it from other chart_* tools like chart_set_symbol or chart_set_timeframe.
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 when the user wants to navigate the chart to a specific date but does not explicitly mention alternatives or exclusions. Context from sibling tools (e.g., chart_set_visible_range) might help but is not referenced in the description.
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?
No annotations are provided, so the description carries the full burden. It clearly identifies the operation as reading (non-mutating) and describes the output as 'text and price pairs'. However, it does not disclose edge cases like empty results, behavior when study_filter matches nothing, or whether it requires a chart with loaded indicators. The behavior is adequately but not richly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and resource, and includes a practical usage hint. No wasted words.
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 read-only tool with three simple optional parameters and no output schema, the description provides enough context: it states purpose, return format, and how to target specific indicators. It could mention what happens when no labels are found or clarify multi-study behavior, but overall it is reasonably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with clear descriptions (verbose, max_labels, study_filter), and the schema description coverage is 100%. The description mentions study_filter but adds no new meaning beyond the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 'Read' and names the exact resource: 'text labels drawn by Pine Script indicators (label.new)'. It also states the return format ('text and price pairs'), which distinguishes it from sibling tools like data_get_pine_lines and data_get_pine_boxes.
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 a usage hint: 'Use study_filter to target a specific indicator.' This implies the tool can read from all indicators when no filter is applied. However, it does not explicitly contrast with alternatives such as data_get_pine_lines or data_get_indicator, so while context is present, exclusions or alternative selection guidance are missing.
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?
With no annotations provided, the description carries the full behavioral burden. It uses the verb 'Read', which implies a non-destructive, read-only operation, but it does not disclose whether the tool returns a single string, a list, or whether it requires a prior compilation or open console. It lacks explicit statements about side effects, auth requirements, or failure modes, leaving the agent with only partial information.
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 states the main action and resource, followed by parenthetical examples. Every element earns its place, with no wasted words or redundant information. It is appropriately sized for a zero-parameter read tool.
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, zero-parameter read-only tool, the description is mostly complete. It clearly names the output types (compile messages, log.info(), errors). However, without an output schema, it does not specify the exact return shape (e.g., raw string vs. array of messages), which would be helpful. Still, given the tool's low complexity, this is a minor gap.
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 is 4. The description does not need to explain parameter semantics, and the schema's empty properties object confirms there are none. No additional meaning is required.
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 ('Read') and resource ('Pine Script console/log output') and gives concrete examples of content (compile messages, log.info(), errors). It clearly distinguishes from siblings like pine_get_errors (which likely returns only errors) and pine_get_source (which returns source code), making the tool's purpose unambiguous.
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 such as pine_get_errors or pine_compile. The description implies it is for reading console output, but it does not explicitly state prerequisites, whether it should be called after compilation, or which scenarios would warrant using a different tool. This is a clear gap.
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?
With no annotations, the description carries the full burden. It states the primary behavior (starting replay mode) and mentions the optional date, but does not disclose side effects, state changes, or requirements like having a chart open. This is acceptable for a simple mode-toggle tool but lacks depth.
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 of nine words, front-loaded with the action verb 'Start' and the resource. Every word earns its place, with no redundant 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 one optional parameter and no output schema, the description is mostly complete. It covers the primary function and the optional parameter. It does not place the tool within the replay workflow (e.g., suggesting replay_step for advancing), but that is not essential for executing the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional 'date' parameter, which is fully documented. The description's mention of 'optionally at a specific date' merely reiterates the schema, adding no extra semantic value beyond the structured data.
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 'Start' with a clear resource 'bar replay mode', distinguishing it from siblings like replay_stop, replay_status, and replay_step. It unambiguously states the tool's function.
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 (entering replay mode) but does not explicitly contrast with siblings such as replay_autoplay, replay_step, or replay_trade, nor does it state prerequisites or follow-up actions. It provides only implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool is a reporting/inspection operation, implying a read-only nature, but it does not explicitly confirm safety, potential side effects, or response structure. The description is not contradictory but adds limited behavioral context beyond the functional statement.
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 11 words in a single sentence, immediately stating the tool's purpose. Each word contributes to the meaning, with no filler or redundant phrasing.
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 simplicity—no parameters and no annotations—the description sufficiently communicates the core function. It could be enhanced by explicitly stating the return format, but for a discovery report, the purpose is clear enough to be considered largely 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 is empty with zero parameters, so the description has no need to explain parameter semantics. According to the rubric, zero-parameter tools receive a baseline of 4; the description does not need to compensate for missing parameter details.
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 the specific verb 'Report' and identifies the resource as 'known TradingView API paths', including the detail that it covers their availability and methods. This clearly distinguishes it from siblings like tv_health_check or tv_compatibility_check, which focus on health and compatibility.
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 tv_health_check or tv_capability_matrix, nor does it mention any exclusions or prerequisites. It simply states the action without contextual recommendations.
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?
With no annotations, the description carries the full burden. It states the action and that positions are returned, but it does not disclose whether the operation is read-only, what happens if no element is found, or whether it returns the first match or all matches. The provided behavior is basic but not misleading.
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 wasted words. It efficiently conveys the tool's purpose and outcome.
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 (2 params, no nested objects) and the absence of an output schema, the description adequately indicates the return value ('positions'). However, it could be more complete by specifying whether multiple matches are returned or how positions are formatted, but this is a minor gap for such a straightforward 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% since both parameters (query and strategy) have descriptions in the schema. The description adds little beyond the schema—it restates that the query can be text, aria-label, or CSS, which the schema already details. No additional semantic value is provided.
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 'Find' with a clear resource 'UI elements' and specifies search methods (text, aria-label, CSS selector) and the outcome (return positions). This clearly distinguishes it from sibling tools like ui_click or ui_hover, which perform actions rather than locating 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 the tool is used to locate UI elements before interaction, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The context of sibling tools suggests a pre-interaction step, but the description itself provides no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and the 'active' filter, which implies a read-only operation, but it does not explicitly mention that it is non-destructive, nor does it describe the output format or any limitations. This is minimal but not misleading.
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 exceptionally concise—just three words—with every word contributing meaning. It is front-loaded and free of any wasted text, embodying ideal conciseness for a simple 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?
Given the tool's low complexity (zero parameters, no output schema), the description is adequate for basic understanding. However, it does not clarify what constitutes an 'active' alert, what fields are returned, or whether there are any pagination or sorting defaults. It is sufficient for a simple list but leaves minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description adds contextual meaning by specifying 'active alerts', which scopes the listing operation. There are no parameter details needed since the schema is already empty and complete.
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 'List active alerts' clearly states the operation (list) and the resource (active alerts), distinguishing it from sibling tools like alert_create and alert_delete that handle alert mutations. The specific scope 'active alerts' adds precision.
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 retrieving current alerts, but it does not explicitly state when to use this tool versus alternatives such as alert_create or alert_delete. No when-not-to-use or alternative guidance is provided, leaving the usage context implied by the verb and resource.
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?
No annotations are provided, so the description carries the burden. It discloses the return mode behavior (inline image vs file_path based on max_image_bytes) and implicitly signals a read-only operation via 'read'. It does not discuss permissions or error cases, but the core behavioral trait is covered.
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, then a concise note on return behavior. No filler or redundancy.
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 explain return values more thoroughly. It explains the image mode but does not describe the structure or format of the other returned data (quote, indicator, OHLCV). For a tool that aggregates many data types, this is a notable gap, though the core behavior is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra parameter meaning: the parenthetical list of content types aligns with the 'include' parameter, and the max_image_bytes threshold is already described in the schema ('Exceeded → file_only mode'). No new parameter context is provided.
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: 'Take a screenshot and read all chart data in one call' and enumerates the content types (quote, indicator, Pine graphics, OHLCV). This distinguishes it from sibling tools like capture_screenshot or individual data_get_* tools.
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 'in one call' implies a convenience aggregator, suggesting when to use it, but there is no explicit guidance on when not to use it or how it compares to alternatives like capture_screenshot plus data_get_* tools. Usage context is inferred, not 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?
No annotations are provided, so the description carries the burden of disclosing behavior. It indicates a read-only 'get' operation, which is helpful, but it does not mention return format, potential empty results, or side effects. It adds some context ('current', 'visible', 'data window') but not deep 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?
The description is a single, front-loaded sentence that clearly states the action and scope. It includes useful examples in parentheses without being verbose. Every word adds value, making it highly concise and well-structured.
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, zero-parameter getter, the description covers the main purpose but lacks return value details. Since there is no output schema, the description should ideally explain the shape or type of 'indicator values' returned. It is adequate but not fully complete for an agent that needs to know how to consume the result.
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 baseline for 0 params is 4. There is no parameter documentation needed, and the description correctly focuses on the output behavior rather than input details.
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 'Get' and clearly identifies the resource ('current indicator values from the data window') and scope ('all visible studies'). It also lists examples (RSI, MACD, Bollinger Bands, EMAs) and distinguishes from sibling tools by emphasizing 'all visible studies' versus single-indicator tools.
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: use this when you need values for all visible studies. However, it does not explicitly state when to prefer this over alternatives like data_get_indicator, nor does it provide exclusions. The context is clear but not reinforced with alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry transparency. It does disclose one behavioral requirement (entity_id needed when multiple strategies loaded), but omits details like return format, error behavior, or any side effects. This is a minimal disclosure, hence a middle score.
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 primary purpose. The second sentence adds a necessary usage condition. No redundant or filler content.
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 getter with one optional parameter and full schema coverage, the description is largely sufficient. It lacks an explicit statement about output structure, but the tool name and first sentence strongly imply the return value is the equity curve. Slight gap due to no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already thoroughly describes entity_id with exact instructions and recommendation. The description's mention of entity_id adds no new information beyond the schema. With 100% schema coverage, baseline is 3.
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: 'Get equity curve data from Strategy Tester' – a specific verb, resource, and source. This distinguishes it from sibling data tools like data_get_trades and data_get_strategy_results.
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 context for the entity_id parameter: 'Pass entity_id when more than one strategy is loaded.' This clarifies when to supply the parameter, though it does not explicitly name alternatives or state when NOT to use this tool. Still, the guidance is useful and situational.
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?
With no annotations, the description carries the full burden. It states the tool retrieves order book data from the chart, indicating it is a read-only operation tied to the chart's context. It does not detail the return structure or number of levels, but for a simple getter this is adequate.
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 is informative.
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 and no output schema, the description provides the essential information that the tool retrieves order book/DOM data from the chart. It could be marginally richer (e.g., mentioning that it reflects the current chart symbol), but it is sufficient for a tool of this simplicity.
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 is empty, so the baseline is 4. The description adds no parameter semantics, but no parameters exist to document.
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 'Get' and clearly identifies the resource as 'order book / DOM (Depth of Market) data'. This distinguishes it from sibling data tools like data_get_trades and quote_get.
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 guidance or alternative tool comparisons are provided. However, the description's specificity implies it should be used when order book depth data is needed, giving an implied usage context.
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?
With no annotations, the description must carry the burden of disclosing behavior. 'List' clearly implies a read-only operation, but it does not disclose the return format (e.g., IDs vs. full objects), whether hidden drawings are included, or any chart-state dependence.
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 is clear and free of unnecessary detail. It is front-loaded and earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description covers the core functionality. However, it could mention the return value or that it provides handles for other draw tools, so it is not maximally 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 tool has 0 parameters, so the baseline is 4. The description does not need to add parameter meaning since there are none. It correctly focuses on what the tool returns.
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 'List all shapes/drawings on the chart' uses a specific verb ('List') and resource ('shapes/drawings'), clearly distinguishing itself from sibling tools like draw_shape (create), draw_clear (clear), and draw_remove_one (remove). It explicitly scopes to the chart.
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 need to enumerate drawings, but it does not explicitly state when to use this tool versus alternatives like draw_get_properties or other list tools. No when-not-to-use guidance is provided.
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?
No annotations are provided, so the description carries the responsibility for behavioral disclosure. It clearly states what is returned (symbols and active state) and implies a read-only, side-effect-free operation. However, it does not address edge cases such as behavior when no panes exist or whether hidden panes are included. For a simple list tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action 'List', and contains no filler. Every word contributes to the meaning, making it highly concise and well-structured.
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, read-only list tool with no output schema, the description sufficiently captures the purpose and return content. It lacks explicit edge-case details, but given the tool's simplicity, it is complete enough for successful 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 accepts zero parameters and the schema is an empty object. With no parameters to describe, the baseline score of 4 applies. The description adds no parameter-specific information because there are none.
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 'List', identifies the resource 'chart panes', and specifies the scope 'current layout' plus the included details 'symbols and active state'. This clearly distinguishes it from sibling tools like tab_list (tabs) and layout_list (layouts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this is the appropriate tool for enumerating panes as opposed to using chart_get_state. The description only states what it does, leaving usage context entirely implicit.
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?
No annotations are provided, so the description carries the full burden. It states the primary operation ('Get...source code') and context ('from the editor'), which clearly is a read-only operation, but it does not disclose edge cases such as behavior when no editor is open or whether the tool can return errors.
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 wasted words. It states the action and resource precisely, making it exceptionally concise.
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, no-output-schema tool, the description is adequate. It identifies the source ('from the editor') and the action ('Get'), which is sufficient for a simple getter. It does not explicitly mention the return value, but that is strongly implied by 'Get source code'.
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 input schema has no properties, so the baseline is 4. The description does not need to explain parameters since there are none.
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 ('Get') and resource ('current Pine Script source code from the editor'), clearly distinguishing it from siblings like pine_set_source (which writes) and pine_compile (which compiles). There is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading the active editor's Pine Script source, but it does not explicitly state when to use this tool versus alternatives. There are no exclusions or prerequisites mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior, but it only restates the action 'Save' without explaining side effects (e.g., overwrite, file location, success indication). The Ctrl+S shortcut is a minor addition but does not address what happens upon save.
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, front-loaded with the key information. Every word earns its place, and no extraneous details are present.
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 simplicity (no parameters, no output schema), the description sufficiently conveys the action. It could mention whether saving triggers a download or writes to a specific location, but in the TradingView context, 'Save the current Pine Script' is an adequate and complete description for an editor save operation.
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 input schema fully covers parameter semantics. The description adds no parameter details but none are needed; baseline for 0 params 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?
The description uses a specific verb 'Save' with an explicit resource 'current Pine Script', making the tool's purpose unmistakable. It distinguishes from sibling tools like pine_get_source and pine_set_source, as none of them perform a save 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 clearly implies usage when you want to persist the current Pine Script, matching the tool's name. It does not explicitly mention alternatives or exclusions, but the context is clear given the sibling tools focus on getting/setting/compiling rather than saving.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. The term 'toggle' implies the tool switches between fullscreen and windowed states, but the description does not mention potential side effects, preconditions, or failure modes. Since the behavior is self-contained and reversible, a moderate score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence containing only the essential action. It is front-loaded and free of filler, scoring high on 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 the tool's simplicity (no parameters, no output schema, no annotations), the one-sentence description covers the core action adequately. However, it leaves some ambiguity about the exact state change and whether any feedback is provided, so it is not fully 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 tool has zero parameters, and the schema is empty with 100% coverage (vacuous). The description does not need to elaborate on parameters, and it introduces no confusing parameter-related information, earning the baseline score of 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?
The description 'Toggle TradingView fullscreen mode' uses a specific verb ('toggle') and a resource ('TradingView fullscreen mode'), clearly expressing the tool's function. No sibling tool references fullscreen, so it is easily distinguishable.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. However, because it is a unique toggle with no siblings performing this action, the usage context is implicitly understood, warranting a mid-range score.
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?
With no annotations, the description carries the burden of disclosure. It usefully reveals sequential execution and per-symbol reporting, but omits details like failure handling, idempotency, or result format, leaving room for ambiguity.
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?
Single sentence, front-loaded with verb and scope, zero filler. Every word contributes meaning.
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 bulk add tool with one parameter and no output schema, the description provides enough context: action, scope, sequence, and result reporting. Lacks an example or detailed result format, but is mostly sufficient.
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 covers 100% of parameters with a clear description ('Symbols to add'). The tool description adds minimal extra meaning, confirming the array is for multiple symbols but not enriching 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 identifies the action (add), the resource (multiple symbols to watchlist), and the bulk scope, distinguishing it from watchlist_add and watchlist_remove_bulk.
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 'multiple symbols' which provides clear context for when to use this tool (bulk vs single add). No explicit exclusions or alternatives are named, but the implication is strong enough from the sibling names.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does explain the return content (last price, change, change%) but omits important traits such as behavior on an empty watchlist, whether the TradingView app must be open, or how 'current' is determined. This is adequate but has clear 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?
The description is a single, front-loaded sentence that directly states the action and result. There is no wasted wording or redundant information, making it concise and well-structured.
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 (no parameters, no output schema), the description covers the essential return values and the data source. It lacks an explicit response structure, but for a simple getter the information is reasonably complete. It could be improved by specifying the output format or potential empty-state behavior.
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 schema provides no param details. According to the rules, a baseline of 4 applies when there are no parameters, and the description does not need to compensate for missing 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 clearly states the tool retrieves all symbols from the TradingView watchlist and specifies the included data fields (last price, change, change%). This distinguishes it from mutating watchlist tools like watchlist_add/watchlist_remove and other data-getting tools.
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 implicitly conveys this tool is for reading watchlist data, but it does not explicitly state when to use it instead of alternatives like watchlist_export or symbol_search. No exclusions or alternative recommendations are provided, leaving usage context implied 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?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It implies a non-mutating, read-only operation by using 'Get', and it lists what is returned. However, it does not mention possible failure states (e.g., if no symbol is currently set), error handling, or side effects. The behavior is mostly clear but not fully 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, well-structured sentence that front-loads the action and resource, with no filler or repetition. It earns every word.
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 getter, the description is complete: it states what the tool does (get metadata) and what to expect (name, exchange, type, description). There is no output schema, but the description enumerates the key return fields, making the tool's purpose and output clear.
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 accepts zero parameters, so the baseline is 4. There is no parameter info needed in the description, and the schema already reflects that no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('detailed metadata about the current symbol'). It enumerates the included fields (name, exchange, type, description), which distinguishes it from sibling tools like symbol_search (which searches) and chart_set_symbol (which changes the chart's symbol).
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 context is implied: it is a read-only getter for the current symbol. However, it does not explicitly compare with alternatives like symbol_search or chart_get_state, nor does it mention when not to use it. There is no guidance on when to prefer this tool over others.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It appropriately discloses that the tool is read-only, which is crucial safety information, and adds context about sample coalescing and state-only persistence. This goes beyond a bare 'start' command and helps the agent understand expected 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 extremely concise and efficient—two sentences with no filler. It front-loads the primary purpose and then adds essential behavioral detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), the absence of an output schema, and the presence of related sibling tools, the description is complete. It tells the agent what the tool does, that it's safe (read-only), and how it behaves (coalescing, state transitions). No critical information is missing for correct invocation.
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 description covers the single parameter (interval_ms) at 100%, so the baseline is 3. The description does not add any additional parameter-specific details, but the schema already provides the necessary semantics (range, default, and purpose).
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 ('Start') and the specific resource ('the read-only in-process health watchdog'), which distinguishes it from related sibling tools like tv_watchdog_stop, tv_watchdog_status, tv_watchdog_sample, and tv_watchdog_history. The purpose is unambiguous and immediately understood.
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 (to start the watchdog) but does not explicitly contrast it with alternatives like tv_health_check or provide scenarios for when to use vs. not use. It lacks clear when-to-use or when-not-to-use guidance, so it falls at the 'implied usage' level.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does reveal that summary=true returns 'compact stats instead of all bars' and that using it 'saves context,' which is a significant behavioral trait. However, it does not describe other behaviors such as return format, potential errors, or the fact that it might be a read-only operation. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—one sentence plus a targeted tip. It front-loads the core purpose and immediately follows with actionable guidance. No wasted words or irrelevant details.
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 two well-documented parameters and no output schema, the description is mostly complete. It covers what the tool does and offers advice on a key parameter. However, it could be more complete by mentioning what the output looks like (e.g., a list of OHLCV bars) or clarifying that it reads from the currently active chart, but these are somewhat implied. Good overall.
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?
Both parameters are already fully described in the schema (count with range and default, summary with details about what it returns). The description adds practical value by emphasizing the context-saving benefit of summary=true, which goes beyond the schema's 'much smaller output' wording. This enhances the agent's ability to choose the right parameter mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Get OHLCV bar data from the chart.' This distinguishes it from sibling data tools like data_get_indicator or data_get_trades, as it specifically targets OHLCV bars. No ambiguity.
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 useful context on how to use the tool, specifically recommending summary=true for compact stats to save context. However, it does not explicitly mention when to use this tool versus alternative data retrieval tools, though the purpose makes the primary use case clear. It lacks 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?
With no annotations provided, the description carries the behavioral disclosure burden. It states the read-only nature ('Read'), the deduplication behavior, and the return format ({high, low} price zones). It does not cover edge cases like empty results or error conditions, but it provides solid transparency for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary verb 'Read'. It avoids redundancy and every sentence contributes meaningful information: what it reads, what it returns, and how to filter.
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 2-parameter read tool with no output schema or annotations, the description is sufficiently complete. It covers purpose, return type, deduplication, and filtering. It does not mention sorting or empty-result behavior, but these are not critical for task selection. The sibling context confirms this is part of a family of data_get tools, and the description clearly differentiates the box focus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters fully (verbose and study_filter). The description adds a brief note to use study_filter for targeting an indicator, which slightly reinforces the schema's existing description. Since schema coverage is 100%, the description does not need to compensate, and it adds only marginal semantic value 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 uses the explicit verb 'Read' and identifies the resource as 'box/zone boundaries drawn by Pine Script indicators (box.new)', making it clear this tool is for reading box objects. It also clarifies the output as deduplicated {high, low} price zones, which distinguishes it from sibling tools like data_get_pine_lines (lines) and data_get_pine_labels (labels).
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 concrete usage context: it is for reading box zones and mentions the study_filter parameter to target a specific indicator. However, it does not explicitly name alternatives or say when not to use this tool, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states the read-only nature ('Read') and discloses the deduplication behavior and per-study grouping. It stops short of detailing edge cases (e.g., empty results, filtering of only horizontal lines), but the core non-obvious behavior is transparent.
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 three short sentences, each earning its place: purpose, key output behavior, and a parameter usage tip. It is front-loaded with the verb and resource, with no fluff or repetition.
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 simplicity (2 optional params, no output schema), the description covers the essential behavior and filtering. It does not detail the exact return format (e.g., array of objects with study names), but the schema and description together provide enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a brief usage hint for study_filter ('Use study_filter to target a specific indicator') but does not explain verbose or add semantic depth beyond what the schema provides. This is adequate but not extra informative.
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 states a specific verb ('Read') and resource ('horizontal price levels drawn by Pine Script indicators (line.new)'), clearly distinguishing it from sibling tools like data_get_pine_labels, data_get_pine_tables, and data_get_pine_boxes. The mention of 'deduplicated price levels per study' further refines the purpose.
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 on what the tool does and how to target a specific indicator via study_filter. However, it does not explicitly name alternatives or exclusions, e.g., 'use data_get_study_values for time-series data', so the guidance is clear but not exclusionary.
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?
No annotations are provided, so the description carries the full burden. It discloses the side effects: 'Auto-opens Strategy Tester and unhides the selected strategy so TradingView computes its report.' This is a meaningful behavioral disclosure beyond a simple read. It does not mention return format or potential errors, but the side effect is the most critical behavioral trait.
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 exactly two sentences, front-loaded with the main purpose. The first sentence states what the tool does; the second gives a conditional parameter hint and the all-important side effect. Every sentence 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 one optional parameter and no output schema, the description covers the essential context: what it retrieves, when to pass the parameter, and the side effect of opening the Strategy Tester. It might benefit from hinting at the nature of the returned metrics, but the tool is simple enough that this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the entity_id parameter with a detailed description including where to get it and when it is recommended. The tool description adds the same advice ('Pass entity_id when more than one strategy is loaded') but does not introduce new semantics. With 100% schema coverage, the 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 opens with 'Get strategy performance metrics', which clearly states the verb and resource (strategy performance report). It distinguishes from sibling tools like data_get_trades and data_get_equity by focusing on the Strategy Tester report. The context about entity_id and auto-opening the Strategy Tester further clarifies the tool's unique role.
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 concrete usage guidance: 'Pass entity_id when more than one strategy is loaded.' It also explains that the tool auto-opens the Strategy Tester and unhides the strategy, which informs the user of prerequisite behavior. However, it does not explicitly name alternatives or state when not to use this tool, so it stays at 4.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the side effect: 'Auto-opens Strategy Tester and unhides the selected strategy.' This is valuable transparency for a tool that might otherwise appear purely read-only. It does not disclose any other potential side effects or permission requirements, but it covers the most significant 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 concise, consisting of two sentences, and front-loads the core purpose. Each sentence adds essential information: what the tool does, when to pass entity_id, and the side effect. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with no output schema, and the description covers the main function and a key side effect. However, it does not specify prerequisites like whether at least one strategy must be loaded, or what happens if no strategy is available. This is a minor gap but not critical for understanding the tool's primary use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already fully documents both parameters. The description adds no new parameter meaning beyond what the schema provides (e.g., the schema already says entity_id is 'Strongly recommended when more than one strategy is loaded'). Thus, the 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 tool's purpose: 'Get the most recent strategy orders.' The verb 'get' and resource 'strategy orders' are specific, distinguishing it from sibling tools like data_get_strategy_results. The additional detail about opening the Strategy Tester further differentiates it.
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 for when to pass entity_id: 'Pass entity_id when more than one strategy is loaded.' This is helpful usage guidance. However, it does not explicitly state when this tool should be used over alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the responsibility of disclosing behavior. It clearly states that the tool does not compile, works offline, and catches specific error types. However, it does not describe the return value or output format, leaving some ambiguity about how results are presented to the caller.
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 concise, with two sentences that front-load the core purpose and then add a key operational detail (offline, no connection). Every word contributes value, with no redundancy or irrelevant 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?
For a single-parameter tool with no output schema and no annotations, the description provides a solid understanding of the tool's function, behavior, and use case. It could be more complete by specifying the return format or providing an example, but given the tool's simplicity, it covers the essentials well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a full description for the sole parameter 'source' ('Pine Script source code to analyze'), giving 100% schema coverage. The tool description adds context about the analysis itself but does not add new parameter-specific meaning beyond the schema, matching the baseline for high 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 clearly states a specific action ('Run static analysis on Pine Script code') with concrete detection categories (e.g., array out-of-bounds, unguarded array.first()/last()). It explicitly distinguishes from compilation ('WITHOUT compiling') and indicates offline operation, setting it apart from sibling tools like pine_compile.
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 this tool: for static analysis without compiling, with the added benefit of working offline and requiring no TradingView connection. It implies that compilation is not needed, but does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that compilation happens remotely via the server API and that errors/warnings are returned. It also implies a non-destructive validation action. It does not mention side effects, but the nature of compilation makes this less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core function, and the second provides the return value and a use case. No redundant words or 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?
Given the tool's simplicity (one parameter, no output schema), the description is largely complete. It explains the action, the return, and the use case. It could optionally mention what happens on successful compilation, but that is not essential for correct invocation.
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 already describes the single parameter 'source' as the Pine Script source code. The description adds no new detail about the parameter's format or constraints. With 100% schema coverage, the 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 tool's specific action: compiling Pine Script via TradingView's server API. It also distinguishes itself from sibling tools by noting that the chart doesn't need to be open, and it indicates the output (compilation errors/warnings). This goes beyond a vague purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: validating code before injecting it into the chart. This implies when to use the tool, though it does not explicitly mention alternative tools or exclusion scenarios. The guidance is sufficient for basic selection.
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?
With no annotations, the description carries the full burden. It discloses a non-obvious behavioral trait: removal is sequential. It also states that per-symbol results are reported, which hints at possibly partial success. This goes beyond the schema and name, though it could elaborate on failure handling or what happens when a symbol is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('Remove multiple symbols'), contains zero filler, and conveys the key facts: multiple, sequential, and per-symbol reporting. It is concise and well-structured.
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 low complexity (one array parameter, no output schema), the description adequately covers the essential operation and its behavioral nuances (sequential, per-symbol results). It does not need to detail return format or edge cases, though a mention of the 100-item limit could slightly enhance 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?
Schema coverage is 100%: the only parameter 'symbols' has a description 'Symbols to remove'. The tool description adds context about sequential processing and per-symbol results, but does not add significant semantic detail beyond what the schema already provides for the parameter itself.
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' with a clear resource ('multiple symbols') and differentiates from sibling watchlist_remove by emphasizing bulk and sequential processing. It also adds 'report per-symbol results', which uniquely describes this tool's scope.
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 phrase 'multiple symbols' and the tool name 'watchlist_remove_bulk' clearly imply this is for batch removal, contrasting with the singular sibling watchlist_remove. However, it does not explicitly state 'use this instead of watchlist_remove when removing more than one symbol' or mention any exclusions, so it misses the explicit alternative guidance.
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?
No annotations are provided, so the description must disclose behavior. It explicitly states 'Read' (non-destructive), mentions the return format ('formatted text rows per table'), and indicates this is data from Pine Script tables. While it doesn't detail error cases or multi-table behavior, it adequately covers the core behavior for a simple read 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 two sentences, front-loaded with the primary action, and every clause adds value—purpose, output format, and filter guidance. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the essential aspects: what it does, return type, and filtering. It is complete enough for an agent to invoke correctly without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's 'Use study_filter to target a specific indicator' largely repeats the schema's 'Substring to match study name.' It adds minimal semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads table data drawn by Pine Script indicators (table.new) and returns formatted text rows per table. This distinguishes it from sibling tools like data_get_pine_lines, data_get_pine_labels, and data_get_pine_boxes, which target other drawing 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 provides clear usage context by specifying that study_filter targets a specific indicator, and the schema notes 'Omit for all.' It does not explicitly name alternative tools for other data types, but the purpose is self-evident given the tool name and 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?
No annotations are provided, so the description carries the full burden. It states the primary effect and result, but does not disclose edge cases (e.g., behavior if no replay is active) or side effects beyond the immediate action.
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 unnecessary words. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no params, no output schema, no annotations), the description is fully sufficient to understand its purpose and effect. It covers the required information 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 an empty input schema. Per the rubric, this warrants a baseline of 4 since there is no parameter meaning to add.
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 ('Stop'), identifies the resource ('replay'), and states the outcome ('return to realtime'). This clearly distinguishes it from sibling tools like replay_start and replay_step.
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 conveys when to use the tool: to exit replay mode and resume realtime data. While it does not explicitly mention alternatives or exclusions, the context is unambiguous for an agent.
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?
With no annotations provided, the description carries the full burden, and it does disclose key behavioral traits: it lists 'all' saved snapshots and the sort order ('by capture date'). This implicitly confirms it is a read-only operation. However, it does not explicitly mention the return format or error behavior, keeping it from a perfect score.
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, focused sentence with no wasted words. It leads with the verb 'List' and includes only essential information about scope and ordering.
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?
Despite lacking an output schema or annotations, the tool is simple and the description is sufficient for an agent to understand what it does and when to invoke it. It could be improved by specifying the return format (e.g., array of snapshot IDs), but overall it is complete enough given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema provides complete coverage. The description adds no parameter details, but since there are none, 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 'List' with a resource 'saved chart state snapshots' and adds detail about sorting by capture date. This clearly distinguishes it from sibling state_* tools like state_snapshot, state_restore, and state_delete.
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 when to use it (when you need to see saved snapshots), providing clear context without explicitly excluding alternatives. It does not state when not to use it, but for a simple list tool, the implied usage is sufficient.
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?
No annotations are provided, so the description carries the burden. It discloses that it refuses certain operations, implying the tool performs safety checks before proceeding. The emphasis on 'safely' and 'clean' communicates prerequisite condition awareness, though it does not describe return values or side effects beyond the update.
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 a clear main clause and a list of refusal conditions. Every word adds value, making it concise and 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 0-parameter tool with no output schema, the description covers the primary purpose, usage conditions, and safety behavior. It does not detail post-update state or how to interpret results, but this is a minimal gap given the tool's simplicity.
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 description cannot add parameter-specific meaning. The empty schema is sufficient, and the description focuses on behavior rather than inputs, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('fast-forward') and resource ('clean git checkout'), and specifies the source ('configured upstream'). It also differentiates by focusing on safe updates, which is distinct from other sibling tools that handle UI, data, or compatibility checks.
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 context: use when you want to safely update a git checkout, and it will refuse if certain unsafe conditions exist (package installs, untracked branches, dirty trees, diverged history). However, it does not explicitly name alternative tools or provide a clear 'when not to use' beyond the refusal conditions.
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?
With no annotations present, the description carries the transparency burden. It explicitly states 'read-only' (no mutations) and discloses persistence behavior: 'Persists only state transitions and never chart symbols, URLs, or account data.' This is a meaningful behavioral guarantee beyond the minimum. It could be enhanced by explaining what a 'health watchdog sample' entails or what triggers a state transition, but it still offers valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence: 'Run one read-only health watchdog sample. Persists only state transitions and never chart symbols, URLs, or account data.' (Technically two sentences, but extremely concise). Every clause adds relevant information without repetition or filler. It is front-loaded with the core action and then adds critical behavioral context.
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 tool with no output schema, the description provides sufficient context to understand the core function and key behavioral constraints. It does not explain what the sample returns or how to interpret the result, but given the simplicity and the absence of parameters, this is not a critical gap. The description could be slightly more explicit about the output, but it remains functionally complete for 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 is trivially 100% covered. The description does not need to explain parameters. The baseline of 4 for no-parameter tools applies here, as there is nothing to add 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 identifies a specific verb ('Run'), a resource ('health watchdog sample'), and a scope ('one', 'read-only'). It distinguishes itself from sibling tools like tv_watchdog_start and tv_watchdog_stop by emphasizing 'sample' as a one-off action. This is a precise, non-tautological statement of purpose.
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 context: using 'sample' suggests a one-off health check rather than continuous monitoring, which differentiates it from tv_watchdog_start. However, it does not explicitly mention alternatives or provide 'when not to use' guidance, so it falls short of a 5. The context is clear enough for an experienced agent to infer appropriate usage.
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?
With no annotations, the description carries the burden. 'List' signals a read-only operation, implying no side effects. It does not detail return format or pagination, but for a simple listing tool that is likely acceptable. The description is honest and not misleading.
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 perfectly captures the tool's function without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless listing tool with no output schema, the description is fully sufficient. It states what the tool returns (list of tabs) and is unambiguous.
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 rubric sets a baseline of 4 for zero-parameter tools. The description appropriately does not need to explain any parameters, and the schema is fully consistent with the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('all open TradingView chart tabs'). It is distinct from sibling tools like tab_new, tab_close, and tab_switch, which perform different actions.
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 when to use the tool (when you need to see all currently open charts). It does not provide explicit exclusions or alternative tool mentions, but the context is clear given the sibling tools and the straightforward nature of the listing operation.
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:

[![tvcontrol MCP server](https://glama.ai/mcp/servers/FerroxLabs/tvcontrol/badges/card.svg)](https://glama.ai/mcp/servers/FerroxLabs/tvcontrol)

Score Badge

Copy to your README.md:

[![tvcontrol MCP server](https://glama.ai/mcp/servers/FerroxLabs/tvcontrol/badges/score.svg)](https://glama.ai/mcp/servers/FerroxLabs/tvcontrol)

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/FerroxLabs/tvcontrol'

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