Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the mutation profile ('STATE_MUTATING (Creates an active alert in user account)') plus a constraint ('Requires market symbol to be active'). It omits permission/auth requirements and whether an existing alert is replaced or duplicated, but the essential side-effect is explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action, then separates WHEN TO USE, SIDE EFFECTS, and LIMITATIONS into labeled clauses – easy to scan. Slightly redundant between 'open the dialog' and 'create a server-side alert', keeping it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description supplies purpose, trigger conditions, side effects, and a precondition. It could say more about permissions or the returned alert handle, but nothing critical for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 price, message, and condition. The description's parenthetical condition list mirrors the schema's own enum examples, adding little new meaning, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('create a server-side price alert') and even the mechanism (TradingView alert configuration dialog). An agent can distinguish it from siblings alert_list and alert_delete without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' clause explicitly scopes the tool to conditional price triggers and names the relevant conditions (crossing, greater_than, less_than). It does not name alternatives (e.g., alert_list/alert_delete) or state when-not-to-use, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose that this is STATE_MUTATING and deletes from the user account. It also documents the delete_all limitation. It stops short of stating permanence, required scopes, or failure behavior, so it is good but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short labeled sections (WHEN TO USE, SIDE EFFECTS, LIMITATIONS) front-load the essential information with no wasted wording. The structure makes it easy for an agent to scan the key constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter delete tool with no output schema and no annotations, the description covers purpose, usage, side effects, and the delete_all option. It omits return/error behavior, but the core decision and invocation inputs are well covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is already documented in the schema. The description's 'Pass delete_all: true to clear all alerts' largely repeats that, adding only minor usage framing, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and resource (active alerts from TradingView alerts list), and the action is clearly distinct from sibling tools alert_create and alert_list. An agent can tell this removes alerts rather than displaying or creating them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section gives clear triggering conditions: removing triggered, obsolete, or batch alerts. It does not explicitly name alternatives or when not to use it, but the context is sufficiently clear for correct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden and does a solid job by declaring 'SIDE EFFECTS: None (Read-only)' and a scope limitation ('Reads alerts visible in alerts dock'). It could say more about the shape of returned alerts, but the safety profile is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three labeled sections with zero filler; the core purpose is front-loaded ahead of the WHEN TO USE, SIDE EFFECTS and LIMITATIONS labels. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only list tool with no output schema, the description covers purpose, usage, side effects and visibility limits adequately. It lacks detail on the returned alert fields, which is a minor gap given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb (List) and resource (alerts), and adds scope ('active and triggered alerts from the TradingView alerts panel'). It is clearly distinguishable from alert_create and alert_delete by its read/list nature, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' clause gives clear context: inspect active triggers or verify created alerts. It stops short of naming alternatives or when-not conditions (e.g., use alert_create to add one), so it is good but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it flags STATE_MUTATING, discloses that it navigates chart symbols/timeframes and may write screenshot files, and notes sequential execution with a configurable delay. It omits permission/auth requirements and failure behavior, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three front-loaded sentences with labeled sections (WHEN TO USE, SIDE EFFECTS, LIMITATIONS) and zero filler. The action enumerated up front immediately orients the agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-param, state-mutating batch tool with no output schema, it covers side effects and sequencing constraints, which is the critical missing piece. It does not describe what the batch returns (e.g., per-symbol results or errors), but the essential invocation context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 five parameters with examples and defaults. The description only restates the action list and does not add syntax or format meaning beyond the schema, giving the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Execute) and resource (sequential analytical action across arrays of symbols/timeframes) and enumerates the three concrete actions. It clearly distinguishes itself from single-target siblings like data_get_ohlcv or capture_screenshot by its cross-asset, multi-timeframe batching scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit 'WHEN TO USE' clause names three concrete scenarios (automated screening, batch chart captures, cross-asset data collection). It does not, however, name when to prefer single-target siblings instead, so it stops short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the external side effect of writing a PNG file to disk, the limitation that the TradingView window must be rendered on screen, and the rationale for returning a filesystem path instead of base64. This gives an agent the safety and operational context it needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is front-loaded with the core action and then uses clear labeled sections for WHEN TO USE, SIDE EFFECTS, and LIMITATIONS. Every sentence contributes useful information without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter tool with no output schema and no annotations, the description covers purpose, usage context, side effects, limitations, and the return value sufficiently. An agent has enough information to call it correctly and understand the main operational risks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 region, method, and filename. The description repeats the region enum values and otherwise adds no syntax, format, or default information beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: capture a lossless PNG screenshot of the TradingView window and save it locally. It also lists valid regions and the return type. However, it does not distinguish itself from the sibling chart_get_snapshot, which may also produce chart imagery, so sibling differentiation is missing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section gives clear context: call when the user requests visual verification of chart patterns, drawings, or UI layout. There is no explicit when-not-to-use guidance or named alternative such as chart_get_snapshot, so it falls just short of the top score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it declares read-only behavior ('safely preserves original chart state'), atomicity ('without race conditions'), and the state-restoration limitation. It omits permission requirements and any latency/rate considerations, but the safety profile is genuinely better disclosed than most.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then segmented into WHEN TO USE / SIDE EFFECTS / LIMITATIONS labels that make scanning fast. Every sentence earns its place; only slight redundancy between the opening sentence and the LIMITATIONS line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, zero-required-param tool with no output schema, the description covers purpose, trigger, safety, and the state-mutation caveat. An agent has enough to call it correctly; only the return shape and behavior on invalid timeframes are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters (count, symbol, timeframes) are already documented with defaults in the schema. The description only echoes the timeframe list and implied bar counts, adding no syntax or format detail 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('atomic sequential multi-timeframe scan across multiple resolutions') plus concrete resolution examples. It reads clearly as the multi-timeframe OHLCV fetcher, which differentiates it from single-timeframe siblings like data_get_ohlcv, though it never names that alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'WHEN TO USE' clause gives a clear triggering condition: needing raw OHLCV bars across several timeframes in one coordinated operation. It lacks a when-not clause or a named alternative, so the agent must infer when a single-timeframe fetch is preferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full behavioral burden and does so well: 'SIDE EFFECTS: None (Read-only)' declares the safety profile and 'LIMITATIONS: Lightweight snapshot only' scopes what it will not do. It omits any note on response timing, staleness guarantees, or error behavior, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly three front-loaded clauses with labeled WHEN TO USE, SIDE EFFECTS, and LIMITATIONS sections. Every sentence carries distinct information and the core action plus returned fields lead the text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, and the description compensates by listing exactly which fields the snapshot contains plus its read-only, lightweight nature. For a zero-parameter read tool, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema baseline of 4 applies; there are no argument semantics for the description to clarify or compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get authoritative atomic snapshot of chart state') and enumerates the returned fields (symbol, resolution, lastBarTime, barCount, generation ID), making the tool's scope concrete. However, it never names sibling chart_get_state or chart_get_state_diagnostics, so an agent cannot be fully certain which state-reading tool to pick without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit 'WHEN TO USE' clause gives clear context: verify state freshness or obtain atomic synchronization metadata without pulling full bar series. The 'Lightweight snapshot only' limitation implies when not to use it, but no alternative sibling is named as an explicit substitute, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the safety burden and does so well: it declares SIDE EFFECTS: None (Read-only) and a LIMITATIONS constraint (requires an active chart window), which is valuable behavioral context. It stops short of describing return shape or failure behavior, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-sentence payload summary followed by clearly labeled WHEN TO USE, SIDE EFFECTS, and LIMITATIONS blocks. Every sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no output schema, the description fully covers purpose, invocation timing, safety profile, and the precondition (active chart window). An agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema cannot be a source of confusion and the baseline is 4. The description appropriately spends no space on parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 returned payload: active symbol, timeframe resolution, chart rendering type, and attached indicator study entities with IDs. This distinguishes it clearly from siblings like chart_get_visible_range or data_get_ohlcv.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE block gives explicit context (inspecting chart configuration) and names the exact follow-up tools it feeds (chart_manage_indicator, indicator_set_inputs), which is precisely the prerequisite routing an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden; it does disclose read-only behavior via 'NO SIDE EFFECTS' and describes what is inspected ('authoritative' liveness/queue/freshness data). It does not cover permissions, response shape, or any caveats about the diagnostic values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: capability, then a front-loaded WHEN TO USE trigger list, then a side-effects disclaimer. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only diagnostic tool with no output schema, the description is nearly self-sufficient: it names the returned fields and the safety profile. Only the exact return format and any error semantics are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema contributes nothing and there is nothing for the description to disambiguate. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('diagnostic state of chart') and enumerates the contents: generation ID, CDP connection status, task queue depths. Clear enough to distinguish from the sibling chart_get_state, though it never explicitly contrasts the two.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'WHEN TO USE' block names three concrete triggers (diagnosing connection liveness, queue backpressure, verifying generation freshness). No 'when not' clause or named alternative, but the context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well: it declares 'SIDE EFFECTS: None (Read-only)' so the agent knows it is a safe read, and 'LIMITATIONS: Depends on active screen width and zoom level' warns that results vary with viewport state. It does not discuss failure behavior when no chart is loaded, but the safety and limitation disclosure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three labeled sentences, front-loaded with the payload description, then routing guidance, then caveats. Nothing is wasted and the structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey what comes back, and it does: a date range in unix seconds plus bar index boundaries. Combined with the read-only and viewport-dependency notes, an agent has everything needed to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies no input is needed and instead documents the output semantics (unix seconds, bar index boundaries).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource ('Get visible date range ... and bar index boundaries currently displayed on the viewport') and even specifies the units of the returned timestamps. An agent can distinguish it from the sibling chart_set_visible_range, which mutates the range rather than reading it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE clause gives concrete triggers ('before capturing screenshots or inspecting what portion of the historical timeline is in user view'). It stops short of naming the complementary setter tool or stating when not to call it, so it is clear context without explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the key traits: 'STATE_MUTATING (Modifies chart study collection)' and the hard limitation that full official TradingView names are required ('Relative Strength Index', not 'RSI'). It does not discuss reversibility, persistence, or failure modes when a name is wrong, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action, then cleanly partitioned into WHEN TO USE, SIDE EFFECTS, and LIMITATIONS. Every sentence carries information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description supplies the side-effect warning, the naming constraint, and the entity_id source. Only minor gaps remain, such as what happens on an invalid name or whether removal needs confirmation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 adds real value beyond the schema by stating that entity_id must come from chart_get_state and by reinforcing the exact-name requirement for 'indicator'. The 'inputs' override parameter is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair (add/remove) plus the resource (built-in or public indicator/study) and the scope (active chart). Reads clearly as a mutation tool for the study collection, distinguishing it from siblings like indicator_set_inputs or indicator_toggle_visibility.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'WHEN TO USE' section names the trigger (attach technical studies, remove via entity_id) and points to chart_get_state as the source of entity_id. It does not explicitly contrast against sibling tools such as indicator_set_inputs, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does disclose the key trait: SIDE EFFECTS: STATE_MUTATING (scrolls chart canvas), plus a LIMITATIONS note that historical data must exist. It stops short of permissions/auth context, but the mutation and precondition disclosure is meaningful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then uses compact labeled sections (WHEN TO USE, SIDE EFFECTS, LIMITATIONS). No sentence is redundant and the structure scans quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter navigation tool with no output schema, the description covers purpose, trigger scenarios, the state-mutating side effect, and a data-availability precondition. That is nearly everything an agent needs, with only the sibling-alternative boundary left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the sole 'date' parameter is already fully documented in the schema, including format (ISO string or unix timestamp as string). The description adds no format or syntax detail beyond it, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Jump the chart viewport to center on a specific historical calendar date or timestamp.' The centering-on-a-historical-date behavior distinguishes it from sibling tools like chart_set_visible_range and chart_get_visible_range.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section gives concrete triggering scenarios (navigating to a past release, news event, or breakout bar), which is strong positive guidance. However, it does not name alternative tools (e.g., chart_set_visible_range) for viewport navigation, so the agent must infer the boundary itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so well. It explicitly discloses STATE_MUTATING behavior, ticker alteration, state generation increment, generational cache invalidation, and that the tool waits for market data feed confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action, then uses clear labeled sections for WHEN TO USE, SIDE EFFECTS, and LIMITATIONS. Every sentence earns its place and the structure is easy for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-annotation mutation tool with no output schema, the description is complete. It tells the agent what the tool does, when to call it, what side effects occur, and what format the symbol must satisfy.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so the baseline is 3. The description adds value by stating the TradingView ticker format requirement and giving examples beyond the schema's own example list, though it largely mirrors the schema's parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Change the active chart symbol and wait for market data feed confirmation.' It clearly scopes the action to the active chart symbol, which distinguishes it from sibling tools like chart_set_timeframe, chart_set_type, and 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section gives clear context: 'Call to navigate the chart to a new financial instrument before performing analysis or running strategies.' However, it does not name alternatives such as symbol_search or pane_set_symbol, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it flags STATE_MUTATING, cache invalidation, state-generation increment, and that the call blocks until candle feed resolution. It omits failure modes (unsupported timeframe, no active chart) and any permission/precondition requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then labeled sections for usage, side effects, and limits. Slightly dense in the parenthetical side-effect block, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

One required parameter, no output schema, and the description covers usage, mutation semantics, blocking behavior, and accepted formats. Remaining gaps (what happens on an invalid timeframe, whether a chart must already exist) are modest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), and the LIMITATIONS line adds value the schema lacks — the schema declares no enums, so the explicit list of standard minutes ("1","5","15","60","240") and calendar periods ("D","W","M") is genuinely additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb (change) plus resource (chart timeframe/resolution) and adds the blocking behavior, which distinguishes it from sibling chart_get_multi_timeframe (read-only multi-series) and chart_set_symbol/chart_set_type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE line gives a concrete trigger (switching resolutions for multi-timeframe analysis) with an example (1D to 15m). It does not, however, name an alternative or exclusion — e.g. it never says to use chart_get_multi_timeframe instead when you only want to read several resolutions without mutating state.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and discloses a key behavioral trait: 'SIDE EFFECTS: STATE_MUTATING (Modifies chart canvas display mode).' It also states a limitation that it accepts chart type name or numeric index, though it does not discuss persistence or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and structurally segmented with clear labels for use, side effects, and limitations. Every sentence earns its place without repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter mutation tool with no output schema, the description covers purpose, usage context, side effect, and accepted input form. It is complete enough to call correctly, though it does not specify the active chart context or failure conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already maps every chart type to its numeric index. The description adds only that a name or numeric index is accepted, which is already implied by the schema, so it meets the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 chart candle rendering type.' It gives examples (Bars, Candles, Line, Area, Renko, HeikinAshi) and distinguishes this from sibling chart-setting tools like chart_set_symbol and chart_set_timeframe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly provides a WHEN TO USE section: 'Call when specific analysis requires alternate bar representations (e.g., Heikin Ashi for trend smoothing).' This gives clear context, though it does not name alternatives or 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses STATE_MUTATING (viewport zoom/pan changes) and the constraint that timestamps must be unix seconds within the historical data range. It omits whether the change is reversible/undoable and how out-of-range input is handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action, then labeled WHEN TO USE / SIDE EFFECTS / LIMITATIONS sections that are each a single sentence with no filler. The label scaffolding is mildly formulaic but costs little and aids scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-param mutation tool with no annotations and no output schema, the description covers the essential gaps: effect, trigger, and input constraints. Remaining omissions (failure behavior for out-of-range timestamps, whether the view can be restored) are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both params are documented there, so baseline is 3. The description adds genuine meaning beyond the schema by specifying the unit (unix seconds) and the validity constraint (within historical data range), which the schema text does not mention.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource: 'Zoom and pan the chart canvas to display a specific date range.' The mutating counterpart to chart_get_visible_range and chart_scroll_to_date is clear from 'set' + 'zoom and pan', but the description never names those siblings to sharpen the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('Call when focusing chart context on a specific historical event or earnings release'), which is real when-to-use guidance. It does not name alternatives (chart_scroll_to_date, chart_get_visible_range) or state when not to use it, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does disclose that the operation is read-only with no side effects, plus a real precondition ('Strategy Tester must be active on chart'). It stops short of describing data volume, pagination, time granularity, or failure behavior when the tester is inactive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three labeled, front-loaded sentences covering action, trigger, side effects, and limitation with zero filler. An agent can parse the key facts in a single pass.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, parameterless extractor with no output schema, the description covers purpose, trigger, safety, and preconditions adequately. It leaves the return shape (what a 'data point' contains, sampling cadence, size limits) unstated, which is the main residual gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the documented precondition (active Strategy Tester) is the only input-like constraint and it is stated. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Extract') and a specific resource ('equity curve data points') plus the source system ('Strategy Tester'). This cleanly separates it from siblings like data_get_trades, data_get_strategy_results, and data_get_ohlcv, which return different artifacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'WHEN TO USE' block names concrete scenarios: analyzing drawdowns, run-ups, or plotting performance trajectory. It gives positive selection criteria but never states when not to use it or which sibling (e.g. data_get_strategy_results) to prefer instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and does so reasonably: it declares 'SIDE EFFECTS: None (Read-only)' and a precondition ('Requires valid entity ID'). It omits what happens on an invalid or stale ID and does not characterize the returned payload, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short labeled segments, front-loaded with the core purpose before WHEN TO USE, SIDE EFFECTS, and LIMITATIONS. Every clause carries information and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no output schema, the description supplies purpose, trigger, side-effect profile, and precondition. It only lightly sketches the return content ('parameters, input values, configuration') and says nothing about the response shape or nesting, a minor gap given there is no output schema to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With a single parameter at 100% schema description coverage, the schema already documents entity_id as the study entity ID from chart_get_state. The description's 'by ID' adds no syntax, format, or sourcing detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('internal study parameters, input values, and configuration of a specific indicator entity by ID'), which is far beyond a tautology of the name. It implicitly separates configuration inspection from sibling tools like data_get_study_values (computed values) and indicator_set_inputs (mutation), though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' block gives a concrete trigger: inspecting active parameters such as RSI length or MA source for an indicator obtained from chart_get_state. It lacks explicit when-not-to-use guidance and does not route the agent to alternatives (e.g., indicator_set_inputs for changing values), so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it declares SIDE EFFECTS: None (read-only) and LIMITATIONS: Maximum 500 bars per request, and explains the closedOnly option's intent (avoiding unconfirmed candle hallucinations). It omits auth/permission requirements and any error or latency behavior, keeping it just below full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then cleanly partitioned into WHEN TO USE, SIDE EFFECTS, and LIMITATIONS blocks. Every sentence earns its place and scanning for a specific fact is trivial.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter, no-annotation, no-output-schema tool, the description covers the essential behavior: read-only nature, the 500-bar cap, and the two behavioral flags. The assertion parameters (expectedTf/expectedSymbol) and the default count live only in the schema, which is acceptable since they are well-documented there, leaving only minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 count, summary, closedOnly, expectedTf, and expectedSymbol. The description restates the summary and closedOnly semantics (and adds a rationale for each) but supplies no syntax or format detail 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Get historical OHLCV bar data from active chart") plus the scope (active chart), which comfortably distinguishes it from image-based siblings like chart_get_snapshot. However, it does not explicitly name or route against close neighbors such as chart_get_multi_timeframe or data_get_trades, so the differentiation is implicit rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit WHEN TO USE clause (computing quantitative models or inspecting raw price action) and a conditional (use summary:true when only high/low/close bounds are needed to conserve context). It gives clear context but never states when NOT to use it or names an alternative tool, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full disclosure burden and rises to it: it declares 'SIDE EFFECTS: None (Read-only)' and a capability LIMITATION ('Only reads box primitives generated by active studies'). It omits details like behavior when no boxes exist or deduplication mechanics, but the safety and scope profile is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, then uses labeled clauses (WHEN TO USE, SIDE EFFECTS, LIMITATIONS) for scannability. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully characterizes the return value as deduplicated {high, low} price ranges, and covers scope and safety for a 2-param read-only tool. Edge cases (empty results, inactive studies) are not addressed, but the definition is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema; the description's mention of 'deduplicated' ranges loosely maps to the verbose flag but adds no syntax or format guidance beyond it. Baseline 3 applies since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read bounding boxes and zones drawn by Pine Script indicators') and even characterizes the output shape ('deduplicated {high, low} price ranges'). This clearly differentiates it from siblings like data_get_pine_lines, data_get_pine_labels, and data_get_pine_tables, which target other primitives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit 'WHEN TO USE' clause names concrete trigger scenarios (order blocks, fair value gaps, consolidation boxes via box.new), which is strong context. It does not name alternative sibling tools, but the conditions for use are clear enough that the agent can route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does reasonably well: it explicitly states 'SIDE EFFECTS: None (Read-only)' and a meaningful limitation that only labels currently in chart memory are readable. It does not describe return structure in detail, but the safety and scope profile 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence followed by labeled WHEN TO USE, SIDE EFFECTS, and LIMITATIONS sections. Every sentence earns its place with zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the verbose parameter's description indicates the return shape (raw label data with IDs/colors/positions vs text+price only), so return expectations are covered indirectly. The definition is complete enough for an agent to invoke correctly, with only minor gaps in return-format detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 verbose, max_labels, and study_filter with defaults and semantics. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (read) and resource (text annotations/labels drawn by Pine Script indicators via label.new) paired with price coordinates. This clearly distinguishes it from siblings like data_get_pine_lines, data_get_pine_tables, and data_get_pine_boxes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE clause gives concrete trigger conditions (indicator displays bias markers, order block tags, or targets via label.new). However, it does not name alternative tools or state when to prefer a different data_get_pine_* sibling over this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it declares 'SIDE EFFECTS: None (Read-only)' and a concrete limitation ('Only reads lines drawn by active Pine studies'). It also discloses post-processing behavior (deduplicated, sorted, per study). Minor gap: no statement on empty/missing-study behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then tightly organized WHEN TO USE / SIDE EFFECTS / LIMITATIONS blocks. Every sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully sketches the return shape ('deduplicated, sorted price levels per study'). Combined with full schema coverage of both params and the read-only declaration, an agent has almost everything needed, though the verbose-mode return shape stays undocumented in prose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already fully documented in the schema; baseline 3 applies. The description reinforces study_filter's purpose ('target specific scripts') but adds no syntax or format detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read horizontal price levels drawn programmatically by Pine Script indicators') and pins down the exact mechanism (line.new). It is clearly distinguishable from the sibling draw-type readers data_get_pine_labels, data_get_pine_tables, and data_get_pine_boxes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE block gives a concrete trigger ('indicator draws support/resistance or session levels via line.new') and points at study_filter for targeting scripts. It stops short of naming explicit alternatives or exclusion conditions, so it is clear but not fully routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the safety profile (SIDE EFFECTS: None, read-only) and a real precondition (requires a study drawing table.new to be attached). It does not describe the return structure beyond 'rows of text', but the core behavioral facts are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence followed by labelled WHEN TO USE, SIDE EFFECTS, and LIMITATIONS sections. Every sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description partially compensates by stating the result is structured rows of text, while covering the precondition and read-only nature. It is complete enough to invoke correctly, though the exact shape of the returned rows remains unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single optional parameter (study_filter) fully documented as a substring match. The description adds no semantics 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Read) and resource (table matrices drawn by Pine Script indicators via table.new) and returns them as structured rows of text. The explicit mention of table.new distinguishes it from the sibling drawing readers data_get_pine_lines, data_get_pine_labels, and data_get_pine_boxes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE clause gives concrete trigger scenarios (dashboard summaries, session statistics, multi-timeframe matrices). It does not explicitly name the sibling tools it is an alternative to, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so reasonably: it declares read-only status, 'no side effects', and states the precondition that a strategy must be running with the panel populated. It doesn't say what happens when the panel is empty (error vs empty result), which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight, labeled sentences (purpose, WHEN TO USE, SIDE EFFECTS/LIMITATIONS) with zero filler. The most decision-relevant information, what it extracts, is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-arg read-only extraction tool with no output schema, the description enumerates the returned metrics, which is exactly the return-value information an agent would otherwise lack. Prerequisites and safety posture are both covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. No parameter meaning needs to be added, and the description correctly does not invent any.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Extract) and resource (TradingView Strategy Tester panel performance metrics), and enumerates the exact metrics returned. This clearly distinguishes it from sibling readers like data_get_trades, data_get_equity, and data_get_indicator.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE clause gives explicit timing ('after compiling a Pine Script strategy to evaluate quantitative backtest results') plus a prerequisite in LIMITATIONS. It does not name alternative tools for related backtest data (e.g. data_get_trades/data_get_equity), so it falls just 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers key behavioral traits: 'SIDE EFFECTS: None (Read-only)' and 'LIMITATIONS: Indicators must be visible on chart.' It does not describe authentication, rate limits, or error behavior if indicators are hidden, but for a read-only extraction tool this is solid coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose first, then labeled sections for when to use, side effects, and limitations. Every sentence earns its place with no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter, read-only extraction tool with no output schema, the description covers purpose, when to use, side effects, and a precondition. It stops short of describing the return structure (e.g., how indicator names map to values), which would be helpful given the lack of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so parameter semantics baseline is 4. The description adds no parameter-specific information 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Extract') and resource ('real-time numerical values of all visible indicators from the chart Data Window'), and lists examples (RSI, MACD, EMAs, custom plot() outputs). The phrase 'all visible indicators' implicitly distinguishes it from the singular sibling data_get_indicator, so an agent can tell them apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'WHEN TO USE' section tells the agent to call this when reading current indicator values directly from TradingView without recomputing in Node.js. However, it does not name an alternative tool or state when not to use it, so it falls short of the full when/when-not/alternatives standard.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does a solid job: it declares the side effect profile (None, Read-only) and a real prerequisite (Strategy Tester bottom panel must be populated). It does not cover rate limits, pagination, or how max_trades truncation behaves, leaving a modest gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, then WHEN TO USE, SIDE EFFECTS, and LIMITATIONS are cleanly labeled. Every line carries information and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only extraction tool with no annotations and no output schema, the description supplies purpose, usage trigger, safety profile, prerequisite, and returned fields. It falls just short of complete because truncation/pagination behavior of max_trades is unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single optional parameter with 100% schema coverage ('Maximum trades to return'), so the schema already documents it fully. The description adds no extra syntax or default behavior for max_trades, making the baseline 3 correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Extract) and resource (individual trade execution log from Strategy Tester) and enumerates the returned fields, which implicitly separates it from aggregate siblings like data_get_strategy_results and data_get_equity. It never names an alternative explicitly, so sibling differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'WHEN TO USE: Call when conducting granular trade-by-trade review or streak analysis of a backtested Pine strategy' gives a concrete triggering condition with a clear scope (backtested Pine strategy). It stops short of naming alternatives or stating when NOT to use it, so it lands at clear-context but no-exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It correctly discloses side effects (none, read-only) and a prerequisite limitation (DOM panel must be open). It does not describe error behavior or return format, but for a simple read-only extraction tool this is a reasonable level of disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and well structured with WHEN TO USE, SIDE EFFECTS, and LIMITATIONS labels. It is concise and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, annotation-free read tool with no output schema, the description covers purpose, usage context, side effects, and a key limitation. It could optionally describe the return shape (e.g., bid/ask level structure), but it is largely complete for tool selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 empty schema provides all necessary structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: extract order book / DOM bid/ask levels from the DOM panel. This is clear and unambiguous, but it does not explicitly differentiate itself from sibling tools such as quote_get, data_get_trades, or market_get_smart_volume.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit WHEN TO USE section: analyzing order book liquidity or bid-ask imbalance. It also gives a prerequisite limitation (DOM panel must be open), but it does not name alternative tools or say when not to use this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does state 'STATE_MUTATING' and 'Irreversible removal of canvas drawings.' It does not cover permission requirements or behavior on an empty canvas, but the critical destructive and irreversible characteristics are 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary action and then uses labeled sections for WHEN TO USE, SIDE EFFECTS, and LIMITATIONS. Each sentence adds value and the total length is appropriate for a destructive zero-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless, destructive tool with no output schema, the description covers purpose, usage context, side effects, and irreversibility. An agent has all the information needed to invoke it safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so the baseline for parameter semantics is 4. The description correctly adds no unnecessary parameter detail, as there is nothing to describe.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Remove all user drawing shapes and annotations from the active chart canvas.' The word 'all' distinguishes it from the sibling draw_remove_one, making the scope unambiguous 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear WHEN TO USE clause: 'Call when resetting or cleaning the chart canvas before drawing a fresh analysis template.' However, it does not name an alternative such as draw_remove_one for single-shape removal, so the when-not guidance is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and explicitly states 'SIDE EFFECTS: None (Read-only)' and the dependency on an entity ID from draw_list. It does not describe error behavior for invalid or missing IDs, but for a simple read getter this is a solid disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then neatly separated into WHEN TO USE, SIDE EFFECTS, and LIMITATIONS. Every sentence contributes useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool with full schema coverage and no output schema, the description is complete. It states what is returned, when to call it, its safety profile, and the prerequisite entity ID.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the single parameter is already fully documented in the schema. The description repeats that entity_id comes from draw_list but adds no additional syntax, validation, or format meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 (styling properties, line colors, line width, coordinate points of an existing drawing shape), and ties it to an entity ID. It clearly distinguishes this inspection tool from sibling tools like draw_list, draw_shape, and draw_remove_one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit WHEN TO USE condition: inspecting or confirming coordinates of an annotated price level. It also states a prerequisite (entity ID from draw_list). It does not name alternatives or when-not scenarios, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and explicitly declares 'SIDE EFFECTS: None (Read-only)' plus a real scope limitation (user drawings only, not Pine script drawings). It omits any mention of result volume or pagination, which is a minor gap for a listing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-sentence purpose followed by clearly labeled WHEN TO USE, SIDE EFFECTS, and LIMITATIONS sections. Every sentence carries information; nothing is restated from the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing tool with no output schema, the description supplies everything needed: what is listed, what is returned, the safety profile, and the user-vs-Pine scope boundary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is no parameter surface for the description to clarify. The description instead describes the shape of the result (IDs, types, coordinates), which is useful but not a param concern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (user drawing shapes and annotations on the chart) and even enumerates the returned fields (entity IDs, types, coordinates). This distinguishes it cleanly from siblings like draw_shape, draw_clear, draw_remove_one, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' clause gives an explicit trigger: call before modifying or deleting drawings to locate drawing IDs. It does not, however, name an alternative (e.g. draw_get_properties) or state when not to use it, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 side effect (STATE_MUTATING, deletes the targeted shape) and the requirement to obtain the entity ID from draw_list, but does not mention reversibility, error behavior, or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in the first sentence, then uses labeled sections (WHEN TO USE, SIDE EFFECTS, LIMITATIONS) for scannability. Every sentence is purposeful and no information is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter removal tool with no output schema, the description covers purpose, usage context, side effects, and prerequisite. Nothing critical for correct invocation appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the entity_id parameter is already fully documented in the schema. The description repeats that the remove operation uses an entity ID and that it comes from draw_list, adding no new format or syntax semantics beyond the structured field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete) and resource (drawing shape), and specifies the target identifier (entity ID) needed. It is clearly distinguishable from sibling tools like draw_clear, which would remove drawings in bulk.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it (removing an invalid or obsolete level while preserving other drawings) and gives a prerequisite (entity ID from draw_list). It does not explicitly name an alternative tool or state when not to use it, but the preserving constraint implies a contrast with draw_clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well: it explicitly discloses STATE_MUTATING ('Adds drawing primitive to chart canvas') and the coordinate-format LIMITATION. It stops short of covering permissions, reversibility/undo, or persistence across sessions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Labeled sections (WHEN TO USE, SIDE EFFECTS, LIMITATIONS) make the definition scannable, and the core capability is front-loaded in the first sentence. No filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool without annotations or an output schema, the description covers purpose, usage context, the mutation side effect, and required coordinate formats. The only gaps are edge behavior such as what identifier is returned and whether the drawing can be undone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (shape, point, point2, text, overrides) are already documented. The description restates the coordinate format (unix timestamp + price) and shape list but adds no new syntax or semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource combination ('Create and render a graphical drawing primitive on the chart') and enumerates the supported shape types. An agent can tell this apart from siblings like draw_list, draw_clear, and draw_remove_one without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE clause gives concrete conditions (support/resistance levels, chart patterns, breakout zones, trade entry/targets), which is clear contextual guidance. It does not, however, name alternatives such as draw_list or draw_get_properties for inspection workflows.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the key trait: 'STATE_MUTATING (Alters indicator configuration on chart)' plus the/entity-ID requirement. It stops short of covering failure behavior for invalid input IDs or whether overrides persist/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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four labeled, front-loaded fragments (purpose, WHEN TO USE, SIDE EFFECTS, LIMITATIONS) with no filler. The mutation warning is placed where an agent will see it before acting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation tool with no output schema and no annotations, the description covers purpose, trigger, side effect, and preconditions adequately. It omits error/validation behavior when input IDs or the JSON map are invalid, which is the main remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are documented with examples inside the schema, so the schema does the heavy lifting. The description's mention of example fields (length, source, period) only loosely restates the schema's 'e.g.' example rather than adding new semantic detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Programmatically override input values of an indicator entity') and enumerates concrete examples (length, source, period, multiplier). The phrase 'without deleting and re-adding it' implicitly separates it from chart_manage_indicator, but no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' clause gives a clear trigger: fine-tuning an attached study's parameters in place rather than removing and re-adding it. It includes a LIMITATIONS precondition (needs study entity ID and valid JSON map) but does not name an alternative tool for the delete/re-add path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it labels the operation STATE_MUTATING and discloses the prerequisite of a study entity ID from chart_get_state. It omits reversibility and permission details, but the mutation profile and precondition are clearly flagged.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, then cleanly labeled WHEN TO USE / SIDE EFFECTS / LIMITATIONS sections. Every sentence carries distinct information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter toggle with no output schema and no annotations, the description covers action, trigger context, mutation side effect, and the entity-ID dependency. That is sufficient to call it correctly, with only minor omissions around reversibility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters (visible, entity_id) are documented there. The description only restates the entity-ID prerequisite already present in the schema, adding no new syntax or format guidance, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (show/hide) and resource (indicator/study plot on the chart canvas), which naturally separates it from siblings like indicator_set_inputs or chart_manage_indicator. It stops short of explicitly naming those siblings, so it is clear but not maximally differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' clause gives a concrete scenario (decluttering the chart before visual analysis or screenshot capture), which is more than most definitions provide. It does not name alternative tools or state when not to call 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the burden. It discloses 'SIDE EFFECTS: None (Read-only)' and 'LIMITATIONS: Requires user profile to have saved layouts.' This covers safety and a precondition. Slight gap: doesn't mention return format or pagination, but with no output schema some of that would be expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Uses labeled sections (WHEN TO USE, SIDE EFFECTS, LIMITATIONS) that are front-loaded and easy to scan. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only list tool, the description covers purpose, usage, side effects, and limitations. It would benefit from a brief note on the return shape since there is no output schema, but overall it's complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so baseline is 4 per the rules. The description mentions layout names and IDs, but since there are no input parameters, there's nothing more to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'List all saved chart layouts in user profile with layout names and IDs.' Clear what it returns and what it operates on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit WHEN TO USE section: 'Call before switching layouts to discover valid layout names.' This directly names the sibling tool layout_switch and the condition that selects this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It discloses a critical side effect (STATE_MUTATING, reloads charts and indicators) and a limitation (layout must exist). This is strong transparency, though it doesn't cover reversibility or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely dense: three labeled sections (purpose, WHEN TO USE, SIDE EFFECTS, LIMITATIONS) with no filler. Front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter state-mutating tool with no output schema, the description covers purpose, usage trigger, side effects, and a hard limitation. It is nearly complete; only the exact post-switch state (e.g., whether current unsaved changes are lost) is unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter, so the schema already explains the 'name' parameter as name or ID. The description adds no format, case-sensitivity, or resolution-order details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Switch) and resource (active chart workspace / saved layout) with clear scope by name or ID. An agent can distinguish this from layout_list and pane_set_layout, which are different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

WHEN TO USE clause gives clear context ('transitioning between specialized analytical layouts') with examples. It does not explicitly exclude other tools or name alternatives, but the use case is well defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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, and it does assert 'NO SIDE EFFECTS,' which is useful. But it says nothing about preconditions (e.g., whether a symbol/chart context must already be set), data requirements, or how results are returned, which matters for a zero-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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what is compared before the WHEN TO USE directive and the safety note. No filler and every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain what the comparison returns and any preconditions. It covers purpose, usage trigger, and side-effect status adequately but leaves return shape and required market context unspecified for what is conceptually a rich analytical tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented, making 3 the baseline. The description's enumeration of example timeframes echoes the schema's default array and adds only marginal clarity about accepted values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (compare) and enumerates the exact dimensions compared (market regime, trend direction, RSI momentum, volume consensus) plus the scope (multiple timeframes with concrete examples). It is clearly distinguishable from generic data tools. It falls short of a 5 only because the sibling chart_get_multi_timeframe sounds closely related and is never differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit 'WHEN TO USE' clause gives a concrete scenario: multi-timeframe top-down analysis to identify timeframe alignment or conflicts. That is clear context for invocation. However, no exclusions or named alternatives are given, so an agent cannot tell when to prefer chart_get_multi_timeframe or market_get_context instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden, and it does declare two traits: the computation is 'deterministic' and has 'NO SIDE EFFECTS', which effectively communicates a safe read-only operation. However, it says nothing about cost, latency, data prerequisites (e.g., whether a chart with enough bars must be loaded), or the shape of what comes back.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, followed by a clearly labeled usage clause and a short safety clause. Every sentence earns its place 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description partially compensates by enumerating the detected structures, which tells the agent what the result will discuss. It still does not describe the response format (per-swing coordinates, timestamps, or labels), so an agent cannot fully anticipate the return payload.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter (candleCount) and schema description coverage is 100%, so the schema already documents it fully as 'Number of bars to analyze (default 100)'. The description adds no extra meaning such as lookback sensitivity or minimum-bar constraints, making the baseline 3 the correct score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Detect) and resource (market structure), then enumerates the exact artifacts produced: Swing Highs/Lows, HH/HL/LH/LL, BOS, CHoCH, Equilibrium/Range bounds. This is enough for an agent to distinguish it from sibling detectors like market_detect_zones or market_get_context without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit 'WHEN TO USE: Call when evaluating trend continuity or structural breakouts' gives a clear triggering context. It stops short of naming alternatives or stating when NOT to use it (e.g., vs market_detect_zones for supply/demand), so it does not reach the top band.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does at least assert 'NO SIDE EFFECTS', establishing it as a read-only analysis. It omits other behavioral traits: which symbol/timeframe/bars it operates on, computational cost, and how zones are ranked or returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler: the capability and its result attributes come first, followed by the usage trigger. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe returns; it only hints at them (touch counts, test recency) without a return shape. It also omits the chart-context dependency (symbol/timeframe/visible range) that an agent would need to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with defaults documented on all three parameters (minTouches, candleCount, tolerancePct), so the schema does the heavy lifting. The description adds no additional meaning about how these knobs affect detection results, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: detecting horizontal support/resistance zones and consolidation clusters, plus output attributes (touch counts, test recency). However, it never distinguishes itself from the sibling market_detect_structure, which an agent could easily confuse with this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit 'WHEN TO USE' clause gives concrete scenarios (take-profit, stop-loss, reaction areas), which is stronger than most definitions. It stops short of naming when NOT to use it or pointing to market_detect_structure / market_get_context as alternatives for related analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does meaningful work: 'NO SIDE EFFECTS' declares the read-only safety profile, 'single deterministic call' signals stable repeatable output, and 'Requires price bars loaded on chart' names a precondition that would otherwise cause silent failure. It omits error behavior and does not describe the response payload.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence followed by labeled WHEN TO USE and LIMITATIONS clauses; every sentence earns its place and an agent can skim the labels for exactly the facts it needs. No filler or restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter, all-optional read tool with no output schema, the description covers purpose, usage trigger, precondition, and side-effect status. Its one real gap is return-shape detail: the enumerated dimension list hints at contents but does not tell the agent what fields or structure to expect back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters (expectedTf, candleCount, includeZones, expectedSymbol, includeStructure, includeIndicators) are already documented in the schema with defaults and constraints. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Get) and resource (market context) and enumerates the dimensions returned: trend, regime, key indicators, volume, market structure, zones. This clearly distinguishes it from narrower siblings like market_detect_structure and market_detect_zones, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The labeled 'WHEN TO USE' clause gives a clear condition: orienting on a ticker/timeframe before planning actions or answering analysis queries. It does not name alternatives (e.g. market_detect_structure for structure only) or state when not to use it, so it stops short of a full routing rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden and does disclose 'NO SIDE EFFECTS', which usefully establishes it as a safe read. It does not describe the shape of the diff output, whether results are bounded/paginated, or what happens when neither timestamp nor generation is supplied (both default to 0).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the purpose and then the usage trigger and safety note. Every sentence earns its place and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-optional-parameter polling tool with no output schema and no annotations, the description covers purpose, trigger, and safety profile adequately. It could go further by clarifying behavior when both parameters are omitted or how the two parameters interact, but the essentials are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are fully documented in the schema, including the seconds-or-milliseconds format for sinceTimestamp and the meaning of sinceGeneration. The description merely alludes to 'a given timestamp or generation' without adding format, precedence, or default-behavior detail beyond the schema. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Detect') and enumerates the exact change types returned: structural shifts, new swings, volume spikes, divergences. It is clearly distinguishable from siblings like market_detect_structure or market_get_smart_volume, which are point-in-time detectors rather than change detectors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE clause gives a concrete trigger: polling for what changed since the last analysis turn, with a stated rationale (saving LLM token bandwidth). It does not, however, name alternatives or state when not to use it (e.g., first-time analysis), so it stops short of explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it declares 'NO SIDE EFFECTS' and adds a LIMITATIONS section disclosing that on CFD/Forex feeds volume is tick-based and the analysis is inferred/heuristic. It stops short of describing the response shape, but the read-only and reliability caveats are genuinely useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then cleanly sectioned into WHEN TO USE and LIMITATIONS. The metric list is dense but each item earns its place by defining the analytical output; no filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-output-schema, six-optional-param analysis tool the description covers purpose, usage triggers, side-effect profile, and data-reliability caveats. It could say more about what the response contains, but the essential invocation guidance is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters (session, lookback, expectedTf, sensitivity, expectedSymbol, includeMultiTimeframe) are documented in the schema itself. The description adds no parameter-level detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Analyze') plus an enumerated set of analytical outputs (RVOL, robust z-score, Wyckoffian effort vs result, absorption, initiative moves, exhaustion, sweeps, accumulation/distribution). This clearly scopes it to volume/activity analysis, distinguishing it from sibling tools like market_detect_structure or market_detect_zones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'WHEN TO USE' section naming concrete triggers (volume anomalies, liquidity sweeps, participation conviction). It gives clear selection context but does not name any sibling alternative or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so reasonably by declaring 'SIDE EFFECTS: None (Read-only)' and a dependency ('Requires rules.json in workspace or specified via rules_path'). It does not describe output structure, failure behavior when rules.json is absent, or whether the scan hits external services, so the disclosure is solid but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then uses labeled WHEN TO USE / SIDE EFFECTS / LIMITATIONS blocks that scan quickly. Sentence count is tight, though the three labels are slightly formulaic relative to the amount of content delivered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-step composite tool with no output schema, the description covers purpose, timing, safety, and the key prerequisite, which is a fair amount. However it does not indicate the shape or scope of the 'structured market data' returned, leaving the agent unable to anticipate the response for such a cross-asset aggregation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter rules_path is fully documented in the schema. The description only reinforces the rules.json default behavior via the LIMITATIONS line, adding no syntax or format detail beyond the schema, which matches the baseline 3 for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verbs and resources ('scan user watchlist, read indicator values across symbols, extract structured market data') and scopes the output ('pre-market or daily briefing according to rules.json'). It is clearly a composite briefing tool, though it does not explicitly contrast itself with similar siblings like market_get_context or watchlist_get, leaving the differentiation to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' clause explicitly anchors usage to 'the start of a trading day to synthesize cross-asset market bias and momentum,' which is strong temporal guidance. It stops short of naming when NOT to use it or which sibling to prefer instead, so no exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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, and it does disclose the key trait: STATE_MUTATING focus change plus a precondition that the index must be valid within pane_list. It does not mention error behavior for an out-of-range index or whether focus persists across commands, keeping it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence of purpose followed by labeled WHEN TO USE / SIDE EFFECTS / LIMITATIONS clauses — front-loaded, scannable, and every line adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter state-mutating tool with no annotations and no output schema, the description covers purpose, timing, mutation side effect, and validity constraint. Only the failure mode for an invalid index is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter is already documented as '(0-based, from pane_list)'; the description's 'index (0-based)' restates rather than extends that. Baseline 3 applies when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb + resource + scope: 'Switch active user focus to a specific chart pane by index (0-based).' That is enough to distinguish it from pane_list (read) and pane_set_symbol (content change), though it never explicitly contrasts itself with those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

A dedicated 'WHEN TO USE' clause states the triggering condition: call it before chart operations aimed at a secondary pane in a multi-chart layout. It lacks an explicit when-not or a named alternative, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden and does so explicitly: SIDE EFFECTS: None (Read-only) and the LIMITATIONS line about requiring a multi-chart layout. It stops short of stating what a single-pane layout returns or whether the list is paginated/ordered, so it is strong rather than complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with labeled WHEN TO USE / SIDE EFFECTS / LIMITATIONS sections; the core behavior is front-loaded and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param, no-output-schema list tool, the description supplies the return fields, safety profile, and a precondition, which is close to sufficient. It omits ordering/emptiness semantics for a single-pane workspace, leaving a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies a no-argument call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('List') plus resource ('chart panes') and scope ('current split-view workspace'), and it names the payload returned (active symbols, resolutions, focus state). An agent can distinguish this from pane_focus, pane_set_symbol, and pane_set_layout without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE line gives a concrete trigger: call before manipulating multi-chart layouts to discover pane indices. It does not name a sibling alternative (e.g. chart_get_state vs pane_list), so it stops short of explicit routing, but the usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does so well for a mutation tool. It explicitly discloses STATE_MUTATING behavior, that it alters window grid division, and that it creates/destroys chart panes, though it omits auth or rate-limit details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and organized under WHEN TO USE, SIDE EFFECTS, and LIMITATIONS, making it easy to scan. It has minor redundancy, including the awkward phrase 'layout grid layout grid' and repetition of layout codes already in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple one-parameter mutation tool with a rich schema and no output schema, the description covers purpose, usage context, side effects, and layout limitations. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 the layout parameter with the full code list and aliases. The description repeats the same layout codes and adds no syntax or meaning beyond what the schema provides, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: changing the chart grid layout, with examples such as single, 2h, 2v, and 4 quad grid. It is clear enough to distinguish from pane_list or pane_focus, but it does not explicitly differentiate itself from sibling layout_switch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes a WHEN TO USE section that gives concrete context: configuring multi-chart views for correlated assets or multi-timeframe monitoring. It provides clear positive guidance but does not name alternatives or 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does so reasonably: it labels the operation STATE_MUTATING, says the target pane's symbol changes, and clarifies that active focus is not changed. It does not describe error behavior or return values, but those gaps are minor for this simple setter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, with clear labeled sections for usage, side effects, and limitations. Every sentence adds a distinct piece of information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter pane symbol setter with no output schema and no annotations, the description covers purpose, when to use, mutation side effect, and the main limitation. Nothing critical is missing for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented with types and descriptions. The description adds only a multi-pane example and the limitation that the index must exist, which is useful but does not substantially extend parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: sets a financial ticker symbol on a specific pane index. It also distinguishes itself from sibling tools like chart_set_symbol by emphasizing 'directly on a specific pane index without changing active focus.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit WHEN TO USE section with a concrete multi-pane example (BTCUSD on pane 0, ETHUSD on pane 1). It does not name an alternative tool for when this should not be used, but the focus-scope distinction gives clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: 'SIDE EFFECTS: None (Read-only offline parser)' declares safety, and 'LIMITATIONS: Static AST parsing only; does not execute runtime logic' discloses the analysis boundary. It omits what the result looks like, but the safety and scope profile is solidly covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then uses labeled WHEN TO USE / SIDE EFFECTS / LIMITATIONS sections with no filler. Every clause conveys distinct, useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param, read-only tool with no output schema and no annotations, the description covers purpose, timing, side effects, and limits. It could briefly indicate the shape of the returned findings, but nothing critical for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, and schema description coverage is 100%, so the schema already documents 'source'. The description adds no syntax or formatting guidance for the input, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run offline static analysis on Pine Script source code') and enumerates the exact classes of defects detected. An agent can distinguish it from siblings like pine_compile, pine_check, and pine_get_errors 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'WHEN TO USE: Call before compiling code to verify correctness without needing a live TradingView connection' gives clear timing and the offline condition. It implicitly positions itself relative to pine_compile but never names the sibling alternatives or exclusions explicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the external side effect (source code is sent to TradingView's cloud compiler) and the hard limitation (active internet connection required). It omits whether authentication/credentials are needed and whether the code leaves the machine permanently, but the key behavioral traits are surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with the action, and uses labeled WHEN TO USE / SIDE EFFECTS / LIMITATIONS blocks that are easy to scan. Minor redundancy ('without touching the UI' plus 'headless') costs it the top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, no-output-schema tool with no annotations, the description covers purpose, return content, trigger condition, side effect, and network limitation. The only meaningful gap is how it differs from sibling compile tools, which an agent needs in order to choose correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter and schema description coverage is 100%, so the schema already documents 'source' as the Pine Script code to compile. The description adds no format, size, or version constraints beyond that, making this the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Compile Pine Script via TradingView remote compiler API') and adds what it returns (compilation errors and warnings), which lets an agent distinguish it from a plain compile call. However, it does not differentiate itself from the close siblings pine_compile, pine_smart_compile, or pine_get_errors, so the purpose is clear but sibling routing is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'WHEN TO USE' guidance: headless validation of Pine Script before opening the editor or chart. This gives a clear trigger condition, but it never names the alternatives (pine_compile / pine_smart_compile) or states when NOT to use it, so routing between the three compile tools remains ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does useful work: it declares SIDE EFFECTS as STATE_MUTATING and a prerequisite (editor open with code loaded). It omits what happens on compile failure and how errors surface (pine_get_errors), which an agent invoking a mutation would want.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Labeled sections (WHEN TO USE / SIDE EFFECTS / LIMITATIONS) front-load the action, then the trigger conditions, then the constraints. Every sentence is informative and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, no-output-schema action tool with no annotations, the description supplies purpose, sequencing, mutation semantics, and a precondition. Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric this is the baseline 4. There is nothing further the description could add on parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('trigger compilation') and resource (the script in the Pine Editor) and names the UI actions it corresponds to. However, it does not differentiate itself from the sibling pine_smart_compile (or pine_check/pine_analyze), so an agent cannot tell from this text alone which compile variant to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section gives clear sequencing ('call after setting source code') and the intended outcome (applying the indicator/strategy to the chart). It stops short of naming alternatives like pine_smart_compile or when not to call it, so routing between compile tools is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the behavioral burden. It does disclose side effects ('None (Read-only)') and a practical limitation ('Console output must be enabled in the script'), though it does not cover return shape or authorization context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, then succinctly labels WHEN TO USE, SIDE EFFECTS, and LIMITATIONS. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only console log tool with no output schema and no annotations, the description provides all essential details: what it reads, when to use it, safety, and a precondition. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to add beyond the schema. Baseline for zero-parameter tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a precise verb ('Read') and names the specific resource ('runtime logs and compiler messages from the Pine Editor console window'), including concrete examples of log functions. It clearly distinguishes this from compile-error retrieval tools by focusing on console output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit WHEN TO USE section: debugging Pine Script runtime behavior or inspecting custom log outputs. It gives clear context but does not name alternative tools (e.g., pine_get_errors) or state when-not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.