tradingview-mcp

by ezydubs

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: v1.0.0
Disambiguation3/5
Category prefixes like chart_, pine_, data_, and ui_ separate most tools, but there are several close pairs: ui_open_panel vs open_panel, pine_compile vs pine_smart_compile vs pine_check, and overlapping status/state tools like tv_health_check, get_status, chart_get_state, and tv_ui_state. Descriptions help, but an agent could still misselect among these similar-sounding actions.
Naming Consistency3/5
Most tools follow a clear {domain}_{action} pattern, especially chart_*, data_*, watchlist_*, pane_*, and tab_*. However, naming is not fully consistent: the trading group uses verb-first names like place_order and list_accounts, and there are isolated deviations like depth_get, quote_get, get_status, open_panel, and connect.
Tool Count1/5
With 97 tools, this is an extreme surface for any MCP agent, exceeding the 50+ threshold. Even though the TradingView domain is broad, many micro-tools like ui_keyboard, ui_hover, ui_scroll, and ui_mouse_click could be consolidated, making the set feel unwieldy rather than well-scoped.
Completeness4/5
The tool set is unusually comprehensive, covering chart control, Pine editing, data extraction, drawings, alerts, replay, indicators, watchlists, UI automation, panes, tabs, layouts, and broker trading. Minor lifecycle gaps exist—such as missing alert_update, layout_save/delete, drawing updates, and Pine script deletion—but they are workable and the core domain is covered.
Average 3.6/5 across 81 of 97 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 40 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only names the actions (add/remove) without revealing side effects, requirements (e.g., chart must be loaded), error behavior, or impact on existing indicators. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, crisp sentence that front-loads the core action and resource. It is appropriately concise and wastes no words, though it could be slightly more structured to mention the conditional parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (one with a JSON string, one with an enum) and no output schema, the description is far too thin. It does not explain what happens after a successful add/remove, whether the operation is idempotent, or how the inputs field interrelates with the action. An agent would need to infer critical details from the schema alone.
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 all parameters are individually described, including the enum for action and the conditional requirements for entity_id and indicator. The description itself adds no extra context beyond what the schema already provides, so it stays at the baseline expected for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Add or remove') and a specific resource ('indicator/study on the chart'), making the core purpose unambiguous. However, it does not explicitly distinguish itself from the sibling tool 'indicator_add', which likely performs a similar add operation, so it misses the opportunity to avoid confusion.
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 like indicator_add, indicator_remove, or indicator_toggle_visibility. The schema hints that entity_id is needed for remove and indicator is needed for add, but the description itself provides no context on selection criteria or 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?
There are no annotations and the description only says 'Change the chart symbol.' It implies mutation but discloses no side effects, prerequisites, permissions, reversibility, or what happens to the current 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the action and target. It contains no filler, though it is so minimal that it omits useful 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?
For a simple one-parameter setter, the description plus schema is minimally sufficient to invoke the tool. However, it lacks guidance on the active chart context, relationship to pane_set_symbol, and any behavioral expectations, leaving clear 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 single 'symbol' parameter with an example. The description adds no additional meaning beyond what the schema already provides, so 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 states a specific verb and resource: change the chart symbol. It is clear and distinguishable from chart_set_timeframe and chart_set_type, though it does not explicitly differentiate from close siblings like pane_set_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?
No guidance is given about when to use this tool versus alternatives such as symbol_search, symbol_info, or pane_set_symbol. The description provides no context for choosing this tool over its siblings.
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 behavioral disclosure burden. It only states that a chart type is changed, without disclosing that this modifies the active chart's state, whether it is reversible, any persistence or side effects, or what happens on failure. Minimal behavioral insight beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words with no wasted content and is front-loaded. It is efficient, though arguably too terse to carry the behavioral disclosure burden for a mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter the tool is mostly invokable with the well-documented parameter, but the description lacks explicit scope (active chart), return/confirmation behavior, or potential failure modes. Without annotations or an output schema, an agent gets only the bare minimum.
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 sole parameter chart_type is thoroughly documented with all valid values and the instruction to pass name or number. The description adds nothing 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Change chart type' uses a clear verb and specific resource. It distinguishes itself from sibling tools like chart_set_symbol and chart_set_timeframe by naming the chart type as the target. It could be slightly more specific about which chart is affected, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, no prerequisites, and no information about the target context (e.g., active chart). Usage must be inferred entirely from the tool name and sibling naming pattern.
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 behavioral traits. It only says 'close a position' without explaining whether it triggers a market order, how position identification works (position_id vs symbol), or what the response indicates. It also does not state any side effects or restrictions, making it 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.
Conciseness4/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 is concise and to the point, though it sacrifices depth for brevity. It earns its place by being clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a trading action with no output schema and no annotations, the description is significantly incomplete. It does not explain how to specify a partial close (qty), how to choose between position_id and symbol, what the return value indicates, or any prerequisites. An agent would need to rely entirely on the schema and guesswork 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 description coverage is 100%, and each parameter already has a descriptive comment (e.g., qty for partial close, symbol if position_id omitted). The description adds little beyond repeating the full/partial concept, which is already in the schema. It does not clarify relationships between parameters or provide extra context for usage.
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 (close) and the resource (a trading position), and notes the 'full or partial' scope. It is specific enough to distinguish from related tools like place_order or cancel_order, though it does not explicitly name alternatives. It is not a tautology and conveys the core 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?
There is no guidance on when to use this tool versus alternatives such as cancel_order or modify_order. The description does not mention any conditions, prerequisites, or differences from sibling tools, leaving the agent to infer the appropriate context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not explain what is actually returned, whether there are side effects, or how the response is structured. This is minimal but not wholly absent.
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, efficient sentence with no filler. It front-loads the key action and object, though it could have used the space to disambiguate from sibling tools 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 one-parameter getter, the description is marginally adequate, but it misses an explicit link to chart_get_state for obtaining the entity_id and does not clarify the distinction between indicator input values and computed study values. Given no output schema, the return format is also left unspecified.
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 entity_id parameter already documented as 'Study entity ID (from chart_get_state)'. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline 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 verb 'Get' and the resource 'indicator/study info and input values', making it easy to see this is a retrieval operation. However, it does not explicitly distinguish itself from the sibling data_get_study_values, which could overlap with 'study info' in an agent's mind.
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 data_get_study_values or data_get_ohlcv. The parameter description 'from chart_get_state' implies a prerequisite but the tool description itself lacks any 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 only says 'draw a shape/line on the chart,' offering no information about side effects, whether existing shapes are affected, how coordinates are interpreted, or what the tool returns. This is minimal behavioral transparency for a mutating drawing operation.
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 with no filler. It is appropriately sized for the simple purpose it states, though it sacrifices detail for brevity. It earns points for efficiency but is somewhat under-specified.
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 schema covers parameter semantics well, but the description omits conditional usage details such as point2 being required for trend_line and rectangle, and text being required for text shapes. With no output schema and no annotations, the description could have provided more context, but the schema does compensate for some 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?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning, but the schema already documents all five parameters, including shape types, point structure, and the style override format. No additional compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('draw') and resource ('on the chart'), identifying the core action of creating a shape or line. It does not explicitly distinguish itself from sibling drawing tools like draw_list, draw_remove_one, or draw_get_properties, but the verb and resource make the purpose reasonably clear.
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 such as draw_list, draw_remove_one, or draw_clear. The verb 'draw' implies creation, but there is no explicit context about when this is the right tool or when a sibling would be more 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, the description carries the burden of behavioral disclosure. It states the mutating action but does not say whether existing editor content is replaced, whether compilation is triggered, whether the source must be valid Pine Script, or how errors surface. 'Set/inject' is semantically clear but leaves side effects unspecified.
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 with no filler or repetition. It is efficient and easy to scan, though it is slightly under-specified in behavioral terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation tool, the description plus schema is nearly sufficient. However, missing caveats about overwriting behavior, editor state requirements, and follow-up compilation leave a small but relevant gap, especially within a large sibling tool family.
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 the sole 'source' parameter. The description adds little beyond the schema's own 'inject' language, so it earns the baseline score without contributing meaningful extra parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set') and the object ('Pine Script source code') with a specific target context ('in the editor'). It is distinguishable from read/compile/save siblings like pine_get_source, pine_compile, and pine_save, though it does not explicitly contrast with pine_save.
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 for when this tool should be used instead of alternatives such as pine_save, pine_compile, or pine_new. Prerequisites like having an editor open or whether source should be set before compiling are not 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 behavior disclosure, but it only says 'run an action' with no mention of iteration order, delays, error handling, side effects, or result aggregation. It omits whether execution stops on failure or continues per symbol, and whether the tool returns per-item results or a single summary. This is a significant gap for a batching wrapper.
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 single sentence is front-loaded, on-topic, and contains no wasted words, making it concise and easy to scan. However, the brevity skips behavioral details that the tool likely needs, so while the structure is good, it is not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, this description is incomplete. It does not explain how the batch loop behaves, what the return payload looks like, or how errors from individual symbols/timeframes are surfaced. An agent cannot predict the tool's full contract from this definition alone.
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%: every parameter (action, symbols, delay_ms, timeframes, ohlcv_count) has a description, so the schema already documents each field's meaning. The description only reinforces the symbols/timeframes components and does not add syntax, defaults, or cross-parameter relationships beyond the schema. Baseline 3 applies because the schema does the heavy lifting.
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 verb (run) and a specific resource ('an action across multiple symbols and/or timeframes'), which conveys the batching purpose without being a tautology. It distinguishes from siblings by emphasizing the multi-symbol/timeframe scope, though it does not explicitly name the allowed actions or contrasting single-action tools. The schema fills the action-list gap, so this is a minor omission.
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 that the tool should be used when the same action needs to be repeated over multiple symbols or timeframes. However, it does not explicitly contrast with single-action tools like data_get_ohlcv or capture_screenshot, nor does it provide when-not-to-use guidance or alternatives. The intended use is inferable but not clearly articulated.
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 reveal the core mutation—changing the chart's timeframe—but says nothing about side effects, whether the chart must already exist, how the change affects indicators or overlays, or what happens on failure. 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 short sentence with no filler, front-loading the verb and resource. It is appropriately sized for a tool with one parameter and low overall complexity.
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 setter, the core invocation is clear and the schema covers the input details. However, with no annotations and no output schema, the description omits useful contextual information such as prerequisites, expected outcome, and how this differs from related chart operations. It is 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 schema already provides a complete description of the single 'timeframe' parameter with examples, giving 100% schema coverage. The description adds only the synonym 'resolution' and no additional format, constraints, or domain guidance, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Change') and a specific resource ('the chart timeframe/resolution'), making the tool's purpose clear. It largely restates the tool name but adds 'resolution' as a synonym for timeframe. It does not explicitly differentiate it from sibling tools like chart_set_symbol or tv_launch, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as an active chart, and no indication of when a timeframe change is appropriate. The correct usage context is entirely left to the agent to infer.
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 must fully disclose behavior. It states the operation is to list accounts, which implies a read-only action, but it does not describe the return format (e.g., whether it returns account IDs, full details, or an array), nor does it mention any prerequisites like a prior connection. Given the absence of annotations, this is a significant gap for a tool that could carry subtle behaviors.
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 states the core action and the target resource efficiently. There is no waste, making it an example of concise, well-structured prose.
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-param tool with no output schema, the description is minimally adequate. However, it does not clarify what 'list' returns (e.g., a list of account identifiers vs. detailed objects) or whether it requires an active connection. Among the many sibling tools, it does not position itself against get_account or switch_account, leaving the agent to infer scope. Given the tool's simplicity, a score of 3 seems fair—it covers the basic purpose but misses contextual context an agent could 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 tool has zero parameters and the schema coverage is trivially 100%. The description adds no parameter-specific meaning, but none is needed. Baseline 3 is appropriate because 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 the verb 'List' and resource 'trading accounts' clearly. It is distinct from 'get_account' (which implies a single account) and 'switch_account', but it does not explicitly name these alternatives. The purpose is unambiguous and specific enough for an agent to understand the basic function.
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 its siblings like get_account, switch_account, or list_positions. The description only says 'for the connected broker,' which implies a prerequisite but does not explain when to choose list_accounts over other account-related tools. An agent would have 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the operation without detailing side effects, whether other panes are affected, what happens on invalid indices, or what the return value is. This is insufficient for an agent to anticipate the tool's behavior beyond the literal 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 concise sentence with no filler or redundant information. It effectively front-loads the action and target, making it quick 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 setter with only two required parameters and no output schema, the description is minimally viable. However, it lacks context about how the pane index should be obtained or validated, and does not mention any return value or confirmation, leaving minor but relevant 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?
Schema description coverage is 100%, so the parameter meanings are already fully documented in the schema: index is 'Pane index (0-based)' and symbol is 'Symbol to set (e.g., NQ1!, ES1!, AAPL)'. The description adds nothing beyond what the schema 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the symbol') and the target resource ('a specific pane by index'), making the core purpose obvious. However, it does not distinguish this from the sibling tool chart_set_symbol, which likely performs a similar symbol-setting operation at the chart level, so an agent could be unsure which to choose.
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 guidance is provided. The description does not say when to use pane_set_symbol versus chart_set_symbol, nor does it explain how to determine the appropriate pane index or any prerequisites such as listing panes first.
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 reveals the data source ('Monaco markers'), which implies reading editor state, but doesn't say whether the operation is read-only, whether a prior compilation is required, or what happens when no markers exist. No side effects or failure modes are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the verb and resource are front-loaded and every word earns its place.
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 getter with no parameters and no output schema, the description is minimal but leaves the agent to infer when compilation errors would exist, what the return format is, and how this fits into the pine workflow among roughly two dozen pine siblings. More context is needed for confident 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?
With zero parameters and vacuous 100% schema coverage, there is nothing for the description to document. It adds a bit of meaning by naming the source ('Monaco markers'), which clarifies what the parameterless call operates on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pairing ('Get Pine Script compilation errors') and names the data source ('Monaco markers'). It clearly indicates a read operation on editor markers rather than an action like pine_compile or pine_check, though it doesn't explicitly name or contrast any sibling.
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 call this tool versus the many related siblings (pine_compile, pine_check, pine_smart_compile, pine_analyze). There is no mention of prerequisites such as compiling first, no exclusions, and no alternatives named.
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 must carry the full burden of explaining behavior. It says 'Open' but does not disclose what happens when the script is opened, whether it replaces the current editor content, what error occurs if the name is not found, or what the return value looks like.
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 unnecessary filler. It front-loads the action and resource clearly.
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 low complexity with one required parameter, but the absence of annotations and an output schema leaves important context unspecified, such as the effect of opening a script and whether 'open' means loading it into the editor versus retrieving its content. This is 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 schema already describes the only parameter, 'name', including the case-insensitive matching detail, so the description adds little beyond echoing 'by name.' With 100% schema coverage, a 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 states a clear verb and resource: 'Open a saved Pine Script by name.' This is specific enough to distinguish basic intent from siblings like pine_save and pine_list_scripts, though it does not explicitly call out a sibling to contrast with.
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 related tools such as pine_get_source, pine_set_source, or pine_list_scripts. The description only states the action and the lookup key, with no context about prerequisites 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose an internal workflow (detect button, compile, check errors, report changes), which is useful, but it omits side effects, whether it modifies the script, what 'reports study changes' means, and what happens if compilation fails.
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 very short and front-loaded with the key action. It packs multiple behavioral points into a single sentence with no filler. The label 'Intelligent compile' is slightly redundant with the tool name, but the sentence remains 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 zero-parameter tool, the description gives a reasonable high-level picture: it compiles, checks for errors, and reports changes. However, with no output schema and no annotations, it still leaves important operational context unclear, such as what the reported output looks like and what conditions must be true before calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the empty schema is already complete and the description has no parameter details to add. The baseline of 4 applies here because no parameter documentation burden exists.
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 an action ('compiles') and a resource ('study'), and distinctively adds checking errors and reporting study changes. The phrase 'detects button' is somewhat odd and less precise, but the overall purpose is understandable and distinguishable from sibling tools like pine_set_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?
No guidance is provided about when to use this tool versus alternatives or about prerequisites such as having a Pine editor open or source code loaded. The description implies usage for compiling and checking a script, but it does not state contexts, exclusions, or related sibling 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 must carry full behavioral disclosure. It states it 'executes' a trade but does not clarify whether this is simulated or affects real positions, what side effects occur, or what the response contains. A mutation tool with zero annotation coverage should provide more context.
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?
One concise sentence with no waste. The core purpose is front-loaded, though it lacks additional detail that could be added in a structured way.
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 this is a trade-execution tool with no output schema and no annotations, the description is underspecified. It should mention whether replay mode is active or auto-started, how it interacts with existing positions, and any potential side effects. The minimal description leaves agents without enough context 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?
Schema description coverage is 100%—the parameter 'action' is fully documented with its possible values. The description adds no additional meaning beyond the schema, 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 tool executes a trade action in replay mode, with a specific verb and resource. It names the actions (buy, sell, close), and the 'replay mode' scope distinguishes it from siblings like replay_start/replay_stop and from real order tools.
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, such as place_order/close_position for live trading, or replay_start to begin a session. It does not mention prerequisites (e.g., must have an active replay session) 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 full responsibility for behavioral disclosure. It states that the active account is switched but does not mention that subsequent calls will use this account, whether the switch is persistent, or any side effects on open positions or orders. This is thin for a state-changing 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, and the essential action and target are immediately clear.
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 single-parameter tool with full schema coverage, the description is minimally adequate. However, because there are no annotations and no output schema, the agent is left to guess at side effects and return behavior, making it incomplete for a state-changing operation.
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 account_id is documented as 'Account id from list_accounts,' which correctly ties the parameter to a sibling tool. The tool description adds no further parameter detail, so 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 (switch) and the resource (active trading account), and identifies the key parameter (id). It is distinct from sibling tools like list_accounts and get_account, though it doesn't explicitly name them for contrast.
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 switch accounts, how this affects subsequent trading operations, or why a user might use this instead of get_account or list_accounts. The phrase 'active' implies context matters, but the description does not explain the implications.
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 alone must disclose behavior. It only says the tool searches by name or keyword, but does not mention return format, result count, no-match behavior, or whether it accepts partial matches. These gaps leave the agent guessing about the tool's runtime 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 a single clear, front-loaded sentence with no redundant words or filler. It communicates the core action and target in an efficient form.
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 full schema coverage, the description is minimally adequate for a basic invocation. However, it is incomplete for a no-output-schema tool because it does not describe what a successful search returns or how to distinguish this search from symbol_info.
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 properties 'query' and 'type' are already documented with examples. The description's phrase 'by name or keyword' loosely reinforces 'query' but adds little 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 uses a specific verb ('Search') with a clear resource ('symbols') and states the search basis ('by name or keyword'). It is distinct enough from sibling 'symbol_info' (which implies retrieving details) but does not explicitly call out that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as 'symbol_info' or 'tv_discover'. The description implies a search use case but does not state exclusions or conditions for choosing a sibling 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Click' without addressing side effects, waits, visibility requirements, failure behavior, or what happens if multiple elements match. For a UI automation tool this is a meaningful 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 concise sentence with no filler. Every phrase adds information about the tool's function or selector options, and it is 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 two-parameter action tool, the description plus schema captures the core invocation. However, it omits important operational context such as whether the element must be visible, what happens on failure, and how this relates to mouse-coordinate clicking. It is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, including the enum values for 'by'. The description essentially restates the selector strategies rather than adding new meaning. Baseline 3 is appropriate because the schema handles the heavy lifting.
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 ('Click') and the resource ('a UI element'), and specifies the selector strategies: aria-label, data-name, text content, or class substring. It does not explicitly distinguish ui_click from the sibling ui_mouse_click, but the selector-based approach gives useful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ui_mouse_click, ui_hover, or ui_find_element. There is no mention of prerequisites, fallback strategies, or contexts where selector-based clicking 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, the description carries the full burden of behavioral disclosure. It does not mention coordinate system details, viewport vs window coordinates, focus requirements, side effects of clicking, or whether the action performs a real OS-level click versus an internal UI event.
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 with no filler. It front-loads the essential action and target 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?
For a simple 4-parameter action, the description is mostly adequate, but it leaves out coordinate-system semantics and relation to ui_click. Given the low tool complexity and complete schema, this is acceptable but not fully self-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 coverage is 100%, so the schema already documents all four parameters. The description adds minimal semantic value beyond restating that x,y coordinates are used; it does not clarify coordinate origin, units, or interactions between button and double_click.
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 ('Click') and resource ('specific x,y coordinates on the TradingView window'). It is clear, though it does not explicitly distinguish itself from the sibling 'ui_click' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over alternatives like ui_click or ui_hover. The context implies coordinate-based clicking, but exclusions and alternatives are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses one explicit failure condition ('Fails if not logged in') but omits side effects, return value, idempotency, and whether this operation changes the connection state irreversibly.
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 specifying the action, target, and a key failure condition.
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: it names the action and a key failure mode. However, it does not state what a successful connection produces, whether it must precede other trading actions, or what 'currently selected' requires the agent to ensure beforehand.
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 the baseline is 4. The description does not need to clarify parameter semantics because there are none to clarify.
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 and resource pairing: 'Connect' + 'currently selected TradingView broker'. This distinguishes it from sibling tools like switch_account or get_account, though it does not elaborate on what 'connect' means in terms of underlying effect.
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 such as switch_account or list_accounts. The only condition given, 'Fails if not logged in', is a prerequisite rather than 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention return format, whether the current layout is included, ordering, or side-effect safety beyond the verb 'list' implying read-only behavior. This is minimal behavioral transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, and every word earns its place. For a zero-parameter enumeration tool, this level of brevity is appropriate.
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, no-output-schema tool, the description is minimally viable: an agent knows to call it to get saved chart layouts. However, it does not explain the return structure, whether the list contains IDs, names, or full layout objects, or whether any errors can occur. With no annotations or output schema, a bit more output 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 no parameter documentation is needed. The description accurately indicates what the output domain is ('saved chart layouts'), which is sufficient since there is nothing to configure or pass in. Baseline of 4 is appropriate for a no-parameter tool.
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 action and resource: 'List saved chart layouts.' This clearly identifies it as a read-only enumeration of chart layouts, which is distinct from layout_switch, layout_new, and other layout-related tools in the sibling list. It does not explicitly differentiate itself by naming siblings, but the verb and object are specific enough for an agent to select it.
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 gives no guidance on when to use this tool versus alternatives like layout_switch or layout_new. It only states what it does, leaving the agent to infer that listing is a precursor to switching or creating layouts. There is no explicit when-to-use or when-not-to-use 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 annotation are provided, so the description carries the full burden of behavioral disclosure. It merely says 'Modify an active trading order' but does not explain whether the change is applied in place, whether it cancels and replaces the order, what happens if the order is already filled or canceled, or whether any confirmation or response is returned.
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 with no wasted words and the core action and scope are immediately clear. The parenthetical field list is compact and does not repeat schema text verbatim.
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 mutation tool in a trading context, with no annotations and no output schema, the description is too thin. It lacks usage alternatives, behavioral side effects, order-status constraints, and any indication of what happens on success or failure, leaving an agent to guess important operational details.
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?
Since the schema already describes all four parameters with 100% coverage, the description does not need to explain parameter syntax. It does add a useful high-level grouping of the editable fields, but it does not provide any additional semantic detail 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 ('Modify'), a specific resource ('active trading order'), and lists the modifiable fields ('qty / price / stop_price'). This clearly distinguishes it from sibling order tools like place_order, cancel_order, and close_position.
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 state 'for new orders use place_order' or 'to remove an order use cancel_order', and it does not mention prerequisites or conditions such as order status beyond the word 'active'.
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 on compile errors, whether the previous indicator is replaced or duplicated, or whether the action can fail silently. The behavioral consequences are largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact phrase with no filler or redundancy. It front-loads the verb and object and stays well within an appropriate size for a simple no-parameter operation.
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-argument, no-output-schema tool, the description is minimally sufficient: an agent knows what action to invoke. However, given the large sibling list that includes pine_smart_compile and pine_get_errors, the lack of any detail about what 'current Pine Script' means or how this differs from similar tools leaves some ambiguity about when to use it.
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 there is nothing for the description to clarify about parameter semantics. This is a no-argument call, and the description does not attempt to invent or obscure parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Compile / add') and a clear resource ('the current Pine Script to the chart'), so an agent can tell what the tool does. However, it does not explicitly distinguish this from the similar sibling pine_smart_compile, and the slash could imply two different operations rather than one.
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 implies it should be used when the agent wants to compile and add the current Pine Script to the chart, but it gives no explicit context about prerequisites, chart state, or when to prefer this over sibling tools like pine_smart_compile or pine_save. No alternative routing 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?
There are no annotations, so the description must disclose behavior. It states that the tool checks the CDP connection and returns chart state, implying a read-only health check, but it doesn't describe failure behavior, side effects, or any required preconditions like being connected. This leaves the agent uncertain about edge-case 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?
A single concise sentence that front-loads the main action and return value. 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?
Given the zero-parameter schema and the simplicity of a health check, the description covers the main purpose and return. However, without an output schema or annotations, it doesn't specify the format or success/failure indicators of the returned chart state, and there's no mention of how this relates to the many sibling tools. It's minimally adequate but incomplete for an agent that needs to verify connection health or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the description needs no parameter details. The baseline for no-parameter tools is 4, and the description appropriately stays silent on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and names the resource ('CDP connection to TradingView'), and also states the return value ('current chart state'). However, it doesn't differentiate it from siblings like connect, get_status, or chart_get_state, so it's clear but not distinct.
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 connect or get_status. No exclusions or alternative conditions are provided, leaving the usage context to inference.
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 simply states the action without explaining important contextual behavior, such as whether the key press requires an active/focused element, whether it waits for the UI to respond, what happens on failure, or whether shortcuts are system-dependent. This is minimal 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, economical sentence that immediately states the action and provides useful examples. It is well front-loaded and contains no filler or redundant restatement of the tool name.
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 and schema together cover the basic 'what' and 'how' for a simple two-parameter tool, and no output schema exists to explain return values. However, the missing usage guidance and the ambiguous handling of composite shortcuts leave the agent without enough context to reliably select and invoke the tool in all cases, especially in a UI-automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description's shortcut examples like 'Alt+S' and 'Ctrl+Z' may actually mislead an agent into passing the combined shortcut as the key parameter instead of separating key ('s') and modifiers (['alt']). The description does not clarify that modifier keys should be decomposed into the modifiers array, which undermines the otherwise clear 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 states a specific verb ('Press') and a specific resource ('keyboard keys or shortcuts'), with concrete examples like Enter, Escape, Alt+S, and Ctrl+Z. This clearly distinguishes the tool from sibling mouse-oriented tools like ui_click and ui_mouse_click, and from text-entry tools like ui_type_text.
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 choose this tool over alternatives. For example, it does not say to use ui_type_text for entering text, ui_click for mouse interactions, or ui_hover for hovering. The only implication is that this tool handles keyboard input, but there is no explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions zooming but does not explain whether the existing visible range is replaced, whether a chart must already be loaded, how invalid ranges (from > to) are handled, or whether the change is reversible.
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. It conveys the action, the target, and the relevant unit 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?
For a simple two-parameter setter, the description plus schema is sufficient to understand the basic call. However, the absence of annotations and the lack of behavioral or usage context leave gaps around prerequisites and side effects, so it is 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%, with both 'from' and 'to' already described as unix timestamps in seconds and start/end of range. The description adds the phrase 'specific date range' but no additional semantic detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Zoom') and resource ('the chart') and clearly indicates the action is setting the visible date range. This distinguishes it from sibling tools like chart_get_visible_range (read) and chart_scroll_to_date (navigation).
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 chart_scroll_to_date or chart_get_visible_range. There are no prerequisites, exclusions, or context clues beyond the implicit meaning of the 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, the description carries the full burden of behavioral disclosure. It states the basic mutation ('Change ... input values') but does not explain how overrides are applied, whether they replace or merge with existing values, what happens on invalid input IDs, or what the response/return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that clearly fronts the core action and includes relevant examples. There is no filler or redundancy; every part contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the schema already documents the required parameters, but with no annotations or output schema, the description does not fully cover behavioral results or error conditions. An agent could invoke it correctly, but might not understand side effects or how to interpret the result.
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 explains both parameters, including that 'inputs' is a JSON string of overrides. The description's examples add minor illustrative value but do not provide 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 uses a specific verb ('Change') and a clear resource ('indicator/study input values'), with illustrative examples ('length, source, period'). It distinguishes the tool from siblings like indicator_add or indicator_toggle_visibility, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when modifying existing indicator/study input values, but it gives no explicit guidance on when not to use it or which alternative tools to prefer. There is no mention of prerequisites such as a loaded study or where to obtain the entity_id, which the schema partially covers.
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 behavioral burden. It only says 'show or hide' and gives no indication of side effects, persistence, error behavior, or prerequisites like whether the study must already exist. For a mutation-like tool, this is a meaningful 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, efficient sentence with no filler. The action is front-loaded, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 toggle, the description plus schema may be enough to invoke it, but there are gaps: no usage guidance relative to sibling tools, no return-behavior information despite no output schema, and no behavioral context beyond the literal action. It is adequate but not 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%, and both parameters are documented: visible says 'true to show, false to hide' and entity_id is described as the study's ID from chart_get_state. The description adds no additional parameter meaning, so the schema-driven 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 states a clear action ('Show or hide') and a specific resource ('indicator/study on the chart'). It is distinguishable from indicator_add, which is about adding indicators, and from indicator_set_inputs, which is about configuration. However, it does not explicitly contrast with chart_manage_indicator, leaving some potential ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this to change the visibility of an existing indicator/study. The entity_id provenance from chart_get_state hints at the workflow, but there is no explicit guidance about when to use this versus alternatives such as indicator_add or chart_manage_indicator, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states that the layout changes but does not disclose whether the existing layout is replaced, whether the change affects the active tab or all tabs, whether it is reversible, or what side effects occur on existing panes.
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 concrete examples and 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?
For a one-parameter setter with full schema coverage, the existing description is nearly adequate. However, the tool performs a mutation and has no annotations and no output schema, so the missing behavioral context—what the layout change actually does to existing panes—leaves the description slightly incomplete for confident 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 documents the layout parameter with accepted values and aliases at 100% coverage. The description's examples (single, 2x2, 2h, 3v) are repeated from the schema and add no meaningful semantic detail beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Change') and the resource ('chart grid layout'), and the examples (single, 2x2, 2h, 3v) make the scope concrete. It is distinguishable from workspace-level layout siblings like layout_switch because it explicitly says 'chart grid layout', though it does not 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you want to change the chart grid layout. However, no explicit guidance is given about when to prefer this over related tools like pane_focus, layout_switch, or layout_new, and there are no exclusions or 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?
No annotations are provided, so the description carries the full burden of disclosing behavioral impact. It only says the action starts replay mode, but does not describe what changes in the UI/chart state, whether a prior replay session is reset, or what happens after 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?
A single front-loaded sentence that states the verb, resource, and the one optional parameter. 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 tool with one optional parameter and a fully documented schema, the minimum invocation information is present. However, the description lacks sequencing context among replay_start, replay_step, replay_autoplay, and replay_stop, and does not explain what 'bar replay mode' entails beyond starting.
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 the date parameter fully. The description reinforces that the date is optional but adds no additional meaning 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 a specific action with a specific resource: 'Start bar replay mode'. It also mentions the optional date, which distinguishes it from related replay tools like replay_step, replay_autoplay, and replay_stop by naming the entry point into the mode.
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 gives no explicit guidance about when to use replay_start versus its sibling replay tools. The agent must infer from the tool name and sibling names that this is the entry point to replay mode, rather than being told.
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 discloses the core action ('switch to a chart tab') but does not mention side effects, invalid-index behavior, or whether the switch modifies UI state beyond selection. For a simple navigation action, this is minimally acceptable 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 one short sentence with no filler. It names the action, target, and index basis 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 simple one-parameter tool, the description and schema together are functionally adequate. However, there is no mention of error conditions, prerequisites, or return behavior, and no annotations exist to fill those gaps, leaving the context 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 fully documents the only parameter, including its 0-based indexing and relationship to tab_list. The description adds no extra meaning beyond what the schema provides, so 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 a specific verb ('Switch'), a resource ('chart tab'), and the selection method ('by index'). It is unambiguous about what the tool does, though it does not explicitly contrast itself with sibling tools like tab_list, tab_new, or 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?
The description gives no guidance about when to prefer this tool over alternatives such as layout_switch or ui_click. The parameter schema hints that the index comes from tab_list, but the description itself does not provide usage 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 full responsibility for disclosing behavior. It only states the purpose, not any behavioral traits like whether scrolling is animated, affects the time or price axis, or depends on focus. There's no mention of side effects or limitations, which is a notable gap for a UI interaction 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 that directly states the tool's function without any clutter. It is appropriately front-loaded with the verb and target, and every word contributes to the meaning. Ideal conciseness for a simple operation.
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 relatively simple, and the schema covers parameters. However, the description omits contextual details such as whether it operates on the currently focused pane, how it interacts with page scroll, or what happens when the scroll limit is reached. Given the existence of many UI tools, a bit more context would help, but it's adequate for basic usage.
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 coverage is 100%, documenting both 'amount' (with default) and 'direction' (with enum). The description adds no extra meaning beyond the schema, which is the baseline for high coverage. No additional context is provided that would clarify parameter interplay.
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 (scroll), the target (chart or page), and the directions (up/down/left/right). It distinguishes itself from siblings like ui_click or chart_scroll_to_date by being a generic scroll operation, and the enum in the schema reinforces the four directions.
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 (e.g., an open chart), which context it applies to, or any exclusions. An agent has to infer that this is the general scrolling tool among the many UI utilities.
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. The one-line description does not reveal whether the screenshot is returned as a file, base64, or path, nor does it mention side effects or the difference between capture methods. The only behavioral hint resides in the wait_for_render parameter description, not in the tool description 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 zero waste. It communicates the essential action clearly and does not repeat information already present in the 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?
There is no output schema and no annotations, yet the description does not explain what the tool returns, where the screenshot is saved, or how the cdp and api methods differ in practice. The schema describes inputs well, but the missing output contract and lack of preconditions leave an agent uncertain about how to consume the result.
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 all four parameters already explained in the input schema. The tool description adds no parameter-level meaning, which matches the baseline expectation: because the schema does the heavy lifting, no additional parameter explanation 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 states a specific verb and resource: 'Take a screenshot of the TradingView chart'. This clearly distinguishes the tool from the large sibling list, which contains no other screenshot operation. Even with no title, the function 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 intended use is implied by the verb, but there is no explicit guidance on when to use this tool versus alternatives or whether certain preconditions must hold. The wait_for_render parameter hints at a timing concern, but the top-level description does not state prerequisites or exclusions.
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 behavioral disclosure burden. The word 'Read' indicates a non-destructive operation, and the content types are listed. However, it doesn't disclose whether the tool triggers a compilation, clears the log after reading, or what it returns when the console is empty, leaving some 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 compact sentence that front-loads the action and resource, followed by a useful parenthetical of content examples. Every word earns its place, 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?
For a simple parameterless getter, the description covers the main return content. However, there is no output schema, and the description doesn't clarify how this tool relates to pine_get_errors or whether the console output reflects the most recent compilation. These are small but meaningful gaps given the lack of structured annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered. There are no input semantics to explain, and the baseline of 4 for parameterless tools 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 uses a specific verb ('Read') and a clear resource ('Pine Script console/log output'), with concrete examples of content types. It is clearly distinguished from a tool like pine_get_errors by covering broader console output, though it doesn't explicitly name any sibling.
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 about when to use this tool versus related tools such as pine_get_errors, pine_compile, or pine_get_source. The description implies a general console-reading purpose but provides no explicit exclusions, prerequisites, or alternatives, forcing the agent to infer relationships from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a new blank script is created, but does not mention side effects, persistence, whether the script is opened/selected afterward, authentication needs, or what happens on success or failure.
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 or repetition. Every word earns its place, and the core action is immediately understandable.
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 creation tool with a fully documented schema, the description is mostly complete. The only gap is the lack of behavioral/return details, but nothing needed to invoke the tool correctly is missing from the description or schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'type' already has a clear description and enum values, so the schema handles parameter semantics. The tool description adds no additional meaning beyond what the schema provides, warranting the baseline score.
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 ('Create') and resource ('new blank Pine Script'), clearly conveying the action. It distinguishes from siblings like pine_open, pine_compile, and pine_list_scripts, although it does not explicitly name an alternative.
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 'new blank' implies this tool is for starting a fresh Pine Script, but there is no explicit guidance about when to use it versus pine_open or pine_set_source. Usage context is only implied, with no exclusions or alternative routing.
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 behavioral disclosure burden. It reveals order types and optional TIF/brackets but does not state that this is a live financial action, whether confirmation or order ID is returned, or what connection/account prerequisites apply.
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 front-loaded sentence with no wasted words; compactly enumerates key order types and optional features while keeping the primary action explicit.
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 10 parameters, no annotations, no output schema, and live trading consequences, the description omits return/confirmation behavior, per-type required conditions, and connected-account prerequisites. The schema documents parameter names but not the call outcome or operational 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 schema already documents all parameters. The description adds useful grouping (order types, TIF choices, bracket orders) but does not add substantive meaning beyond the schema or clarify conditional-required parameter combinations.
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?
States a specific verb and resource ('Place an order with the connected broker') and enumerates order types, clearly distinguishing it from sibling order-management tools like cancel_order, modify_order, and set_brackets.
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 'use this when placing a new order,' but it does not explicitly say when to prefer this tool over modify_order, cancel_order, or set_brackets. Context is present, but exclusions and alternative routing are left to inference.
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 disclosing behavior. It says the code runs in the TradingView page context, which is useful, but it does not warn that arbitrary JavaScript can mutate page state, nor does it mention side effects, reversibility, or execution limits.
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, and it front-loads the action and context. It is appropriately sized for a simple one-parameter tool, even though more behavioral detail would be valuable.
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 an arbitrary code execution tool, the description does not explain what the tool returns, how results are surfaced, or what happens when the expression fails. Since there is no output schema to fill that gap, an agent cannot reliably know what to expect from the 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?
Schema description coverage is 100%, so the single expression parameter is already fully documented. The description adds no additional parameter meaning beyond what the schema 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 states a clear verb and resource: execute JavaScript code in the TradingView page context. It also communicates the intended use case, advanced automation, and there is no sibling tool that does the same thing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for advanced automation' hints at when this tool is appropriate, but it does not explicitly say when to prefer it over the many specific sibling tools. 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the basic actions but does not mention what happens if the panel is already in the requested state, whether opening one panel closes another, or whether TradingView needs to be loaded first. 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 one efficient sentence with zero filler. It front-loads the action verbs and resource, then lists concrete panel types, giving the agent all necessary high-level information in compact form.
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 only two enum-constrained parameters and no output schema, this description is mostly sufficient. It names the target resource, the valid actions, and the panel identifiers. A brief note about prerequisites or state-dependent behavior would round it out, but nothing critical is missing for basic 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 input schema fully documents both parameters: each has an enum constraint and a description. The description's list of panel names duplicates the schema values and adds no additional meaning about parameter formats, defaults, or interactions. Since schema coverage is 100%, a 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 names a specific action set (open/close/toggle) and an explicit resource (TradingView panels), enumerating the supported panels. However, the sibling tool `open_panel` exists and the description does not clarify how `ui_open_panel` differs from it, so it doesn't fully distinguish itself within the tool family.
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 purpose statement implicitly tells an agent to use this tool when a TradingView panel needs to be opened, closed, or toggled. There is no explicit when/when-not guidance and no mention of alternatives like `open_panel`, `tv_ui_state`, or `ui_click`, but for a simple UI manipulation tool the implied usage is reasonably clear.
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 behavioral disclosure burden. It only states the mutation ('add') and does not mention what happens if the symbol is already present, whether validation occurs, what side effects exist, or how the watchlist is affected.
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 or redundancy. Every word contributes to stating the core action.
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?
Even though this is a simple one-parameter tool, the absence of annotations and output schema means the description should provide more context about prerequisites, return values, duplicate handling, or failure modes. It currently only states the basic action, which is too thin.
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 coverage is 100% and already documents the symbol parameter with realistic examples. The description adds no extra parameter semantics beyond the schema, 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 uses a specific verb and resource: 'Add a symbol to the TradingView watchlist.' The singular 'a symbol' clearly distinguishes this from sibling watchlist_add_bulk, and the action is unambiguous even without opening the schema.
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 is implied from the name and simple wording, but there is no explicit guidance about when to choose this over watchlist_add_bulk, watchlist_remove, or watchlist_get. No when-not-to-use conditions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It only discloses the mutation and the current-symbol dependency; it does not mention prerequisites (an active chart), side effects, idempotency, or possible failures, which are important for a create operation with no output 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 with no filler or repetition. It conveys the action, target, scope, and mechanism economically.
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 create tool with three documented parameters, the core object is clear. Still, the absence of annotations and output schema leaves success/error behavior and preconditions undeclared, so the definition is adequate but not fully complete for an agent invoking it autonomously.
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 each parameter has its own description, so the schema does the heavy lifting. The tool description adds useful context about current chart symbol and the TradingView alert API, but it does not enrich the meaning of price, condition, or message 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 names a specific verb ('Create'), a specific resource ('a price alert'), and a scoping constraint ('on the current chart symbol'). This clearly separates it from alert_list and alert_delete while also distinguishing it from data/replay 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 context is clear: this is for creating a new alert tied to the currently displayed symbol. However, the description does not explicitly mention when not to use it or name alternatives such as alert_list/alert_delete for managing existing alerts, so the routing 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the 'active' status and does not describe irreversibility, permission requirements, error behavior, side effects, or post-cancellation state.
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 with no wasted words. The action, target object, and required input are all front-loaded and immediately clear.
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 single-parameter tool, the description is largely adequate, but the absence of annotations, output schema, and usage guidance leaves important context implicit, such as failure modes and whether cancellation is idempotent. It is minimally viable 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?
Schema description coverage is 100% and the order_id parameter is documented as 'Order id'. The description adds marginal context with 'active trading order' and 'by id,' but does not provide additional format, source, or validation semantics 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 ('Cancel') and resource ('active trading order') and identifies the selection method ('by id'). This clearly differentiates it from siblings like modify_order and close_position.
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 'active trading order' implies that the tool is for canceling open orders, but it does not explicitly state when to use cancel_order versus alternatives such as modify_order or close_position. Usage is inferable but not explicitly guided.
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. The verb 'get' implies a read-only operation and the object tells the user what data is returned. However, there is no disclosure of output structure or behavior when no Strategy Tester results are available.
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 or repetition. It front-loads the action and the resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description names the exact resource retrieved and the source. It does not explain how the target Strategy Tester context is selected or what the equity curve data structure looks like, but the basic call behavior is clear enough.
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, so there is no parameter semantics for the description to clarify. This matches the baseline score of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('equity curve data from Strategy Tester'). It is specific enough to understand what the tool does, though it does not explicitly contrast it with sibling tools such as data_get_trades or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus closely related sibling tools like data_get_strategy_results, data_get_trades, or data_get_indicator. The description states only what the tool does, not the conditions under which it should be chosen.
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 conveys that the operation is a read ('Get') and that data comes from the chart, but it does not disclose whether a chart must be open, whether the data is real-time or snapshot-based, or whether the tool is unsupported for certain market types. This is minimal behavioral information for a no-annotation 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, direct sentence with the action and object front-loaded. It contains no filler and every word contributes to the meaning.
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 getter, naming the resource and source covers basic selection and invocation. However, with no output schema and no annotations, the description does not clarify the return shape, whether the active chart symbol is used implicitly, or if order book data is available for all symbol types. It is adequate but leaves meaningful operational details to inference.
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 there is no parameter documentation gap for the description to fill. The baseline for a no-parameter tool applies, and no further parameter-level detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: getting order book/DOM data, and it notes the data source is the chart. This clearly distinguishes it from sibling retrieval tools like quote_get or data_get_ohlcv, whose resources are explicitly different. The parenthetical '(Depth of Market)' also removes ambiguity about the acronym DOM.
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 such as quote_get, data_get_trades, or data_get_ohlcv, and no exclusion conditions are stated. The phrase 'from the chart' implies a dependency on the active chart but does not say it explicitly or mention prerequisites.
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 behavioral disclosure itself. It indicates a read-only operation by saying 'Get' and specifies the returned content (properties and points), but it does not disclose error behavior, return structure, or any side effects—though for a simple getter the lack of side effects is reasonably clear.
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 verb and resource with no filler or redundant detail. It earns high marks for efficiency.
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 a clear noun phrase about what is retrieved. However, with no output schema, the description could be more explicit about the shape of the returned properties and points; as written, an agent knows what to expect semantically but not structurally.
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 entity_id parameter is already documented with context that it comes from draw_list. The tool description adds no additional parameter semantics, which is acceptable given the schema already covers the only 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 operation (get) and resource (properties and points of a specific drawing), making it distinct from broad listing tools like draw_list. It does not explicitly name sibling alternatives, but 'specific drawing' helps signal single-entity retrieval.
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 schema description adds 'from draw_list', implying the correct prerequisite workflow of listing drawings first. However, the tool description itself gives no explicit guidance on when to choose this tool over alternatives like draw_list or 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 of behavioral disclosure. It only restates the destructive action and does not explain whether removal is permanent, what happens if the entity_id is invalid, or what the tool returns.
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. It efficiently communicates action, resource, and selection key.
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 covers the single parameter, but there is no output schema and no annotations to fill in behavioral gaps such as error handling, idempotence, or confirmation of removal. The description is adequate for invoking the tool 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?
Schema description coverage is 100%, so the entity_id parameter is already fully documented. The description adds only 'by entity ID,' which confirms the selection mechanism but provides no additional meaning 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 ('Remove'), a clear resource ('drawing'), and a precise selection mechanism ('by entity ID'). This clearly distinguishes it from draw_clear, which removes all drawings, and from read-only siblings like draw_list and draw_get_properties.
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 tool is for removing a single drawing by ID, and the schema's reference to draw_list hints at the required workflow. However, it never explicitly names draw_clear as the alternative for removing all drawings or states 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Switch to a saved chart layout' indicates a state change but does not mention potential side effects such as discarding unsaved changes, requiring existing layouts, or behavior on invalid names. This is a significant 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, front-loaded sentence with zero unnecessary words. It conveys the action, target, and input format in ten words, which is appropriately concise 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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the one-sentence description is minimally adequate but lacks context on success/failure behavior, side effects, or prerequisites. A more complete description would confirm what happens to the current workspace and how failures are reported.
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 100% of parameters, and its description ('Name or ID of the layout to switch to') largely duplicates the tool description. The description adds no new semantic meaning beyond confirming that the name parameter maps to the layout being switched, so the schema-heavy 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 states a specific verb ('Switch to'), a clear resource ('saved chart layout'), and the accepted input scope ('by name or ID'). This distinguishes it from sibling tools like tab_switch or layout_list without needing to inspect schemas.
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 change the active chart layout, but it does not explicitly say when to use it versus alternatives like layout_list to find layouts or tab_switch. No exclusionary guidance is provided, leaving usage context inferred.
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 must carry the full burden of behavioral disclosure. It only states the action and keyboard shortcut, but does not disclose whether this overwrites unsaved changes, whether it requires an open editor, whether it reports success/failure, or what side effects occur.
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 well-formed sentence that is front-loaded with the verb and resource, plus a helpful keyboard-shortcut hint. There is no wasted wording or redundant restatement.
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 save action, the description is minimally viable, but it leaves out context such as what 'current' refers to (active tab/editor), whether the operation persists to disk or workspace, and what happens if there is nothing to save. Given the absence of annotations and output schema, a bit more context would be warranted.
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 adds no parameter detail, but none is needed since the input schema is empty and coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Save') and a specific resource ('the current Pine Script'), which distinguishes it clearly from sibling tools like pine_get_source and pine_compile. The parenthetical '(Ctrl+S)' reinforces the exact operation without 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?
The description does not state when to use this tool versus alternatives such as pine_new, pine_open, or pine_set_source. There is no mention of prerequisites like having an editor open or whether this persists to a specific location, so the agent gets no routing guidance beyond the inferred 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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It states the immediate effect but does not mention whether a replay session must be active, what happens at the end of available bars, or whether the action is reversible.
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 and contains no filler. Every word contributes to conveying 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?
The description is adequate for a zero-parameter action but leaves out useful context such as the need for an active replay session and how it relates to replay_autoplay. It does everything required to identify the action, but not enough to fully inform correct invocation in all scenarios.
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?
There are zero parameters and the schema is empty, so there is no parameter information to document. Per the baseline for zero-parameter tools, a 4 is appropriate even though the description adds nothing 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 states a specific verb ('advance'), a specific resource ('one bar'), and the mode ('replay mode'). It clearly distinguishes itself from sibling replay tools like replay_start or replay_autoplay, which do 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. There is no mention that it should be used for manual stepping while replay_autoplay is for continuous playback, nor any stated prerequisite that replay mode must already be active.
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 disclosure. It does not explain potential side effects like triggering tooltips or hover menus, whether the element must be visible, or what happens when the element is not found.
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, tightly worded sentence with no filler. The action, resource, and selector strategies are all front-loaded and clearly conveyed.
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?
Adequate for a simple two-parameter action, but thin overall. With no output schema and no annotations, the agent receives no information about return values, failure behavior, or hover-induced UI changes.
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 both parameters. The description partially restates the 'by' enum but omits 'class-contains', and adds no extra meaning beyond what the schema 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 states a specific verb ('Hover') and a clear resource ('a UI element'), and enumerates the main selector strategies. It is immediately distinguishable from sibling tools like ui_click or ui_scroll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb implies when to use the tool: whenever a hover interaction is needed. However, it gives no explicit guidance on when not to use it, no prerequisites, and no comparison with alternative UI interaction 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 must fully disclose behavioral traits itself. It does state the key precondition that the target must be the currently focused element, but it fails to mention whether existing text is replaced or appended, how special characters are handled, or what happens when no editable element is focused.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and target. It contains no filler or redundant information, making it highly 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 one parameter and no output schema, the description is mostly adequate and the focused-element precondition is useful. However, the ambiguity around whether typing overwrites or appends existing content, and the lack of error behavior when no focus exists, leave meaningful gaps 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?
The single `text` parameter is fully documented in the input schema (100% coverage), so the description does not need to add much. The schema description 'Text to type into the focused element' already covers the parameter's meaning, leaving no additional semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly uses the verb 'Type' and specifies the resource as 'the currently focused input/textarea element', making the tool's function immediately clear. It is distinguishable from sibling UI tools like ui_click and ui_keyboard because it focuses on text entry into editable fields.
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 intended use case: typing text into an already-focused editable element. However, it provides no explicit guidance on when to use this tool versus alternatives like ui_keyboard, nor does it state prerequisites beyond the 'currently focused' condition.
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, but it only restates the core action. It does not mention whether duplicates are ignored, whether existing watchlist contents are preserved, how invalid symbol formats are handled, or what the mutation implies for the current TradingView session.
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 and the key information is immediately visible.
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-covered parameter and no output schema, so the description is minimally viable. However, with no annotations, an agent still lacks guidance on expected return value or failure behavior, leaving the definition just 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%, so the schema already documents the symbols parameter with examples. The description adds no parameter-level detail beyond the word 'multiple', 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 names a specific verb ('Add'), a specific resource ('TradingView watchlist'), and a specific scope ('multiple symbols'), which clearly differentiates it from sibling watchlist_add (single) and watchlist_remove/get. An agent can identify what this tool does without inspecting the schema.
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 use is implied by 'multiple symbols' and the existence of watchlist_add, but the description never explicitly states when to prefer this tool over the singular watchlist_add or how it should be used in a batch workflow. 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.
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 does disclose the core behavior—changing the viewport to center on a date—but says nothing about side effects, failure behavior for out-of-range dates, or whether the chart must already be launched. This is adequate but has 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?
A single, front-loaded sentence with no filler. The verb and object are immediately clear, and the rest of the sentence adds the only needed detail.
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 one-parameter navigation command with no output schema, the description is functionally complete: an agent knows what action to take and what input is relevant. It omits edge-case behavior on invalid or out-of-range dates, but that is less critical for a simple viewport jump.
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 describes the single 'date' parameter as an ISO date or Unix timestamp string (100% coverage), so the baseline applies. The description adds only the context that this date is the centering target, without extra format, syntax, or edge-case semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('jump ... to center') on a well-defined resource ('chart view') with a precise target ('a specific date'). This clearly separates it from siblings like chart_set_symbol, chart_set_timeframe, or chart_set_visible_range, which change other aspects of 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 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 vs alternatives such as chart_set_visible_range or replay controls. The purpose statement implicitly suggests the use case, but there is no explicit context, prerequisite, or exclusion to help an agent choose among navigation-related siblings.
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 the action but does not mention side effects, prerequisites (e.g., an open chart or valid pane), behavior for invalid indices, or whether the tool returns anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. The action, resource, and indexing scheme are all present 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 simple one-parameter UI focus action, the description plus schema covers the essential details: what is focused and what the parameter means. It could mention prerequisites or invalid-index behavior, but the simplicity of the operation reduces the need for extensive 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 schema already documents the index parameter. The description restates '0-based' but adds no new meaning beyond the schema, earning the baseline score 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 uses a specific verb ('Focus') and a specific resource ('chart pane by index'), making it immediately clear what the tool does. It is distinct from sibling tools like pane_set_layout or pane_set_symbol, which perform different pane-related actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the core usage concept ('by index, 0-based') and the schema points to pane_list as the source of the index, implying it should be used after retrieving pane_list. However, there is no explicit statement of when to use this tool vs. alternatives or any exclusions.
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 communicate behavior on its own. 'Get' signals a non-mutating read and the parenthetical names the data fields, which is useful. However, it does not disclose whether an active chart or session is required or the shape and format of the returned metadata, leaving some behavioral ambiguity for an agent.
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 sentence gets straight to the point: the verb, resorce, and returned fields are front-loaded with no filler. Every word contributes to understanding 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?
For a zero-parameter getter this is mostly adequate, but with no output schema the description should more explicitly describe the return value and any precondition such as an active chart with a selected symbol. The listed fields hint at the return payload but do not fully specify it.
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 and 100% schema description coverage, so the baseline is 4. The description adds context that the operation is scoped to the 'current symbol', which is the only relevant semantics; there are no parameter details needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the explicit verb 'Get' and identifies a specific resource, the current symbol's metadata, while listing the fields returned. It is not a tautology, but it does not explicitly compare itself to sibling tools such as symbol_search or quote_get, so it stops short of full sibling differentiation.
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 'current symbol' implies the tool should be used when a symbol is already loaded or selected, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like symbol_search or quote_get. The usage context is therefore only implied, 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 behavioral disclosure. It does disclose the destructive scope ('specific alert' or 'all active alerts'), which is important, but it does not mention irreversibility, confirmation, or what happens if both parameters are supplied.
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 with no redundant content. The two deletion modes are front-loaded and immediately actionable.
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 low-complexity delete tool with full schema coverage, the description names the operation and both modes. However, leaving ambiguous what happens if no parameters or both parameters are provided is a notable gap for an AI agent invoking 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%, and the schema already documents both parameters. The description adds the useful 'or' relationship between alert_id and delete_all and the 'active' qualifier, but it does not clarify mutual exclusivity, precedence, or behavior when neither parameter 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 states a specific verb ('Delete'), a clear resource (alert), and the two operational modes: by id or all active alerts. This distinguishes it clearly from siblings like alert_create and alert_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 description implies when to use this tool—when an alert needs to be deleted—and distinguishes between deleting one specific alert versus all active alerts. However, it does not explicitly reference alternatives like alert_create or alert_list, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure. It states the core action (toggle autoplay) but leaves ambiguity about whether providing a speed also toggles autoplay or only sets the speed, and how this interacts with an existing replay session. There is no mention of return values, state changes, or side effects, though the primary action is at least 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, efficient sentence that front-loads the primary action and resource, then mentions the optional parameter. Every word carries meaning and there is 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?
The tool is simple, with one optional parameter and no output schema, but the description leaves unresolved how the speed parameter interacts with the toggle and what happens if replay mode is not active. The description is not grossly incomplete for a trivial tool, but additional context about state effects would make it more robust.
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 fully documents the speed parameter, including valid values and the note 'Leave empty to just toggle.' The tool description adds no additional meaning beyond what the schema provides. 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 uses a specific verb 'Toggle' with a clear resource: 'autoplay in replay mode'. This distinguishes it from related siblings like replay_start, replay_step, and replay_stop, which focus on other replay controls. The optional speed is also mentioned, making the tool's scope immediately evident.
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 that this tool is used for controlling autoplay in replay mode, but it does not explicitly state when to use it versus alternatives such as replay_start or replay_step. There is no discussion of exclusions or conditions that would route an agent to a different sibling. Usage is largely inferred from the name and 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation with no side effects, but the description does not elaborate on edge cases (e.g., behavior when replay mode is off) or output format. For a simple status query, this minimal transparency is adequate but not enriching.
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 communicates the tool's purpose. There is no redundant or unnecessary 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?
For a tool with no output schema and no annotations, the description doesn't specify what the status response will contain or how to interpret it. An agent knows it can call the tool to get status, but not what values or structure to expect. Given the tool's simplicity, this is a minor but notable 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 input schema is empty; there are no parameter semantics to clarify. The baseline for a zero-parameter tool is 4, and the description doesn't need to compensate for any parameter documentation gaps.
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 replay mode status'), making the tool's function immediately obvious. It is clearly distinguished from the sibling replay_* tools, which perform actions (start, stop, step) rather than report 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is the correct tool for checking replay state before calling replay_start/step/stop, nor does it exclude any context. The intended usage is only implicit in the name and 'current status' phrasing.
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 behavioral burden. It clearly indicates a mutating operation and the 'clear' option signals destructiveness. However, it does not disclose side effects such as whether setting one bracket preserves the other, what happens if no matching position exists, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler; the action verbs are front-loaded and every word contributes to the meaning. It is concise without being under-specified.
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 parameter schema fills in the details for symbol, position_id, clear, and prices, but the description alone does not explain behavior when only one bracket is set, how clear interacts with prices, or how to route between this and sibling order tools. With no output schema or annotations, these 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?
The schema already describes all five parameters with 100% coverage, so the description adds no new parameter-level meaning beyond naming the two bracket fields. This meets the baseline for a schema-covered tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action set (add, change, or clear) with a clear resource (stop loss / take profit on an open position). This distinguishes it from sibling order tools like modify_order and close_position, even without naming 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 phrase 'on an open position' implies when the tool should be used, but it does not explicitly say when to prefer this over modify_order or place_order, nor does it mention exclusions. Usage context is clear but not fully 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, the description carries the full burden, yet it only restates the literal close action. It does not disclose irreversible loss of tab state, which tab becomes active afterward, or behavior when there is no current tab.
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 conveys the exact action and target with no filler or duplicated schema 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?
For a zero-parameter, no-output-schema tool the core action is stated, but as a destructive operation it lacks side-effect context such as post-close tab selection or behavior on the last tab. The description is minimally viable rather than 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 input schema has zero parameters, so no parameter-level semantics are needed. The baseline score of 4 applies: the description correctly avoids inventing 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 uses the specific verb 'close' with the resource 'current chart tab', making both the action and its scope unambiguous. This distinguishes it from sibling tools like tab_new, tab_switch, and tab_list by naming a clearly 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?
The intended use is implied—use this when you want to close the currently active chart tab—but no explicit guidance is given about alternatives or edge cases such as closing the last tab. There is no when-not-to-use or sibling comparison.
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 communicates a read-only operation and the return format, but does not discuss output limits, error cases, or whether a chart must contain the indicator. It's acceptable but 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?
Three terse, front-loaded sentences with no filler. The purpose, return shape, and filter hint are each in their own sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema and three optional, fully documented params, the description covers what it returns and how to filter. It could add a note about alternatives or prerequisites, but nothing essential is missing.
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 a small hint for study_filter but doesn't enrich verbose or max_labels 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?
States a specific verb ('Read') and resource ('text labels drawn by Pine Script indicators (label.new)'), and distinguishes from sibling tools like data_get_pine_lines and data_get_pine_boxes by focusing on labels. Also specifies return format ('text and price pairs').
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 (read text labels) and gives a filter hint ('Use study_filter to target a specific indicator'), but doesn't explicitly contrast against sibling tools or state when not to use it. 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.
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 discloses material side effects: 'Auto-opens the panel and auto-unhides a hidden strategy.' This tells the agent the call mutates UI state beyond simply reading data, which is valuable. It does not disclose all potential side effects (e.g., requiring the panel to be available), but the main ones 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, both informative. The primary action is front-loaded in the first sentence, and the behavioral caveat is succinctly added in the second. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately covers the source of the trades and the notable side effects. It is slightly incomplete because it does not describe what the returned trade list contains, but the absence of an output schema makes this less critical for 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?
Schema description coverage is 100% for the sole parameter max_trades, so the baseline is 3. The description does not add any additional meaning about max_trades beyond the schema, but the schema already fully documents it.
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 and resource: 'Get trade list from Strategy Tester.' This clearly identifies what the tool does and differentiates it from other data_get_* siblings like data_get_strategy_results or data_get_equity. The additional side-effect mention further characterizes the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool instead of alternatives such as data_get_strategy_results or data_get_equity. The phrase 'from Strategy Tester' hints at context, but no conditions, exclusions, or alternative tool names are provided. The side-effect note about opening the panel is behavioral, not usage 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?
With no annotations, the description carries the full burden of disclosing behavior. It clearly indicates a destructive action ('Remove all') but does not disclose whether the action is irreversible, whether confirmation is needed, or what side effects occur. Given the mutation-like nature of this tool, more behavioral context is needed.
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. It fully communicates the action and target in minimal words, earning a top conciseness score.
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, zero-output tool, the description is largely sufficient: it names the action and scope clearly. However, it omits any note about irreversibility or the state of the chart afterward, which would help an agent assess consequences.
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 already reflects that with an empty properties object. The description adds no parameter information, but none is needed; a baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Remove'), a specific resource ('all drawings'), and a scope ('from the chart'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling draw_remove_one by emphasizing that it clears everything rather than 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'all drawings' implies this is for clearing the entire chart rather than removing specific items, but it does not explicitly mention alternatives or when not to use it. Usage guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implies a read-only, chart-wide enumeration with 'List all', but it does not disclose whether the result contains IDs/handles, what shape types are included, or whether an open chart is required.
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 or repetition. Every word contributes to meaning: it states the action, the resource, and the full scope.
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 list tool, the description is largely sufficient to select and invoke it correctly. The main gap is the lack of any return-value details or output format, but the low complexity and absence of parameters make this a minor deficiency.
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, and the description adds no parameter requirements, so there is little to clarify. The baseline of 4 applies because no parameter documentation is needed for this no-argument tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'all shapes/drawings on the chart', making the operation immediately clear. The word 'all' scopes it as the enumeration tool, distinguishing it from draw_shape, draw_remove_one, draw_get_properties, and draw_clear.
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 draw_list versus alternatives such as draw_get_properties or data_get_pine_lines. There is no mention of workflows like listing before removing, so usage must be inferred entirely from the name and sibling set.
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 discloses the return format (titles grouped by section) but does not explicitly state the operation is read-only or describe any side effects. For a search tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler, front-loaded with action and resource. Every word adds value, and the grouping detail is mentioned 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?
Adequate for a simple search tool with two parameters and no output schema. It covers what is searched and the structure of results. Missing only minor details like default limit behavior, but these are unlikely to be critical.
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 documentation covers both parameters fully (100% coverage). The description mentions 'by keyword' linking to the query param but adds little beyond the schema; grouped-by-section is a result behavior, not 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?
States a specific verb (search), resource (TradingView's Indicators dialog), and scope (indicators, strategies, community/public scripts). Clearly distinguishes from sibling tools like symbol_search and indicator_add, as it targets the Indicators dialog specifically.
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 on when to use this tool versus alternatives like symbol_search or indicator_add. The purpose is clear enough that an agent could infer usage, but there's no contrast or exclusion clause.
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. The verb 'List' clearly signals a read-only operation and 'open trading positions' defines scope, but it does not disclose whether positions are limited to the current account, whether closed positions are included, or what the response shape will be. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It states the action and target clearly in the most efficient way possible.
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 (zero parameters, no annotations, no output schema), the description is largely sufficient to understand what the tool does and invoke it. It does not elaborate on return format or account scoping, but these are not critical for a basic zero-parameter list 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 baseline is 4. The description correctly implies there is no input needed, and no parameter documentation 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 ('List') and a clear resource ('open trading positions'), which distinguishes it from related siblings like list_orders and close_position. Even without naming alternatives, the resource type makes 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 provided about when to use this tool versus alternatives such as list_orders or data_get_trades. There is no mention of account context, prerequisites, or conditions that would select 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'List saved Pine Scripts' establishes a read-only enumeration, but it does not disclose the return format, whether this includes cloud/local scripts, or any other behavioral details an agent might need.
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 is appropriately sized for a zero-parameter list operation and still conveys the essential action and resource.
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 list tool, the description is mostly complete: it names the resource and the operation. It does not specify the return structure, but for this straightforward operation that is a minor gap rather than a blocking omission.
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. There are no parameter semantics to clarify, and the description does not need to compensate for missing parameter documentation.
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 is specific: it identifies the action ('List') and the resource ('saved Pine Scripts'). It clearly distinguishes itself from sibling tools like pine_get_source or pine_save, which read or modify scripts rather than list 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 gives no guidance on when to use this tool versus alternatives such as pine_open, pine_get_source, or pine_new. There are no context cues or exclusions, so an agent must infer the appropriate use case.
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 'List' verb implies a read-only operation, but with no annotations, the description carries the burden of disclosing behavior. It does not clarify scope (e.g., all windows vs current window) or whether the response is a simple array or includes tab metadata. For a trivial zero-parameter list tool, 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 clear sentence with no filler. It front-loads the verb and object, making it easy to scan. Nothing extraneous is included.
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 a zero-parameter list operation, so minimal description is needed. However, without an output schema, the description does not specify the return shape or any edge cases (e.g., no open tabs). This is a minor gap given the 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?
There are no parameters, so there is nothing to explain. With an empty input schema, the description need not add parameter details. The baseline for zero-parameter tools applies 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 uses a specific verb ('List') and a precise resource ('open TradingView chart tabs'). It clearly distinguishes from sibling tab management tools like tab_new, tab_close, and tab_switch, and from layout_list, since it targets chart tabs specifically. The purpose is immediately understandable.
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 instead of alternatives. It does not mention that tab_list is the read-only counterpart to tab_new/tab_close/tab_switch, nor does it reference layout_list or other list tools. The agent must infer the use case from the name.
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 present, so the description carries the behavioral disclosure burden. It explains the two loading modes, but does not state what happens when layout is omitted, whether the new tab becomes active, or what the tool returns.
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 core action. No filler, and every clause adds relevant 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 low-complexity tool with full schema coverage, the description covers the main usage cases well. Minor gaps remain around omitted-layout behavior and return values, but these are not critical for basic 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?
Schema coverage is 100%, so the baseline is 3. The description restates the 'new' and saved-layout semantics and adds the 'named blank layout' nuance, but most parameter detail is already in 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?
States a specific action ('Open a new chart tab') and clearly distinguishes this from tab management siblings by identifying the resource (chart tab). It also explains the optional loading modes.
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 is reasonably implied by the core action and the layout parameter instructions. However, the description does not explicitly contrast this with tab_switch, tab_close, layout_new, or layout_switch, so alternative selection guidance is left mostly to inference.
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 must carry the behavioral disclosure burden. 'Report' implies a read-only, non-mutating operation, but it does not clarify side effects, response format, or whether this performs a live network scan. It is adequate but 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, grammatically complete sentence delivers the tool's purpose with no filler. The key verb and resource appear immediately, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter discovery tool with no output schema, the description communicates enough to know what the call will return: available paths and their HTTP methods. It lacks detail about output structure or edge cases, but those are less critical for a simple introspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter-level meaning, and no parameter documentation gaps exist.
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 ('Report') and a specific resource ('known TradingView API paths') and states what is output (availability and methods). It clearly distinguishes itself from siblings like tv_health_check, which implies status checking rather than endpoint discovery.
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 tv_discover versus alternatives such as tv_health_check or get_status. The description does not mention prerequisites, expected scenarios, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does well by disclosing auto-detection, the MSIX fallback behavior, the msix_local_copy result flag, and the potentially slow ~330MB copy. It does not mention the kill_existing default behavior, though that is covered in the 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?
Three sentences, all relevant, with the primary action up front and critical fallback/time caveats included. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the cross-platform and MSIX fallback complexity, the description is robust: it covers fallback behavior, result flag, and timing. With no output schema, it only partially describes the return payload, but the main operational caveats an agent needs are present.
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 special meaning for port or kill_existing beyond the schema, but it does not need to because the schema already documents both 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?
Description states a specific action (Launch TradingView Desktop with CDP enabled) and a clear resource. It is distinguishable from siblings like tv_health_check and tv_update by its launch focus, and adds platform-scanning context.
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 implies this is the way to start the Desktop app for remote debugging, but it never says when to use this tool vs alternatives or mentions any prerequisites/exclusions. With numerous tv_* siblings, explicit routing guidance is 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, the description carries the full burden. It states that it finds elements and returns positions, which implies a read-only operation, but it does not disclose potential side effects, error behavior (e.g., what happens if no element is found), or whether it returns multiple matches or only the first. It does not specify the format of the positions (e.g., coordinates). These are gaps, but for a simple find operation, it is minimally 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, concise sentence that front-loads the verb and resource, and states the output. It wastes no words and is easy to parse. It earns its sentence without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers the core functionality well. It tells what it does and that it returns positions. However, it leaves ambiguity about the return format, whether it finds all matches or just the first, and error behavior. These are minor gaps given the tool's simplicity, but it could be 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 already provides descriptions for both parameters: query (text, aria-label, or CSS selector) and strategy (with enum). The description does not add any new meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not need to compensate.
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 (find), the target (UI elements), and the search methods (text, aria-label, CSS selector). It also mentions the output (positions), which distinguishes it from sibling tools like ui_click or ui_hover that perform actions. The verb 'find' is specific and differentiates it from other UI 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 for locating elements before interacting with them, but it does not explicitly state when to use this tool versus alternatives. It does not mention that it should be used before ui_click or ui_hover, nor does it provide exclusions or alternative tool names. The context of it being a search/find operation is clear, but the guidance is not 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?
With no annotations, the description carries the burden of explaining behavior. It does convey the state-changing and reversible nature of a toggle, but it does not mention side effects, return values, or how the current fullscreen state might interact with the toggle. 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 a single, compact sentence with no filler. Every word contributes meaning, and the operation is fully stated up front.
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 parameterless toggle, the description is functionally complete: an agent knows what action to perform and that no arguments are required. It lacks extra context such as querying state before toggling, but the simplicity of the operation keeps the gap small.
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 there are no semantics for the description to clarify. The baseline of 4 applies because no parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Toggle') and a clear resource ('TradingView fullscreen mode'), leaving no ambiguity about the operation. It also stands apart from the sibling UI tools, none of which mention fullscreen control.
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, when it is appropriate, or what conditions precede calling it. The agent must infer usage solely from the tool name and 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?
With no annotations, the description carries the burden of disclosing behavior, and it does state the mutating effect and the 'active' scope. It does not disclose whether removal is permanent, how invalid symbols are handled, or any side effects on watchlist state.
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 with the action and target front-loaded. No filler or redundant detail.
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 one-parameter, no-output-schema tool, the description plus well-documented schema gives enough context to select and invoke it correctly. Slight gap is lack of detail on error/confirmation behavior, but this is low-risk for a simple removal operation.
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?
Input schema already covers the only parameter with a clear description of bare vs. full symbol formats, so the description adds little parameter-level meaning. Baseline 3 is appropriate because schema coverage is 100% and no descriptor beyond 'one or more' is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states an explicit verb ('Remove') and resource ('one or more symbols from the active TradingView watchlist'), making the action unambiguous. It is clearly distinct from sibling tools like watchlist_add and watchlist_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?
Usage is implied: an agent would call this when it needs to remove symbols from the active watchlist. However, it does not explicitly reference alternatives or state when not to use it, such as when adding symbols or targeting a non-active watchlist.
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 explaining behavior. It discloses that only active alerts are returned, but does not mention response format, pagination, or lack of side effects. The read-only nature is inferable from 'List' but not explicitly stated.
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, front-loaded sentence. There is no wasted wording 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?
Given the zero-parameter schema and no output schema, the description is minimally sufficient for an agent to invoke the tool. However, it does not describe what is returned, how active status is determined, or any limits, leaving some ambiguity for a tool that could return a structured list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to explain parameter details. The baseline of 4 applies because there is nothing missing in parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List active alerts'. It clearly distinguishes this from its alert siblings (alert_create, alert_delete) by indicating a read-only listing operation rather than creation or 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?
There is no explicit guidance about when to use this tool versus alternatives, but the intended usage is strongly implied by the verb and resource. No sibling tool performs a similar list operation, so the risk of confusion is low.
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 disclosure burden. It makes the read-only nature explicit with 'Get' and specifies what is returned (unix timestamps and bars range). It does not mention prerequisites like whether a chart must be open, but for a simple getter the core 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?
One sentence that leads with the action and resource, gives the timestamp format parenthetically, and names the second returned component. Zero 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 zero-parameter getter, this is mostly adequate, but no output schema exists and 'bars range' is left underspecified (e.g., indexes vs count vs offsets). The description names the return categories but does not fully define their structure or units.
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, which is baseline 4. The input schema is empty, so there is no parameter information for the description to clarify or supplement.
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 ('Get'), a specific resource ('visible date range'), an explicit format ('unix timestamps'), and a second resource ('bars range'). This clearly separates it from the setter sibling chart_set_visible_range and from the more general chart_get_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?
There is no explicit guidance about when to use this tool versus alternatives such as chart_get_state or chart_set_visible_range. The usage is only implied by the tool name and the simple 'Get' verb.
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?
There are no annotations, so the description carries the behavioral burden. It discloses the target widget and that it uses an internal API, but it does not mention potential side effects, preconditions, or error behavior. The action itself is simple and clearly described, which keeps this above a 2.
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 with zero filler. It communicates the action, target, and mechanism efficiently.
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 tool with one optional enum parameter, no output schema, and low complexity, the description plus schema fully specify how to invoke it. Nothing needed for a correct call is missing.
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 single action parameter has a clear enum with a default noted. The description repeats the same vocabulary without adding meaning 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?
States specific actions (open, close, toggle) and a concrete resource (the Trading Panel bottom widget paper_trading) plus the internal API used. This clearly distinguishes it from siblings like ui_open_panel by narrowing to the paper_trading widget.
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 or when-not-to-use guidance, and it does not mention ui_open_panel as an alternative. However, the narrow scoping to the paper_trading bottom widget implies that this tool is for that specific panel.
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 correctly signals a read operation and names what is returned, but does not disclose prerequisites (e.g., whether a chart/tab must be open) or whether the indicators list is full details or just names. Adequate for a zero-parameter read, but not riich behavioral context.
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 with zero waste: the verb and resource come first, and the parenthetical enumerates the return contents economically. Every word carries 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 zero-parameter getter with no output schema, the description gives a usable summary of what comes back. The main gaps are the lack of an explicit return shape (a booleans? strings? a structure?) and any prerequisite about an active chart, but the complexity is low enough that this is nearly 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, which is the baseline-4 case per the rubric. There is nothing for the description to explain, and it correctly avoids inventing param 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?
States a specific verb ('Get') and resource ('current chart state') and enumerates the exact contents: symbol, timeframe, chart type, indicators. This clearly distinguishes it from the chart_set_* siblings (mutators) and chart_get_visible_range (a narrower getter for a different aspect of 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?
Usage is implied by the 'Get' verb and the listed state components, but the description never explicitly says when to choose this over related getters like symbol_info, tv_ui_state, or chart_get_visible_range. There are no exclusions or alternative routing, so it sts at implied usage rather than 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 full behavioral burden. It does convey a key behavioral trade-off (summary=true produces compact stats and saves context) and implies a read-only operation, but it does not describe the default output shape, count limits, or chart-relative behavior beyond the schema's parameter 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?
Two short sentences, front-loaded with the primary purpose and then a practical usage tip. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two optional, fully documented parameters, the description plus schema is nearly sufficient. It lacks an explicit statement of the return structure, but no output schema exists and the OHLCV bar concept makes the expected fields reasonably 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 input schema already describes both parameters completely (100% coverage), so the baseline is 3. The description adds value by explaining why summary=true should be used (compact stats, saves context) and clarifies the all-bars vs summary distinction beyond the schema's wording.
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 starts with a specific verb 'Get' and resource 'OHLCV bar data', scoped to 'the chart'. This clearly identifies the tool's function and distinguishes it from siblings like data_get_indicator or data_get_study_values, which target different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is internal to the tool: use summary=true for compact stats instead of all bars to save context. It does not explicitly state when this tool should be preferred over sibling data_get_* tools, though the tool name and purpose make that largely inferable.
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 states the operation is a read ('Read'), describes deduplication behavior, and specifies the returned data shape ('{high, low} price zones'). It could additionally mention edge cases like no matching boxes or sorting, but the essential safety and output traits are 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 with no filler. The main action and output are stated first, followed by a concise parameter hint in the second sentence. Every phrase carries informational weight.
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 simple: two optional parameters, no annotations, no output schema. The description gives the return type, the data source, and a filtering tip, which is sufficient for a basic read operation. It stops short of covering no-match behavior or the format of verbose output, but those are minor given the low 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 schema already fully documents both 'verbose' and 'study_filter'. The description adds only a slight rephrasing of study_filter's purpose ('target a specific indicator') without introducing any meaning beyond what the schema provides, earning the baseline 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 ('Read'), a precise resource ('box/zone boundaries drawn by Pine Script indicators (box.new)'), and clearly states the output ('deduplicated {high, low} price zones'). It is instantly distinguishable from sibling tools like data_get_pine_lines, data_get_pine_labels, and data_get_pine_tables.
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 this tool by naming the box/zone data source, which differentiates it from line/label/table readers. However, it does not explicitly mention alternatives or provide exclusion criteria, and the only guidance ('Use study_filter to target a specific indicator') is parameter-level rather than tool-selection-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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool reads data and returns formatted text rows per table, which covers the core behavior. However, it does not describe edge cases like absent tables, multiple matching studies, or whether the data reflects the current 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences deliver the essential information with no filler. The primary action and target resource are front-loaded, and the parameter guidance is compact. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one optional parameter and no output schema. The description adequately covers the return format and the filtering mechanism. Combined with the fully self-documenting schema, the main missing context is minor—such as how multiple tables are represented or whether an empty result is possible—so it remains sufficiently complete 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?
Schema description coverage is 100%, so the baseline is 3. The description repeats the study_filter parameter and says it targets a specific indicator, which echoes the schema's 'Substring to match study name. Omit for all.' It adds no material new meaning 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 opens with a specific verb and resource: 'Read table data drawn by Pine Script indicators (table.new).' It clearly distinguishes this tool from siblings like data_get_pine_lines, data_get_pine_labels, and data_get_pine_boxes by focusing on tables. The added return detail, 'formatted text rows per table,' further disambiguates its 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 gives clear context for when to use the tool: whenever table data from Pine Script indicators is needed, and it mentions using study_filter to target a specific indicator. It does not explicitly name alternatives or exclusion cases, but the 'table data' scope makes the appropriate use case evident.
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 reveals the precondition of a connected broker but does not disclose whether the operation is read-only, what happens if no broker is connected (error vs empty summary), or any side effects. For a simple getter this is a partial disclosure, but it lacks explicit safety assurances.
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, tight sentence that front-loads the core purpose and includes only essential detail (fields and prerequisite). Every word adds value, and it avoids redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description lists the key return fields and a prerequisite, which is sufficient for an agent to understand what it will retrieve. It does not specify the response structure, but the list of fields is adequate for a simple summary retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no constraints. The baseline for 0 params is 4. The description correctly adds no parameter information because none exist, and it does not need to compensate for any schema gaps.
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 clear resource 'active trading account summary' and enumerates the included fields (balance, equity, PnL, margin, available funds). This distinguishes it from sibling tools like 'list_accounts' which retrieves all accounts, and 'switch_account' which changes the active account, making its 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a clear prerequisite ('Requires a broker connected'), which is useful. However, it does not explicitly compare to alternatives or specify when to use this tool over others like 'list_accounts' or 'switch_account'. The usage context is implied but not fully spelled out.
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 clearly states the side effect ('add a result to the chart'), the supported scope ('strategies and community scripts'), and the return value ('Returns the new study entity_id'). This is sufficient transparency for a straightforward additive operation, though it does not discuss any prerequisites like an open chart.
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 with no filler. It front-loads the core action, then adds scope and return-value information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description is nearly complete: it states the action, scope, and return value. It could arguably mention that a chart/workspace context must exist, but the schema and tool name make that reasonably inferable.
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 query, match, and section. The description adds contextual meaning around 'by name' and the search-to-add flow, but it does not need to repeat parameter details. A 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 uses a specific verb ('Search ... and add ... to the chart by name') and identifies the resource and result ('Returns the new study entity_id'). It distinguishes itself from sibling tools like indicator_search by clarifying it actually adds a study, and broadens scope by covering strategies and community scripts.
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: when adding an indicator or strategy to a chart by name. It notes that it works beyond built-ins, which helps with selection, but it does not explicitly mention alternatives like indicator_search for look-ups or chart_manage_indicator for managing existing indicators, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It does convey a read-only intent and the active-vs-history behavior, but it does not mention account scope, pagination, ordering, or return shape. For a simple listing tool 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 compact sentence with no filler. It front-loads the core purpose and places the default-mode clarification in a parenthetical, making it easy to scan.
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-optional-parameter list tool, the description plus schema is sufficient for an agent to invoke it correctly. The lack of an output schema and annotations leaves some ambiguity around the exact return shape, but the tool is straightforward enough that the description is nearly 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?
Schema coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema by stating the default behavior ('active by default') and how the history flag changes the result set, which clarifies the parameter's role without needing to inspect 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 states a specific verb ('List') and resource ('trading orders'), and immediately clarifies the default mode (active) versus optional history. This clearly distinguishes it from order-mutating siblings like place_order/cancel_order/modify_order and from list_positions/data_get_trades.
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 through 'List trading orders' and the active/history distinction, but it provides no explicit guidance about when not to use it or which sibling alternatives to prefer. Context is implied rather than spelled out.
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 behavioral disclosure burden. It transparently explains that the tool does not compile, works offline, and targets specific static-analysis issues. It does not mention whether the analysis is read-only or what kind of output is returned, but the described behavior is clear and non-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, dense sentence with no filler. The core behavior is front-loaded, and the distinctive details ('WITHOUT compiling', 'Works offline') plus specific checks follow naturally without wasting 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 tool with one simple string parameter and no nested objects, the description is sufficient for an agent to select and invoke it. The main gap is the lack of stated return format or behavior for valid code, but the description's phrase 'catches ...' strongly implies diagnostic output, which may be enough for this simple 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?
The schema already documents the single parameter with high coverage ('Pine Script source code to analyze'). The description reinforces that the source is Pine Script code but adds no additional semantic detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Run static analysis on Pine Script code') and lists concrete diagnostic categories (array out-of-bounds, unguarded array.first()/last(), bad loop bounds, implicit bool casts). It distinguishes itself from compiling tools by saying 'WITHOUT compiling', though it does not explicitly differentiate itself from the similarly named sibling pine_check.
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: it is for static analysis, works offline, and does not require a TradingView connection. It implies this is a faster/safer alternative to compiling but does not explicitly state when to use it over alternatives like pine_compile or pine_check.
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 present, so the description must carry the behavioral burden. The verb 'Get' indicates a read-only operation with no side effects, but the description does not disclose what happens if no editor is active, whether unsaved buffer changes are included, or the return format. For a simple getter this is likely sufficient, but it leaves some behavioral edges unstated.
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 identifying the verb, resource, and location, making it efficiently scannable for an agent.
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 that the tool has no parameters and no output schema, the description covers the essential call semantics: it returns the current Pine Script source from the editor. It is slightly thin around edge cases and sibling differentiation, but for a zero-input getter this is nearly 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 takes zero parameters, and the input schema is an empty object with 100% coverage by definition. Per the baseline for 0-parameter tools, the description need not explain parameter syntax; it only needs to communicate the purpose, which it does.
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 the specific verb 'Get' and names the exact resource ('current Pine Script source code') plus its location ('from the editor'). This clearly distinguishes it from sibling tools like pine_set_source (which writes) and pine_get_errors/pine_get_console (which retrieve other data). 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 gives no explicit when-to-use guidance or alternatives; usage must be inferred from the tool name and the editor scope. While 'current ... from the editor' implies a use case (retrieve the active script source), it does not contrast with pine_list_scripts or other pine_* siblings. This is adequate context but no exclusions, 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 the full burden. It communicates a read-only 'get' behavior and names the state categories returned, which is useful. However, it does not disclose whether a live UI session is required, whether the call has side effects, or what error conditions might exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence. It front-loads the core action and resource ('Get current UI state') and then provides brief, relevant specifics about panels and button states, with no filler or redundant 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 zero-parameter read-only state tool, the description is largely complete: it tells an agent what to expect conceptually. The main gap is that there is no output schema and the description does not specify the exact return representation or possible error conditions, but the tool's simplicity keeps this from being a major deficiency.
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. There is no parameter surface for the description to clarify, and the description instead adds value by explaining what aspects of UI state are covered.
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 direct resource ('current UI state'), then adds concrete details about what that includes: open panels and visible/enabled/disabled buttons. This clearly differentiates it from mutating siblings like ui_click or ui_open_panel, which change the UI rather than report on it.
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 should be used when an agent needs to inspect current UI conditions rather than change them. However, it never explicitly states when to use this tool versus similar state-reading tools like chart_get_state, replay_status, or get_status, and it does not mention any prerequisites or exclusions.
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 discloses that the tool reads current values and only for visible studies, which is useful. But it does not describe the output format, whether values are last-bar snapshots or series, or how multiple studies like Bollinger Bands are represented.
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 with a helpful parenthetical list of study types. Every word contributes 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 with no parameters, but it also has no output schema. The description names the data source and scope but remains vague about the returned structure, which matters for an agent consuming the result programmatically. It is adequate but leaves room for clarification.
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 and the schema is fully empty, so there is no parameter information that the description needs to add. 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 clearly states a specific verb ('Get'), a specific resource ('current indicator values from the data window'), and a precise scope ('all visible studies'). It also gives concrete examples (RSI, MACD, Bollinger Bands, EMAs, custom indicators), which makes the tool's function unmistakable and distinguishes it from sibling 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'all visible studies' gives clear context for when this tool is appropriate. However, it does not explicitly state when to prefer a sibling tool like data_get_indicator for a single indicator, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the key side effect: a new tab opens. It does not detail effects on the currently active layout or whether the new layout is immediately saved, but for a simple create action the core 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?
One sentence with no filler. The core action and the notable side effect are front-loaded, making the description efficient and easy to parse.
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?
This is a simple tool with one optional parameter and no output schema. The description combined with the schema fully covers what the agent needs to invoke it correctly: what it creates, how the UI responds, and the parameter semantics.
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 'name' parameter, and the schema already explains its meaning and default value. The description adds little parameter-specific detail beyond naming the layout as 'blank', which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create'), identifies the resource ('new named blank chart layout'), and adds the observable detail that it opens in a new tab. This clearly distinguishes layout_new from sibling tools like layout_list and 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by 'Create', but there is no explicit guidance on when to choose this tool over alternatives such as layout_list or layout_switch, nor any mention of prerequisites or conditions that would make another tool more appropriate.
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 disclosure burden. It explicitly states the operation is a read ('Read'), and adds a useful behavioral trait: 'Returns deduplicated price levels per study.' It does not mention what happens when no matching study or lines exist, and it omits output-shape details, but the core behavior is clearly 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?
Two short sentences, each earning its place: the first establishes the tool's purpose and input, the second explains the return behavior and filtering. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with no output schema, the description is nearly complete: it states what is read, the deduplication behavior, and how to target a study. It just stops short of describing the returned shape or empty-result behavior, but the schema covers parameter details and the operation is simple enough not to require more.
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 fully documents both parameters. The description reinforces study_filter with 'Use study_filter to target a specific indicator,' but adds no new parameter semantics beyond what the schema provides; hence 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 names a specific verb, resource, and scope: 'Read horizontal price levels drawn by Pine Script indicators (line.new).' It clearly distinguishes this from sibling data_get_pine_labels/boxes/tables by focusing on horizontal price levels and line.new, and additionally states the deduplicated per-study output.
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 it: to read horizontal Pine line levels, with 'Use study_filter to target a specific indicator' as explicit parameter guidance. It does not explicitly contrast it with alternatives like data_get_pine_labels or data_get_study_values, so it misses the full 'avoid when...' 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?
With no annotations, the description carries the behavioral burden. It clearly frames the operation as a status report (implying read-only) and adds useful behavioral semantics: safe_for_paper_mutation is true when a broker is connected. It does not discuss error cases or exact output shape, but for a status tool the disclosed behavior is solid.
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 states the purpose first, then uses a colon-delimited list of status components. Every phrase adds information, and the mutation-safety clause earns its place as a meaningful behavioral qualifier.
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 status tool with no output schema, the description enumerates the key returned status categories and explains the important safety flag. It is nearly complete, though exact output formatting or behavior when disconnected is not specified.
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?
There are zero parameters, so the baseline is 4. The description correctly adds no parameter-level detail because none exists; nothing about the input schema needs 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 uses a specific verb ('Report') with a clear resource ('TradingView trading status') and enumerates concrete status categories: desktop CDP, auth session, Trading Panel, connection, active broker id, and mutation safety. This distinguishes it from other status-like siblings by listing the exact scope of what is reported.
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 use is implied by the definition: call this when you need TradingView connection/auth/broker state. However, it does not explicitly mention when to prefer this over siblings like tv_health_check or get_account, and there are no exclusions or alternative routing cues.
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 behavioral burden. It discloses that compilation happens server-side, does not require a chart, and returns errors/warnings. This gives an agent a reasonable mental model of the tool's behavior, though it does not mention rate limits, authentication, or whether any state is modified.
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?
Three concise sentences, each earning its place: what the tool does, what it returns, and when to use it. The most important differentiating detail—'without needing the chart open'—is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single string parameter and no output schema, the description covers the essential purpose, behavior, and return type. It does not detail the error/warning return structure, but it provides enough context for an agent to select and invoke the tool correctly for validation.
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 'source' parameter as 'Pine Script source code to compile/validate', and the description adds no additional parameter-level meaning. Since schema description coverage is 100%, 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 compiles Pine Script via TradingView's server API and returns compilation errors/warnings. The phrase 'without needing the chart open' distinguishes it from chart-dependent sibling tools like pine_compile or pine_set_source. This is a specific verb+resource description that an agent can act on immediately.
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 a clear use case: validating code before injecting it into the chart, and notes that no open chart is required. It does not explicitly name alternative sibling tools or state when not to use them, so it falls short of a full when/when-not guideline.
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 disclosing behavior. 'Stop replay and return to realtime' directly conveys the action and outcome, which is sufficient for a simple zero-parameter command. It does not mention edge cases like calling it when replay is not active, but for this tool's scope the core behavior is clearly 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 six-word phrase that efficiently captures the entire purpose and outcome. There is no filler, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, no parameters, and no output schema, the description is largely complete: it states the action and the resulting state. It could slightly improve by mentioning prerequisites, such as replay needing to be active, but this is not a critical gap for a no-argument stop command.
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 already fully documents parameter expectations. The description does not need to add parameter semantics, and the baseline for a no-parameter tool 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 verb ('Stop') and resource ('replay') and adds the outcome ('return to realtime'), which clearly distinguishes this tool from siblings like replay_start, replay_step, replay_autoplay, and replay_trade. An agent can immediately understand what action this tool performs.
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 phrasing conveys that the tool should be used when replay is active and the user wants to exit back to live data. However, it does not explicitly state when not to use it or point to alternatives such as replay_status for checking state or replay_step for continuing.
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 or output schema, the description carries the full behavioral burden. It communicates a read-only listing action and specifies the output content (panes with symbols and active state), which is sufficient for a simple, side-effect-free tool. It does not detail return formatting or ordering, but these are minor for this 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?
A single, front-loaded sentence states the action, object, scope, and included output fields. Every part is informative and there is no redundancy 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?
For a zero-parameter listing tool, the description is nearly complete: it identifies the object type, scope, and returned attributes. It could marginally clarify the structure of 'active state' or how panes are ordered, but an agent can reasonably invoke the tool with the provided information.
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 there is nothing for the description to explain beyond stating the operation's scope. The baseline for zero-parameter tools is 4, and the description appropriately adds no redundant 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 ('List') with a clear resource ('all chart panes in the current layout') and states what is included ('symbols and active state'). It is easily distinguishable from sibling tools like layout_list, pane_set_symbol, or chart_get_state.
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 scopes usage to the current layout, which tells an agent when this pane-specific list is relevant. It does not explicitly mention alternatives like layout_list for listing layouts, but the context is sufficiently clear for choosing this tool over pane-related mutations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and succeeds. It explicitly discloses that providing a non-current symbol causes a temporary chart switch, a ~1-2s delay, and serialization of parallel calls—non-obvious side effects that materially affect invocation and concurrency expectations.
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 with no filler: the first states the core purpose and fields, the second fronts the critical side-effect and performance caveat. Every sentence earns its place and the most actionable warning appears early.
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 one-optional-parameter read tool with no output schema, this is complete: it covers what is returned, how the parameter behaves, the side-effecting case, and the performance cost. An agent can safely decide whether to call it and what to expect without further investigation.
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 already covers 100% of parameter meaning, giving a baseline of 3. The description adds value by explaining the behavioral consequence of a non-blank symbol and the restore guarantee, going slightly beyond the schema's 'chart switch + restore' note with timing and serialization 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?
States a specific action ('Get real-time quote data') and concrete resource (a symbol), and enumerates the returned fields (price, OHLC, volume). The term 'real-time' and 'quote' distinguish it from historical data tools like data_get_ohlcv and metadata tools like symbol_inf o, even though it does not name them explicitly.
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?
Provides clear contextual guidance on the symbol parameter: blank means current chart symbol, while a non-blank different symbol triggers a switch-and-restore with a ~1-2s cost. However, it does not state when to choose this tool over alternative quote, OHLCV, or symbol-information tools, so the cross-tool routing is left implied.
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 itself carries the behavioral burden. The verb 'Get' clearly implies a read-only operation, and the description states exactly what data is returned (last price, change, change%). It does not mention rate limits or failure modes, but for a simple zero-parameter read, 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?
A single sentence that is front-loaded with the essential action and resource, with no filler. Every word contributes to understanding what the tool does and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no annotations, and no output schema, the description fully covers what an agent needs to know: the action, the target resource, and the returned fields. Nothing essential is missing.
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 schema description coverage is 100%, so there is nothing for the description to add. Baseline 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific verb 'Get', the resource 'all symbols from the current TradingView watchlist', and the returned fields. It clearly distinguishes itself from sibling tools like watchlist_add and watchlist_remove.
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 'Get all symbols from the current TradingView watchlist' makes the use case clear: call this when you need the current watchlist contents. It does not explicitly name alternatives or exclusions, but the read-only intent is apparent from 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full transparency burden. It explicitly discloses that calling the tool auto-opens the panel and auto-unhides a hidden strategy, explains the TradingView reason, and warns that the result can include unhidden_strategies. This is exactly the sort of non-obvious behavior an agent needs to know.
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 with no filler: the first states the core purpose, and the second packs the critical side effects, the reasoning, and the conditional result field. Every clause earns its place and the important caveats are 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 parameterless tool this is nearly complete: the agent knows what action it performs, what side effects to expect, and one conditional field in the result. A minor gap is that the full set of returned performance metrics is not enumerated, and there is no output schema to fill that in.
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 there are no parameter semantics to clarify. Per the baseline rule for zero-parameter tools, this is a 4; the description does not need to compensate for missing param documentation.
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 a precise verb and resource: 'Get strategy performance metrics from Strategy Tester.' This makes the tool's function immediately clear and differentiates it from sibling data_get_* tools that retrieve OHLCV, study values, or pine objects.
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?
'From Strategy Tester' provides clear context for when this tool is the right choice and separates it from the other data retrieval tools in the sibling list. It does not explicitly name alternatives or say 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool performs a git operation, conditionally runs npm ci, has safety guardrails, and requires a restart after successful updates. This is highly transparent for a mutating maintenance 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?
Three concise sentences, each earning its place: purpose and mechanism, safety conditions, and post-condition. The primary action is front-loaded and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the call's side effects, preconditions, and post-conditions well, including the critical restart requirement. The only notable gaps are return/error behavior and potential server downtime during the update, but the restart warning mitigates the latter. For a zero-argument maintenance tool, this is quite 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 has zero properties and the tool takes no parameters, so the schema is trivially 100% described. The description adds no parameter semantics because none exist; per the zero-parameter baseline, a 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?
States a specific verb and resource: 'Update this MCP server to the latest version' — clear and unambiguous. It then details the exact mechanism (git fast-forward of origin/main + npm ci), which further distinguishes it from the many sibling tv_* tools like tv_health_check or tv_launch. No other tool in the sibling list performs a self-update, so it is easily differentiated.
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?
Clearly implies when to use the tool (to update the MCP server) and provides explicit refusal conditions: non-git installs, dirty working trees, non-main branches, or diverged history. It also warns that a restart is required after success. However, it does not explicitly compare to alternative tools, though none exist in the sibling list, so the guidance is mostly 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ezydubs/tradingview-mcp'

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