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

Annotations already flag destructive behavior, and the description adds context: it mutates the broker, is paper-only, and returns both the cancelled order and remaining working orders. This goes beyond the annotation by describing the return value and scope.

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, front-loaded with the key action 'MUTATES' and the specific resource. No redundancy; every clause carries meaning.

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?

The description covers the operation, scope, constraints, and return value. It lacks error handling details or prerequisites, but for a cancel operation with clear annotations and full schema coverage, it is sufficiently 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 coverage is 100% with parameter descriptions for all three fields. The description adds minimal parameter-level detail beyond restating that it cancels by id, which the schema already implies. 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?

The description clearly states the tool cancels a working order by id, specifies it's for entry orders, and differentiates from bracket orders. It also mentions the connected TradingView broker and that it's paper-only, making the purpose unambiguous and distinct from siblings like tv_close_position.

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 states when to use this tool (cancel entry orders) and implicitly when not to (bracket orders belong to position). It doesn't name specific alternatives but provides clear scoping. The 'PAPER ONLY' constraint is a useful usage guard.

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?

Annotations already mark it destructive and non-read-only, but the description adds significant context: 'MUTATES', 'market close via the broker adapter', 'PAPER ONLY', and the return values (closed position and remaining open positions). This goes well beyond the structured annotations.

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

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

A single dense sentence that front-loads the mutation flag, then states the action, selection methods, execution mode, paper-only constraint, and return values. Every clause 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?

Despite no output schema, the description explains return values and covers purpose, mutation, and paper-only constraint. The main gap is that it doesn't explicitly state that at least one of symbol or position_id is required, even though the schema marks both optional.

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 baseline is 3. The description mentions 'by symbol or position id' which aligns with the schema, but adds no extra parameter-level detail beyond what the schema already provides.

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

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

States a specific verb and resource: 'close an open position' on the TradingView broker, with clear selection methods (symbol or position id) and execution mode (market close). This clearly differentiates it from siblings like tv_cancel_order (which cancels orders) and tv_place_order (which places orders).

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 clear context that this tool is for closing existing positions, not for managing orders or brackets. It doesn't explicitly name alternatives or exclusions, but the action is unambiguous and the 'PAPER ONLY' constraint further narrows when it should be used.

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?

Beyond the destructiveHint annotation, the description explains the timeline (45-60 s), the settling condition (copy appears in saved-layout list), the new-tab behavior on TV Desktop, and the refusal conditions for empty or duplicate names. It also adds detail about how source_url 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?

The description is dense but tightly structured, with the core action first, then performance/settling behavior, then edge-case refusals. Every sentence provides operational detail that an agent needs; there is no filler or repetition of schema 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 complex destructive operation with no output schema, the description covers the essential operational context: expected duration, success criterion, tab behavior, duplicate-name policy, and source_url handling. An agent has enough guidance to invoke the tool correctly and interpret the result.

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?

Although the schema already documents all seven parameters, the description enriches their meaning by tying name/allow_duplicate_name to refusal behavior, explaining timeout_s in terms of server round trips plus page reload, and clarifying that source_url follows tv_open_chart_url rules. This goes well beyond the structured 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 states a specific verb ('clone') and resource ('the layout shown in the bound tab'), and includes the TradingView feature name 'Make a copy'. It clearly distinguishes this from related tools like tv_delete_layout or tv_open_chart_url by describing exactly what is created and what is not.

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 gives clear context: use it to clone the current tab's layout, optionally from a source_url such as someone else's View Only chart. It does not explicitly enumerate when to prefer alternative tools, but the behavior and boundaries are sufficiently clear for an agent to decide.

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?

The description discloses critical behavioral traits beyond annotations: the clone is created paused by default, the armed window when overrides are applied, the auto-delete on retarget failure, and the fact that alerts fire real webhooks placing live orders. It also notes the path was verified live on defanged throwaway clones. This is rich behavioral context that annotations alone don't provide.

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 dense and information-rich, front-loading the core purpose and mechanism. Every sentence earns its place, covering the clone rationale, paused default, armed window, failure cleanup, return value, and verification. It is longer than typical but justified by the complexity and risk profile of the 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?

Given the tool's complexity, the 100% schema coverage, and the absence of an output schema, the description is remarkably complete. It covers the return shape, the failure mode, the safety window, the verification status, and the real-world consequence of firing webhooks. An agent has everything needed to invoke it correctly and understand the 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 coverage is 100%, so the schema already documents all 9 parameters. The description adds meaning for key parameters like symbol, resolution, message, and web_hook, explaining how they behave (e.g., resolution applied to alert AND every condition, empty string removes webhook). However, it doesn't add much beyond the schema for parameters like layout, expect_layout, or active, so a 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?

The description states a specific verb and resource: create a new alert by cloning an existing one, with explicit overrides. It clearly distinguishes this from other alert tools by explaining the clone-based mechanism and why it must be clone-based. The description also names the sibling tv_resume_alerts for the separate resume step.

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 explicitly explains when to use this tool: when creating an alert that must carry live study plots and pineId, because /create_alert rejects hand-built payloads. It also states that resuming is a separate explicit tv_resume_alerts call, and mentions the armed window risk. This gives clear context for when to use it vs 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?

Annotations already declare destructiveHint=true, but the description goes far beyond: it explains the irreversible nature, the resolution-to-name/symbol step before any deletion, the abort-on-unknown-id behavior, the exact result payload structure, the potential lag with still_present ids, and even a live verification date. This is exemplary behavioral disclosure.

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

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

The description is front-loaded with the critical mutation warning, then packs each sentence with actionable detail—no redundancy. The structure flows from high-level purpose to execution details and a verification note, 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 destructive operation with no output schema, this is remarkably complete: it covers the endpoint, irreversibility, required confirmation, pre-deletion resolution, abort behavior, response format, and lag characteristics. An agent can predict outcomes and side effects confidently. The only missing element, a formal output schema, is mitigated by the description itself.

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 covers 100% of parameters with descriptions (ids, confirm, layout, expect_layout), so baseline is 3. The description reinforces that confirm must be true and that ids are resolved before deletion, which adds process context but does not fundamentally change parameter semantics. It aligns with the schema rather than adding new meaning.

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 opens with 'MUTATES: PERMANENTLY delete the given alerts' and names the exact REST endpoint, clearly distinguishing this from siblings like tv_pause_alerts and tv_resume_alerts which handle temporary state. The verb 'delete' and resource 'alerts' are specific and unambiguous.

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

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

It clearly states the permanent nature ('there is no undo') and the confirm=true requirement, implying this is for final removal rather than temporary suspension. It does not explicitly name alternative tools, but the context makes it obvious when to use this vs. others. A slightly higher score would require an explicit 'use tv_pause_alerts instead for temporary' clause.

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?

Beyond the annotations (destructiveHint=true), the description discloses specific behavioral traits: it requires confirm=true, refuses anything in protect, refuses the currently displayed layout unless force=true, and verifies by re-listing. These details are critical for safe invocation and are not present in the annotations or schema.

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 a single sentence that front-loads the core purpose ('Delete ONE saved layout') and then packs the essential safety constraints into a compact, readable structure. Every clause adds value, 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 destructive tool with 7 parameters and no output schema, the description covers the key behavioral context: irreversibility, confirmation requirement, protection list, force override, and post-deletion verification. This is sufficient for an agent to safely invoke the tool without additional context.

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 parameters are documented. The description adds interaction semantics beyond the schema: it explains that confirm must be true, that protect acts as a safeguard, and that force overrides the current-layout refusal. This enriches parameter understanding, though not every parameter (e.g., timeout_s, expect_layout) is explicitly tied to the description, but the schema already covers those.

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 ('Delete'), a specific resource ('ONE saved layout'), and the exact identification methods (by layout id, numeric id or exact name). It clearly distinguishes this from sibling tools like tv_list_layouts or tv_copy_layout, and the scope ('ONE') prevents confusion with bulk deletion tools.

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 implies the tool is for deleting a single saved layout but does not explicitly state when to use it over alternatives (e.g., tv_delete_alerts) or provide exclusions. The destructive nature and safety constraints are mentioned, but no direct guidance on when-not-to-use is given. Purpose clarity already covers the 'what', but 'when' is left implicit.

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?

Beyond the readOnlyHint/destructiveHint annotations, the description discloses real behavioral traits: TradingView Desktop refuses its own export, the export is composed from loaded series, there is a 500-bar cap, studies without series are listed under `skipped`, and column names follow a specific pattern. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place: core action first, then limitations, skipped-study behavior, column naming, and return fields. It is long only because the tool has many behavioral nuances that matter for correct invocation.

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 explicitly lists what is returned: symbol, resolution, bar count, first/last bar, columns, and file path. Combined with fully documented input schema parameters and edge-case disclosures, an agent has everything needed to call and interpret the 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 coverage is 100%, so the baseline is 3, but the description adds integration context: write=false means inline rows, studies can be selected by name, count is capped at 500, and the export is joined on bar time. It does not restate each schema field but enriches how the parameters work together.

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: 'export the active chart as one table' with OHLCV bars plus study plots joined on bar time. This scope clearly differentiates it from sibling data-access tools like tv_get_bars and tv_get_study_values without needing to name 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?

It gives clear context: read-only, at most 500 bars, only what the chart has scrolled into memory, and how skipped studies behave. It does not explicitly name alternative tools or state when not to use it, but the caveats make the intended usage understandable.

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?

Beyond the readOnlyHint annotation, the description discloses specific behaviors: `presentation_data` is deliberately omitted and why, the condition is untruncated, and the response includes the raw snake_case REST payload. This tells the agent exactly what to expect from the call and why irrelevant megabytes are skipped.

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 verb and resource, then lists the returned payload pieces and one purposely omitted field. Every sentence earns its place, and the note about `presentation_data` is a useful heads-up that prevents the agent from expecting it.

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-id read tool with no output schema, the description is complete: it lists all return segments, leaves out a known irrelevant field with a rationale, and relies on the schema for id/layout/expect_layout. An agent can call it correctly without missing any workflow context.

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 three parameters are already documented in the input JSON schema. The description adds little parameter-specific meaning beyond identifying `id` as returned by tv_list_alerts, which is already present in the schema. The baseline 3 is appropriate because the schema carries the weight.

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?

Uses a specific verb ('read') and resource ('one alert') and then enumerates exactly what is included: full description, untruncated firing condition, projected model, and raw listAlerts payload. This clearly distinguishes it from the sibling list/create/delete alert tools without needing to inspect schemas.

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

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

The scope is clear: this is the full-detail read tool for a single alert, with the id format stated in the schema. It does not explicitly list alternatives like tv_list_alerts for summaries or tv_set_alert_condition for edits, but the read/full semantics provide strong context for when to invoke it.

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

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

Beyond the readOnlyHint annotation, it adds meaningful behavioral detail: a 500-bar cap, that TradingView only stores scrolled-in-memory bars, the `available` field indicates the true bar count, and failure to resolve the symbol is reported. This is exactly the sort of context an agent needs to interpret results correctly.

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 the core action. The 'Read-only' sentence adds minor redundancy, but the rest directly informs agent behavior (limit, memory blocking, error flag). No fluff.

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 there is no output schema, the description covers the main return semantics (OHLCV bars, ordering, max count), a status field (`available`), and a possible error condition (symbol failed to resolve). This is strong context for a tool of this simplicity, though it could spell out the exact response structure.

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 already provides full descriptions for all three parameters (count, layout, expect_layout) with 100% coverage. The description does not add any new meaning to these parameters beyond what the schema gives, so it stays at the baseline for full schema 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?

The description states the exact operation — reading OHLCV bars of the active chart from the loaded series — with the additional detail 'newest last'. This clearly distinguishes it from sibling getters like tv_get_chart_state or tv_get_study_values, which target different data.

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

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

It implies the tool is for reading raw OHLCV data of the chart, but it does not explicitly compare it with alternatives such as tv_export_data or tv_get_study_values. The memory limitation is stated, but the description stops short of telling an agent 'use this instead of X when you need only current in-memory bars.'

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Read-only' reinforces rather than contradicts them. Beyond annotations, the description adds genuine value by disclosing the full inventory of returned data, which tells the agent what it will receive before calling. It omits failure behavior (e.g., when no chart is open), but for a simple getter the bar is met.

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 short sentences with the verb and resource front-loaded, followed by a dense, useful list of returned fields. The second sentence 'Read-only' slightly duplicates the annotation but is harmless and costs little. No wasted words.

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 low-complexity read tool with zero required parameters, 100% schema coverage, and read-only annotations, the definition is essentially complete — nothing needed to invoke it correctly is missing. Minor gaps are the loosely typed 'extended symbol info' and the lack of an output schema or no-chart failure behavior.

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%: both layout and expect_layout carry detailed descriptions including default-tab semantics and the refusal condition when the tab shows a different layout. The tool description adds nothing about the parameters, 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 ('Read') with a concrete resource ('the active chart') and enumerates the exact payload: symbol, extended symbol info, resolution, chart type, study count, saved layout name and layout id. This naturally separates it from siblings like tv_get_bars and tv_set_symbol, though it never names a sibling explicitly, so it misses the top score.

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?

No when-to-use guidance is provided. The returned layout name/id overlaps with tv_list_layouts, the study count overlaps with tv_list_studies, and the symbol/resolution fields overlap with tv_get_bars, yet the description offers no decision rule for choosing among them. The 'Read-only' tag merely describes what it is, not when to reach for 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Read-only' adds no new safety information. The description does add useful behavioral detail about accepting a case-insensitive name substring, but it does not disclose behavior for no-match or ambiguous-match cases.

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 core purpose, and uses three clear sentences without fluff. The 'Read-only' note is slightly redundant with annotations but costs one word and does not harm clarity.

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 single-study tool with fully documented parameters, the description covers enough: what it reads, how the study is identified, and what output content to expect. Minor gaps like ambiguity handling and return format details are acceptable given the schema coverage and annotations.

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 input schema has 100% coverage, with each parameter, including 'study' and 'filter', already described. The description adds no parameter meaning beyond lightly restating the 'study' parameter's matching behavior, 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?

The description states a specific verb ('Read') and resource ('one study's inputs'), and enumerates what is returned (human names, types, options, ranges). This unambiguously distinguishes it from related tools like tv_get_study_values or tv_set_study_inputs, even without naming them.

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

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

The description conveys that this is the read-only retrieval tool for study inputs, which implies when to use it versus tv_set_study_inputs. However, it does not explicitly mention alternatives or provide exclusion criteria, leaving the routing decision 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?

Annotations already establish read-only and non-destructive behavior. The description adds valuable behavioral details beyond that: it explains the ordering of bars ('newest last'), how rows are keyed by plot title, the dropping of colour/fill plots unless include_decoration is true, and the special handling of built-in studies (returning formatted strings). These edge cases are not covered by annotations and materially affect invocation expectations.

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 tightly written, front-loading the core purpose and then adding necessary caveats in a logical order. Every sentence earns its place, covering identification, return format, decoration filtering, and built-in study behavior without redundancy. It is concise yet complete.

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 tool with a single required parameter and full schema coverage, the description covers the essential return format and edge cases (decoration plots, built-in studies). It does not need to explain the output schema since none exists, and the count/layout parameters are self-documented in the schema. Nothing an agent needs to call 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?

Schema description coverage is 100%, so the schema already fully documents every parameter. The description adds minimal parameter-level meaning beyond the schema: it reiterates that study accepts an id or name part (already in schema) and mentions the effect of include_decoration (also in schema). The description does not introduce new parameter semantics that would raise the score above the baseline for full schema 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?

The description opens with a clear, specific verb-resource pair ('Read the plotted values of one study') and explains how the study is identified (id or name fragment). It distinguishes itself from sibling read/write study tools by its explicit read-only scope and the data it returns. Even without naming a sibling, the purpose is unambiguous.

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

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

The description implies when to use the tool (to fetch plotted values of a study) but does not explicitly contrast it with alternatives like tv_get_study_inputs or tv_list_studies. However, the read-only nature and the mention of 'plotted values' make the context clear enough for an agent to select it appropriately. No exclusions are stated, but none are strictly needed.

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?

Annotations already mark readOnlyHint=true and destructiveHint=false, and the description reinforces this by declaring 'Read-only.' It goes far beyond the annotations by disclosing the 200-row cap, ordering (newest first), panel_pos semantics, per-field truncation limits, and the collapsing of large input/plotOffsets maps.

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?

Despite its length, every sentence carries operational information: purpose, read-only flag, ordering, row limit, full field list, positional-reference caution, and truncation caveats. The critical warnings about position and tv_get_alert fallback appear near the end, 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?

With no output schema, the description carries the full burden of describing the return value, and it does so extensively: all 15 fields, sort order, maximum rows, and truncation behavior. It also covers the important edge case of large study input maps and directs the agent to the right tool for full details. The only minor omission is how to handle >200 alerts (filtering vs. pagination), but that is partially addressed by the symbol and active_only filters in the 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?

All four parameters (layout, symbol, active_only, expect_layout) are 100% described in the input schema. The description adds nothing about parameter behavior beyond the schema; it introduces the output fields and filtering implications but does not elaborate on parameter syntax or valid values, 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?

The description opens with a specific verb and resource: 'List the account's TradingView alerts with their machine-readable firing condition.' It also labels the operation 'Read-only,' and later contrasts itself with 'tv_get_alert' when pointing to the full-detail fallback, so an agent can distinguish it from sibling alert-manipulation tools.

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 tells the agent when to prefer tv_get_alert ('use tv_get_alert for the full detail') for truncated fields. It also warns 'Refer to an alert by name + symbol, never by position alone,' which is essential context for using list output in later alert operations. These are concrete when/when-not signals.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations: it discloses that the paint probe runs one requestAnimationFrame per tab, which is a side effect an agent should know about despite the read-only nature. This is useful 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?

Two sentences with no wasted words. The core listing behavior and return fields are front-loaded, and the read-only note plus the paint probe detail are appended efficiently. 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 listing tool with no output schema, the description is nearly complete. It states what is returned and the one behavioral side effect. It could arguably mention that the output is a list of tabs, but the verb 'List' and the enumerated fields make that clear. The absence of an output schema is not a gap because the description enumerates the fields.

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 there is no schema burden to compensate for. The description fully explains what the tool returns, which is the only semantic content an agent needs. Baseline 4 for zero-param tools 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?

The description states a specific verb ('List') and resource ('every open TradingView chart tab') and enumerates the exact fields returned (index, layout id, title, url) plus the active/painting status. It clearly distinguishes itself from the sibling tv_list_saved_layouts, which lists saved layouts rather than open tabs.

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 makes clear this is for open chart tabs and identifies the active one, which implies it should be used when an agent needs to know which tabs are open and which is painting. It doesn't explicitly name alternatives or exclusions, but the sibling list (tv_list_saved_layouts) is implicitly differentiated by the word 'open' and 'chart tab'.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description repeats 'Read-only'. It adds context by naming the underlying API (TradingViewApi.getSavedCharts()) and listing the returned fields, which enriches behavioral understanding beyond the annotations.

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

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

Two concise sentences pack the core purpose, read-only nature, API source, and filter usage. No wasted words; the key action is front-loaded and 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?

For a read-only list tool with all parameters optional and fully documented in the schema, the description covers purpose, safety, and the filter behavior. It does not discuss edge cases or error conditions, but nothing critical is missing for correct invocation. It could add a note distinguishing from tv_list_layouts, but that is 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 description coverage is 100%, so all three parameters are already fully described in the schema. The description only reiterates the filter parameter and adds no new semantic value for layout or expect_layout. 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?

Clearly states the verb 'List' and the resource 'saved chart layouts' of the logged-in account, listing the exact fields returned. It is specific and unambiguous, but does not explicitly differentiate from the sibling tv_list_layouts, so it loses a point on sibling 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?

Mentions the optional name filter and its case-insensitive substring behavior, which gives a usage hint. However, it does not state when to choose this tool over tv_list_layouts or any other alternative, nor any exclusions. The guidance is present but implicit.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, which the description reinforces with 'Read-only'. It adds the specific scoping to 'the active TradingView chart' – useful context beyond the annotations. However, it does not disclose behavior like what happens with no studies or whether the result is sorted, so it adds only modest behavioral detail beyond what annotations already provide.

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

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

The description is a single, front-loaded sentence that wastes no words. It states the action, the resource, the output detail, and the read-only nature – all in under 20 words. Every element 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 read-only list tool with no output schema and fully described parameters, the description is largely complete. It covers the core purpose and the active-chart scope. The only minor gap is not stating the return format (e.g., array of objects with id and name), but this is easily inferred for a 'list' operation and not critical.

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%, meaning both parameters (layout and expect_layout) are fully documented in the schema. The tool description itself adds no parameter-level information, so it does not go beyond the baseline for a tool whose schema already covers the parameters.

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 (List), a clear resource (indicators/strategies on the active TradingView chart), and the output detail (study ids). It clearly distinguishes itself from siblings like tv_list_layouts and tv_get_study_values, making the tool's purpose unambiguous without requiring schema inspection.

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 clearly conveys when to use this tool: when you need to enumerate indicators/strategies on the active chart. It does not explicitly name alternatives or state when not to use it, but the purpose is so distinct that an agent can infer the right context. The read-only note also signals it is safe for reconnaissance.

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?

The description provides transparent behavioral details beyond the annotations: full page reload, ~20 seconds duration, waiting for chart readiness, reporting the landed layout/owner/read-only status, and refusing on unsaved changes. This aligns with the destructiveHint=true annotation because it can discard unsaved changes when discard_changes=true. No contradiction exists.

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

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

The description is three tight, information-dense sentences with no fluff. It front-loads the core action and scope, then adds timing, outcome reporting, and a key refusal condition. 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 tool with 5 parameters, annotations, and no output schema, the description is complete enough: it explains what the tool does, how long it takes, what it returns, and its destructive edge case regarding unsaved changes. An agent can correctly select and invoke this tool without needing additional context.

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 100% schema description coverage, the baseline is 3, but the description adds meaningful behavioral context tied to parameters: it explains the ~20s reload and readiness wait relevant to timeout_s, and clarifies the discard_changes behavior when unsaved changes exist. It does not add new syntax details beyond the schema, but the behavioral coupling is useful.

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 opens with a specific verb and resource: 'Open a TradingView chart URL (or bare layout id) in the bound chart tab.' It clarifies scope by including own layouts and other users' shared/View Only charts, which distinguishes it from sibling tools like tv_list_layouts and tv_get_chart_state. The uniqueness of the action is immediately clear.

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

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

The description clearly states when to use the tool: to open a chart URL or bare layout id in the currently bound tab. It also explains a key usage condition: it refuses when the current layout has unsaved changes unless discard_changes=true. It does not explicitly name alternatives or exclusions, 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?

Annotations declare destructiveHint: true, but the description states 'they stay defined but stop firing', implying the operation is not destructive and is reversible via tv_resume_alerts. This directly contradicts the destructiveHint annotation, making the behavioral disclosure unreliable. The description adds no clarifying context for the destructive flag, so it fails to provide transparent 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?

Two sentences, front-loaded with 'MUTATES' and the action, followed by the return format and reversibility. No fluff; every sentence contributes. The 'Verified live' note is minor but not distracting.

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?

The description provides the return format and notes reversibility, which is helpful given no output schema. However, it does not address the destructiveHint contradiction or clarify the layout/expect_layout parameters beyond their schema descriptions. While the tool is relatively simple, the contradiction and lack of edge-case guidance make it incomplete for reliable agent use.

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 already documents all three parameters with 100% coverage, so the description does not need to explain them. It adds no extra meaning beyond the schema, which is the baseline for full schema coverage. The mention of per-id return values is not parameter-specific.

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 clearly states the verb (stop/pause), the resource (alerts), and the mechanism (AlertsCollection.stopAlerts). It distinguishes from siblings by noting that alerts 'stay defined but stop firing' and explicitly mentions tv_resume_alerts as the reverse operation, making its purpose unambiguous.

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

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

It provides clear context: pausing alerts keeps them defined but stops firing, implying use when you want to temporarily disable them rather than delete. It also names the reverse tool (tv_resume_alerts). However, it does not explicitly contrast with tv_delete_alerts or state conditions for choosing this over other alert mutations, so a small gap remains.

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?

Beyond the destructiveHint annotation, the description adds substantial behavioral context: it explicitly states the tool MUTATES the broker, enforces a paper-trading-only gate, describes order sizing logic (qty from risk_usd/stop distance, market orders using chart price or entry_price), and explains dry_run behavior. This gives the agent a clear mental model of side effects and preconditions. No contradiction with annotations.

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

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

The description is long but dense and well-organized. It front-loads the core purpose and mutation warning, then systematically covers constraints, sizing logic, and dry_run guidance. Every sentence contributes new information; there is no fluff or redundancy. The structure aids quick comprehension for an agent scanning the description.

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 complex tool with 14 parameters and 3 required ones, the description covers all critical behavioral aspects: gate conditions, sizing algorithm, paper-only enforcement, and dry_run safety. The schema handles parameter syntax and enums, so the description need not repeat them. Given the absence of an output schema, the description's note that dry_run returns the exact pre-order is essential and provided. An agent has enough 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 coverage is high (93%), so the baseline is 3. The description adds meaningful semantic value by clarifying non-obvious parameter interactions: how qty is derived from risk_usd and stop distance, how market order sizing depends on chart layout or entry_price, and the purpose of dry_run. It does not repeat schema details but explains relationships between parameters, which is valuable.

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 ('place an order'), the resource ('connected TradingView broker'), and key constraints (mandatory SL, optional TP, paper only). It clearly distinguishes this tool from siblings like tv_close_position or tv_cancel_order by focusing on order entry, leaving no ambiguity about its role.

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 explicit conditions for use: PAPER ONLY, gate limits (risk ≤ 50 USD, max 2 positions, one per symbol, denied symbols), and a recommendation to use dry_run first. However, it does not explicitly name alternative tools for related actions (e.g., modifying brackets via tv_set_position_brackets), so the 'when not to use' aspect is only implied. Given the clarity of the tool's purpose, this is a minor gap.

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?

Annotations already indicate destructiveHint=true, but the description adds valuable behavioral details: it refuses read-only/View Only charts and returns the previous and new name. This goes beyond the annotations and informs the agent of side effects and safety checks.

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 with zero fluff. The action and scope are front-loaded, followed by a behavioral note and return info. 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 rename operation with 4 parameters (1 required) and full schema coverage, the description is sufficient. It covers the refusal behavior, the return value, and the scope. An agent can call it correctly without missing critical information.

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 each parameter is already documented. The description does not add extra meaning beyond the schema, but it reinforces the 'bound tab' concept that relates to the layout parameter. 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 action (rename), the resource (layout shown in the bound tab), and distinguishes it from other layout tools like tv_copy_layout and tv_delete_layout. Also notes the refusal condition and return value, making the tool's function unambiguous.

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 clear context by specifying the target is the layout in the bound tab, which narrows usage. It does not explicitly name alternatives or when to avoid this tool, but the context is enough to distinguish from other layout operations.

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?

Annotations already indicate mutation and destructiveness; the description adds useful context by revealing that webhooks are re-enabled, that the response contains per-id previous/current state read from the server, and that the operation is reversible via tv_pause_alerts. It does not contradict the annotations and provides meaningful beyond-schema 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?

Three compact sentences front-load the mutation verb and effect, then cover return values, reversibility, and a verification note. There is no filler or repetition; each clause adds information useful to 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?

With a fully documented schema, safety annotations, and no output schema, the description supplies the missing return-shape summary and the key side-effect warning about webhooks. An agent has enough information to invoke the tool correctly without external documentation.

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 input schema already documents all three parameters. The description's 'per-id' note concerns output rather than parameter meaning, so the description does not need to compensate. 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?

The description names a precise verb ('restart (resume)') and resource ('the given alerts'), and explains the concrete effect ('they begin firing again, webhooks included'). It also ties directly to AlertsCollection.restartAlerts and differentiates itself from tv_pause_alerts by noting the inverse relationship.

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 intended use is clear: resume alerts that were paused, with tv_pause_alerts explicitly identified as the reverse operation. It lacks a full 'do not use when...' exclusion list, but the context is strong enough for an agent to select this tool correctly among siblings.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only'. It adds the output type (PNG image) but does not disclose other behavioral details such as auth requirements or failure conditions; for a safe read-only capture tool, the annotations carry most of the burden.

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 two short sentences with no filler: the action and result are front-loaded, and the crop option is stated efficiently. Every word contributes 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 tool with three optional parameters, a fully descriptive schema, and read-only annotations, the description covers the core action, return type, and the main option. No output schema exists, but 'return it as an image' supplies the necessary return-value information.

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 layout, clip_to_chart, and expect_layout are already fully documented in the schema. The description adds only a brief restatement of clip_to_chart's cropping behavior, which does not materially extend the parameter meaning.

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 opens with the specific verb 'Capture', the resource 'the chart tab', and the output type 'PNG screenshot ... as an image'. This clearly states what the tool does and distinguishes it from every sibling tool, none of which are screenshot-oriented.

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 clear usage context: capture the chart tab and optionally crop to the chart container, while explicitly noting the tool is read-only. It does not name alternatives or exclusions, but no screenshot alternative exists among the siblings, so this is not a material gap.

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?

The description goes far beyond the annotations by disclosing that the call modifies a live alert through modifyRestartAlert, re-arms the alert, can restore a paused state after ~1s, and may fire real webhooks placing live orders. It also exposes reversibility through returning `previous` and notes the live-tested clone/modify/stop path, giving an agent a full safety picture.

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 dense but every sentence earns its place: it front-loads the action, then explains the return payload, rejection rules, the re-arm window, and the live-order risk. The wording is efficient and ordered by importance.

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 this is a mutating tool with no output schemabund, the description is remarkably complete: it covers return fields, error refusals, side effects, reversibility, and real-world danger. Nothing essential for an agent to invoke this tool safely 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?

Even though schema coverage is 100%, the description adds meaning beyond the schema: patch is explicitly a camelCase shallow-merge, identity fields are refused, unknown field names are refused, and `previous` can be fed back as a patch to undo the change. These are critical semantics for correct invocation.

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 opens with a specific verb and resource: 'MUTATES a live alert' and explains the exact operation (shallow-merge `patch` into the alert). This clearly distinguishes it from sibling tools like tv_create_alert, tv_get_alert, tv_pause_alerts, and tv_delete_alerts.

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 states clear context for use: this is the only server-accepted path, raw snake_case payloads are rejected, and the tool refuses empty patches, identity fields, and unknown field names. It does not explicitly name sibling alternatives or when-not-to-use conditions, but it gives enough operational guidance to select it 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?

Annotations only signal readOnlyHint=false and destructiveHint=true, so the description shoulders the behavioral burden and delivers: paper-only refusal, the no-override sanity gate against position side, the always-send-both-levels behavior, the read-back-until-consistent semantics, and the dry_run sends-nothing behavior. This is rich, non-obvious context an agent cannot infer.

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 core purpose and mutation flag are front-loaded in the opening sentence, followed by crowding conditions, usage constraints, and sanity gate in logical order. The closing 'Verified live... ~450 ms each' is slightly beyond the essential contract, but there is no redundancy or filler elsewhere.

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 destructive mutation with no output schema, the description explains the return shape (previous and applied levels, position before/after, read-back verification), the failure modes (paper-only, sanity gate), and the dry-run path. An agent has everything needed to call this tool correctly on the first attempt, including a safe validation mode.

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, and the description adds genuinely useful cross-parameter semantics that schemas cannot express: 'Give symbol or position_id', 'at least one of stop_loss/take_profit', the omitted-value-keeps-current rule, and the ordering/side sanity gates. It does not narrate each individual parameter, but it doesn't need to given full schema 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?

The description names the exact operation ('move the stop loss and/or take profit of an OPEN position via the broker adapter (editPositionBrackets)') and the mutation is signaled in the opening word MUTATES. It distinguishes itself from siblings like tv_place_order, tv_close_position, and tv_trading_status by scoping the resource to position stop-loss/take-profit brackets.

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 concrete invocation conditions: PAPER ONLY with a refusal on non-demo brokers, requires symbol or position_id plus at least one of stop_loss/take_profit, and recommends dry_run=true first. It does not explicitly route to alternative siblings or name a when-not condition, so it stops short of a full 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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds value by explicitly stating 'MUTATES' and mentioning the return value includes { previous, current } for revertibility. This provides extra context about the mutation and the ability to undo it, going beyond the raw annotations.

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 extremely concise—two short sentences. It front-loads the action ('MUTATES') and delivers the target resource and valid values immediately. No filler or redundant information is present.

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?

The description explains the operation and return value, and the schema documents all parameters. However, it lacks usage guidance (when to use versus alternatives) and does not address potential error conditions or prerequisites. The revert information is helpful, but the missing usage context keeps it from being fully 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?

The schema provides full descriptions for all three parameters (100% coverage). The description offers example resolution values, but these are already present in the schema. It does not add new constraints or elaboration on parameter meaning beyond what the schema documents.

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 clearly states the operation: 'change the active chart timeframe/resolution' and provides concrete example values ('1', '5', '60', '1D', '1W'). It identifies the resource (chart timeframe) and the action (change). It does not explicitly differentiate from sibling setter tools like tv_set_symbol, but the verb and resource are specific enough to avoid ambiguity.

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?

No guidance is provided on when to use this tool versus alternatives. The description only describes what it does, without mentioning any conditions, exclusions, or alternatives such as tv_set_symbol. An agent receives no context for selecting this tool over other modification tools.

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?

Annotations already provide destructiveHint=true and readOnlyHint=false, and the leading 'MUTATES' is consistent with them, so there is no contradiction. The description adds substantial context beyond annotations: values are 'coerced to the input's declared type and validated against its options/min/max,' it 'returns the previous value for every change so it can be undone,' and it re-reads after setting. This tells an agent the mutation is reversible and how values are processed.

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 with zero filler; the destructive 'MUTATES' warning is front-loaded, and every remaining clause ('re-read,' 'coerced,' 'validated,' 'returns previous value for undo') adds a distinct piece of information. Nothing repeats what the input schema already documents.

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 4-parameter mutation tool with 100% schema coverage and a destructive annotation, the description covers the core behavior, value processing semantics, and the undo mechanism. The only gap is that, with no output schema, the full return structure beyond 'previous value for every change' is 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%, so the baseline is 3 with the schema carrying the parameter documentation burden. The description adds some extra meaning by explaining how values in the inputs map are handled (coerced to declared type, validated against options/min/max), which the schema does not state, though it does not elaborate on individual parameter formats.

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?

Opens with the explicit verb 'MUTATES' and names the exact resource and action: 'set one or more inputs on a study by id, then re-read them.' The 'by id' scoping and the re-read behavior distinguish it from the sibling read tool tv_get_study_inputs without needing to open 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 mutating purpose is inferable by contrast with siblings such as tv_get_study_inputs (read counterpart) and tv_study_template (template application), so when-to-use is reasonably clear from context. However, the description never names an alternative explicitly or states when not to use this tool, leaving routing to agent 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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, so mutation is disclosed. The description adds substantial behavioral context: it states the return value includes previous and current for reverting changes, and it explicitly warns about TradingView's lack of up-front validation, directing the agent to verify the result. These details go beyond the annotations and are genuinely useful for correct invocation and error handling.

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 extremely concise: two sentences, both carrying essential information. The first sentence states the action and effect, the second provides a critical caveat about validation. No fluff or redundant content, and the mutation is front-loaded. This is exemplary brevity.

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 the tool's moderate complexity (3 params, schema fully documented, no output schema), the description covers the key behavioral aspects: mutation, revert capability, and validation caveat. It explains the return shape ({previous, current}) which the schema lacks. The only minor omission is clarifying what 'symbol_resolved' is, but that is a field in the result rather than a parameter, and its meaning is inferable. Overall, it is sufficiently complete for an agent to call the tool 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 input schema covers 100% of parameters with clear descriptions (e.g., symbol format, layout selector, expect_layout). The tool description does not add meaning beyond the schema; it merely restates the symbol example and mentions the return value, which is not parameter-specific. With full schema coverage, the baseline of 3 is appropriate; no extra parameter semantics are provided.

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 precise verb ('change'), a clear resource ('active chart symbol'), and includes a concrete example ('BYBIT:ETHUSDT.P'). It distinguishes itself from sibling tools like tv_set_resolution by explicitly targeting symbol, not resolution. The purpose is unambiguous.

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

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

The description establishes clear usage context: it mutates the chart and returns a revertible pair. It warns that TradingView does not validate the symbol up front, guiding the agent to check symbol_resolved after the call. While it does not explicitly name alternatives or when not to use, the distinguishing nature of symbol-setting versus sibling tools is implied by the focus on symbol.

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?

The description goes well beyond the annotations by explicitly warning that `apply` MUTATES THE CHART and REPLACES EVERY STUDY, that `delete` requires `confirm=true`, and that built-in templates refuse deletion. It also adds verified behavior such as list appearing in ~2 s, apply restoring studies, and delete taking effect in ~1 s.

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 long but dense and well-structured, using action labels as anchors. Each sentence contributes unique operational detail, including endpoint information, mutation warnings, and latency expectations, with the overall tool purpose 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 multi-action tool with 10 parameters and no output schema, the description is unusually complete. It explains return expectations for apply (studies before/after), snapshot (template object), list (custom before built-in), and delete (gone). The live round-trip verification further reduces agent uncertainty about real behavior.

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 baseline is 3case. The description adds meaningful action-parameter mapping: `replace=true` overwrites, `confirm=true` is mandatory for delete, `file` can be written by snapshot or read by apply, and `template` supports inline JSON. This goes beyond the schema descriptions.

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 clearly identifies the tool as managing TradingView indicator/study templates, with each action (`list`, `snapshot`, `save`, `apply`, `delete`) explicitly enumerated. It differentiates the tool from sibling study-related tools by focusing on saved templates and mutating the chart's study set rather than individual study values.

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?

Per-action usage guidance is explicit: snapshot is recommended before apply for undoability, delete requires confirm and refuses built-ins, replace overwrites existing templates. It does not explicitly compare to sibling tools like tv_list_studies or tv_get_study_values, but the action-based routing and clear read-only vs. destructive labeling give strong 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by revealing what state is read (broker id, account, positions, orders, capability flags, gate) and by noting that passing a symbol triggers extra tradability/price checks. No contradiction with annotations.

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

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

Two tight sentences with no filler. The primary purpose is front-loaded, and the optional symbol behavior is stated in a compact second sentence. Every phrase 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 read-only status tool with no output schema, the description covers the main returned data and the key optional behavior. It does not detail error semantics around expect_layout or the meaning of 'gate', but the parameter schema already explains expect_layout's refusal behavior, so the definition is reasonably 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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the meaningful consequence of the symbol parameter: it also checks tradability, qty step/min, and chart price. This adds non-obvious parameter semantics that help an agent decide whether to pass a symbol.

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 ('Read') and a clear resource ('the broker connected inside TradingView'), then enumerates the exact fields returned. This makes the tool's purpose unmistakable and distinguishes it from sibling trading-action tools like tv_place_order or tv_close_position.

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 clear context on when to use the tool: to inspect broker/account state, positions, orders, and tradability. It also explains the optional symbol behavior and the read-only nature. It does not explicitly name alternatives or state when not to use it, but the purpose is distinct enough among the siblings.

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