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

Beyond annotations, the description discloses meaningful behavior: the clone gets an independent ID, copied configuration, keeps the native clone name, and is requested in a paused state. This adds useful context about side effects and post-clone state, though it does not explain the role of idempotency_key.

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 compact sentences and front-loads the main action. The phrasing 'Make one native alert clone' is slightly awkward but not wasteful.

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 four-required-parameter mutation with no output schema and incomplete schema descriptions, the description is too thin. It omits when to choose this over sibling alert tools, what idempotency_key does, and what the verification step returns.

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 only 50%, and the description names no parameters. It does not explain alert_id, idempotency_key, or how target_id/expected_layout_id affect the clone, leaving required parameters undocumented in the description.

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

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

The description clearly states the action and resource: 'Make one native alert clone.' The word 'one' distinguishes it from bulk creation siblings like alert_create_bulk, though it does not explicitly differentiate from alert_create or alert_prepare.

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?

There is no explicit guidance on when to use this tool versus alert_create, alert_create_bulk, alert_prepare, or alert_reconcile. The only implied usage is cloning an existing alert, but no conditions, exclusions, or alternatives are stated.

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

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

Annotations declare idempotentHint=false, while the description advertises 'Durable idempotency'; that is a direct behavioral conflict. Valuable extra context about independent verification and the paused default exists, but the contradiction forces a 1.

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 dense sentences front-load the purpose and capabilities with little waste. The second sentence is slightly overloaded but remains structured and informative.

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 13-parameter nested create tool with no output schema and low schema coverage, the description omits too many operational details about notifications, expiration, webhook behavior, and condition subfields. It covers purpose and some condition semantics but not enough to confidently invoke across all parameters.

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 only 15% across 13 parameters, so the description must compensate. It maps the condition families and mentions idempotency and verification, but leaves active, symbol, message, resolution, webhook_url, notifications, message_format, expiration_days, and most condition subfields unexplained.

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?

Starts with a specific verb and resource ('Create a native alert directly') and clarifies it does not require a template. It also names supported condition families (price, strategy, indicator), but does not explicitly distinguish itself from siblings like alert_create_bulk or alert_prepare.

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 phrase 'without requiring a template' implies when to use this tool rather than a template-based path, but no alternative sibling is named. There is no explicit when-not guidance or mention of prerequisites such as target_id and expected_layout_id.

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?

Adds real behavior beyond the annotations: a validation pass happens before any writes, creation is sequential rather than parallel, and partial success is possible and explicitly reported. That last point is the key operational trait (a bulk call can half-succeed), which annotations do not convey. Minor tension worth noting: idempotentHint=false overall while the description promises 'per-item idempotency', which the agent must reconcile via idempotency_key.

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 with no filler, and the preflight-before-write ordering is front-loaded where the agent needs it. It is efficient, though 'explicit partial-progress report' is compressed enough to be slightly ambiguous about what the caller actually receives.

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 bulk-create with no output schema, the description covers the operationally critical facts: validate first, write one at a time, expect partial progress. The remaining gaps (stop_on_error semantics, item shape) are secondary to safely deciding to call it.

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?

At 50% schema description coverage, the description only adds meaning for one thing: idempotency_key's purpose. The richest, most error-prone part of the schema — the nested item definitions (name, condition.kind, symbol, notifications) and the stop_on_error flag — gets no explanatory support from the description, so it does not compensate for the coverage gap.

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 ('create ... native alert definitions') at bulk scope, plus the preflight-then-write sequencing, so an agent can tell it apart from alert_create. It never explicitly names the single-item sibling, so the differentiation is inferred from the name/plurality rather than stated.

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

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

The description describes internal mechanics (preflight, sequential creation) but gives no when-to-use or when-not guidance. It never mentions alert_create, alert_prepare, or alert_validate_message as the single-item/validation path, and never states the 50-item cap or that target_id must come from browser_list_tabs as a precondition.

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, idempotentHint=false, openWorldHint=true, so safety is covered structurally. The description still adds real value by stressing permanence, that only explicit IDs (no filter/wildcard scope) are affected, and that the operation includes a post-delete confirmation that those exact IDs are gone.

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

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

One dense, front-loaded sentence with no filler; permanence and the ID constraint lead. The trailing "confirm those exact IDs disappeared" is slightly ambiguous about who performs the confirmation and how, but it earns its place as a post-condition hint.

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, non-idempotent batch tool with no output schema, the description covers intent and precondition but leaves gaps: what "resolving" concretely means, behavior on partial failure, and whether the confirmation is internal or requires a follow-up call. Adequate but not 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 67% (target_id and expected_layout_id already documented in-schema). The description adds meaning to alert_ids by emphasizing "explicit" IDs and "those exact IDs", ruling out pattern or filter semantics, but it says nothing about the 50-item cap, ordering, or partial-failure handling.

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

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

Specific verb+resource: "Permanently delete explicit alert IDs" clearly distinguishes this from alert_pause/alert_update/alert_clear-style siblings by scoping it to explicit IDs. It doesn't name an alternative tool, but the operation and its scope are 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?

"only after resolving them" gives one precondition (IDs must be resolved first), which implies calling alert_list/alert_reconcile beforehand, but that inference is left to the agent. No explicit when-to-use-vs-alternative guidance (e.g. pause vs delete) is offered.

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 readOnly/destructive=false, so the bar is lower, yet the description still adds real value: ordering of filtering vs. pagination and the important caveat that a fire record does not prove webhook delivery. It stops short of stating sort order, result cardinality, or rate/limit 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 short, front-loaded sentences with no filler; the pagination mechanic comes first and the caveat last. Slightly terse on what 'filters' refers to, but nothing is wasted.

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

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

For a 5-parameter read with no output schema, the description should at least sketch what a fire record contains and which filters are honor-able. It covers pagination and one data-semantics caveat but leaves the return shape and the alert_id filter undocumented.

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

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

Only offset/limit are referenced, and only by repeating the pagination mechanic the schema already documents with defaults and bounds. With 40% schema coverage, alert_id is never explained and the implausible target_id/expected_layout_id parameters are left entirely unaddressed, so the description does not compensate for the coverage gap.

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

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

States a specific verb+resource ('page through ... firing history') and adds the pagination mechanism, so an agent knows this is a paginated read of delivery/fire attempts. It does not distinguish itself from the many sibling alert reads (alert_list, alert_get, alert_verify), leaving the boundary implicit.

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 on when to choose this over alert_get/alert_list/alert_verify, and no note that it is the tool for inspecting delivery attempts rather than alert definitions. 'Filters apply before pagination' is a mechanics note, not a selection rule, and the available filters are never named.

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 a genuinely useful behavioral fact: missing webhook/condition fields are returned as unknown rather than fabricated. It does not explain why a read tool carries target_id 'required for changes' or what expected_layout_id does, leaving some tension unexplained.

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 no padding; the core action is front-loaded and the caveat about unknown fields follows immediately. Every clause carries information.

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

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

For a single-record read with no output schema, the description plus annotations cover the essentials, and the unknown-field disclosure is a meaningful addition about return-data fidelity. It is still thin on what the 'native detail model' actually returns and on the three undocumented parameters.

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 only 40%: target_id and expected_layout_id are documented, but alert_id, include_message, and include_webhook_url are not. The description only obliquely gestures at one of these by mentioning 'webhook or condition fields', and says nothing about include_message or the alert_id format. It does not compensate for the coverage gap.

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 singular resource: 'Read one alert from the server and native detail model.' That distinguishes it from alert_list and alert_sources by scope (one vs. many). 'Native detail model' is jargon the agent may not parse, and no sibling is named explicitly, keeping it just below a 5.

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 statement of when to use this instead of alert_list, alert_verify, or alert_sources. The singular 'one alert' implies a detail-fetch, but there are no explicit exclusions or prerequisites (e.g., that an alert_id from alert_list is required first). An agent must infer the routing on its own.

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 cover the safety profile (readOnly, non-destructive), and the description adds genuinely new behavior: filters are applied before offset/limit, summaries are redacted, and there is no 500-alert total cap. Those are exactly the non-obvious traits an agent needs when paging.

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

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

Three short sentences, front-loaded with the core purpose and with zero filler. Each sentence carries distinct information: scope, filter ordering, and the paging loop.

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

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

With no output schema, the description usefully names the return fields next_offset and has_more. But it doesn't say what a 'redacted summary' contains, whether filters combine with AND semantics, or why write-flavored parameters exist on a read tool — leaving a multi-parameter enumeration under-explained.

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?

At 29% schema coverage, the description must compensate for the undocumented parameters, and it doesn't. It never explains what name, symbol, active, target_id, or expected_layout_id filter or mean in a read-only enumeration context — notably the two schema-described params read like write-operation artifacts. Only the offset/limit and next_offset mechanics get any treatment.

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 plus resource: page through the server-returned alert inventory with redacted summaries. That clearly separates it from alert_get (single alert) and alert_fires (firing history). It stops short of naming a sibling for contrast, but the enumeration framing 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?

It gives explicit loop mechanics (continue with next_offset until has_more=false), which is real usage guidance for this tool. However, it never says when to reach for alert_list versus alert_get, alert_sources, or alert_fires, so the alternative-selection decision 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?

Annotations already declare a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that eventual server state is polled, which is useful beyond annotations, but it remains vague about timeout behavior, side effects, and what happens on layout mismatch.

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 with no wasted filler. However, 'independently poll their eventual server state' is cryptic and does not clearly resolve into actionable behavior.

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?

This is a mutating operation with three required parameters and no output schema, yet the description does not explain what pausing means, what is returned, how timeout_ms behaves, or what happens when expected_layout_id mismatches. The schema covers some of this, but the description remains too thin for the tool's complexity.

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 50%: target_id and expected_layout_id are described in the schema, while alert_ids and timeout_ms are not. The description only says 'explicit alert IDs' and does not compensate for the undocumented timeout, ID format, or batch limits.

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: pausing explicit alert IDs. It does not distinguish the tool from nearby siblings such as alert_resume, alert_verify, or alert_reconcile, so an agent must infer when pausing is the right operation.

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 phrase 'explicit alert IDs' implies that IDs are required, but there is no guidance on when to use this versus alert_resume, alert_verify, or alert_reconcile. No prerequisites or exclusions are stated.

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

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

With readOnlyHint=true already declaring the safety profile, the description still adds real value by confirming nothing is created and by disclosing what comes back ('hashes and inspectable routing metadata'). It does not explain what a hash is for or how validation failures surface, but the mutation-safety question is answered consistently 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 sentences, zero filler, with the core purpose and the non-creating constraint front-loaded before the return-value note. Every clause carries 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 13-parameter tool with a nested object and no output schema, the description covers purpose and return shape but supplies no parameter-level guidance. It is minimally adequate for an agent that reads the schema carefully, but the low schema coverage means gaps remain.

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 only 15% across 13 parameters (including a nested condition object with kind/price/study_id/comparison/offsets_by_plot), and the description explains none of them. Notable semantics — why idempotency_key is required for a read-only prepare, what target_id and expected_layout_id guard against, how condition.kind selects which other fields apply — are left entirely undocumented.

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 ('build and validate'), a specific resource ('native price, strategy or indicator alert'), and an explicit non-effect ('without creating it'). The phrase 'from current chart state' further scopes it, which lets an agent distinguish it from the sibling alert_create without opening either 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?

'Without creating it' clearly frames this as a pre-flight step, so an agent can infer it precedes alert_create. However, no sibling is named explicitly and no conditions or exclusions are given (e.g. when to skip preparation and call alert_create directly), so it stops short of full routing guidance.

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

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

The description usefully states what will NOT happen (no automatic deletion, recreation or webhook tests), which adds context beyond readOnlyHint=true and destructiveHint=false. However, it leaves a real ambiguity: the schema's target_id ('Required for changes') and expected_layout_id ('stops the operation before writing') imply a possible write path that the 'read-only' claim does not explain.

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 with the read-only guarantee front-loaded and the negative guarantees after the semicolon. No filler, though 'webhook tests' is cryptic without additional context.

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?

This is a complex tool with a deeply nested schema and no output schema, yet the description never says what a reconcile returns (a diff? per-item status? mismatch list?). Combined with the unresolved read-only vs. 'before writing' tension, an agent cannot fully predict the tool's 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 67%, so the baseline is around 3. The phrase 'multiple desired alert definitions against their exact server IDs' loosely maps to the items array of alert_id + definition, but the description says nothing about target_id, expected_layout_id, or the 50-item batch limit.

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

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

The description names a specific operation: a read-only comparison of multiple desired alert definitions against exact server IDs. That distinguishes it from single-alert siblings such as alert_verify or alert_get, though it never names an alternative explicitly.

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

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

The 'comparison / reconcile' framing implies a drift-check use case, but there is no explicit when-to-use statement, no prerequisites, and no pointer to alert_verify or alert_get as the single-alert alternative. The agent must infer the routing.

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

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

Annotations already declare this is a non-read-only, open-world, non-idempotent operation. The description adds useful behavioral context by saying it independently polls eventual server state and explicitly avoids claiming a trigger or delivery occurred, which is valuable transparency 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 compact sentences, front-loaded with the action and followed by an important behavioral caveat. There is no filler and every sentence contributes.

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 core caveat that resume does not guarantee a trigger or delivery, which is important for an asynchronous mutation. However, it omits relevant details such as the expected_layout_id guard behavior and timeout semantics, and there is no output schema to fill those gaps.

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

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

Schema coverage is only 50%, and the description does little to compensate: it references "explicit alert IDs" but does not clarify target_id, expected_layout_id, or timeout_ms semantics beyond the schema. The schema itself documents target_id and expected_layout_id, but alert_ids and timeout_ms remain undescribed in both places.

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: "Resume explicit alert IDs," and adds the polling behavior. It clearly distinguishes resume from pause or verify, though it does not explicitly name an alternative sibling.

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 use when alerts are paused by mentioning "Resume explicit alert IDs," but gives no explicit guidance on when to choose this over alert_verify, alert_reconcile, or other alert tools. No exclusions or prerequisites are stated.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a real behavioral claim—it returns exact attachments rather than heuristically guessed plot indices—which is genuinely useful. However, it does not reconcile the odd idempotentHint=false on an ostensibly pure read, nor does it describe output shape.

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 discovery payload front-loaded and the negative constraint (no guessed plot indices) second. Nothing is padded, though the second sentence is terse enough to be slightly cryptic out of context.

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 effectively enumerates what is returned (IDs, versions, input metadata, alertcondition IDs), which substitutes for the absent output schema. But the schema's own parameter text mentions "Required for changes" and "before writing," implying a write-adjacent workflow that the description never explains, leaving the read-only vs. mutation-adjacent relationship ambiguous for the agent.

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

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

Schema description coverage is 100%, so both optional parameters (target_id, expected_layout_id) are fully documented in the schema itself, including the layout mismatch guard. The description adds nothing about parameters, which is acceptable at full coverage but earns only the baseline.

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?

A specific verb ("Discover") tied to concrete resources: attached Pine study IDs, versions, input metadata and alertcondition IDs. That distinguishes it from the sibling alert_list/alert_get tools, which presumably return alert records rather than the underlying study identifiers. It never says explicitly which sibling it replaces, so it stops short of a 5.

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?

There is no explicit when-to-use statement or named alternative. The clause "Does not guess plot indices" implies it is the safe precursor for alert creation/update where exact study IDs are needed, but the agent must infer that workflow. Usage is implied rather than stated.

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

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

Goes meaningfully beyond annotations: it discloses the re-arm guard ('refuses to re-arm a paused alert unless explicitly allowed'), which explains the allow_temporary_activation parameter, and the reporting behavior ('reports every unverified field'), which hints at partial-verification outcomes. It does not discuss atomicity or what happens to fields omitted from the patch, so it stops short of 5.

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

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

Two tight sentences, front-loaded with the operation and followed by the guard condition; every clause carries information. 'Through the native alert model' is the one soft phrase that adds little for an agent.

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

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

For a non-idempotent mutation with a nested patch object, 4 required params, 40% schema coverage and no output schema, the description covers the patch surface and the re-arm guard but omits whether updates are atomic, how omitted fields are treated, and what 'unverified field' reporting actually returns.

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 only 40%, with descriptions on target_id and expected_layout_id but nothing on alert_id, patch.active, or allow_temporary_activation. The description does map most of the patch sub-fields and implicitly explains the re-arm flag, but leaves `active` and `message_format` semantics and the alert_id format unexplained.

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

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

States a concrete verb+resource (update an alert) and enumerates the mutable fields (name, message, webhook, notifications), which lets an agent tell it apart from alert_pause/alert_resume/alert_delete. It does not explicitly say 'use alert_update for field edits, not alert_pause for active state,' so sibling differentiation is only implied.

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?

Usage is implied: this is the field-editing path, while activation state has dedicated siblings. However there is no explicit when-to-use/when-not statement, and the presence of `active` inside `patch` alongside the dedicated alert_pause/alert_resume tools leaves a real ambiguity the description never resolves.

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/destructiveHint, so safety is covered; the description adds two genuinely useful behaviors (no placeholder substitution, no network request). However, it does not say what a failed validation produces (exceptions vs. an error list), which matters for a validation tool with no output schema.

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

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

One sentence, front-loaded with the verb and the object of validation, with no filler. Slightly dense jargon ('exact alert-message bytes') but 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 two-parameter, no-output-schema tool, the agent still lacks the outcome semantics (what counts as valid, what is returned on failure) and the meaning of the format enum. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden and it does not: it never mentions that message_format controls whether JSON template structure is checked, nor any constraints on message (32KB limit, placeholder syntax). The enum parameter is left entirely to the schema.

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

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

States a specific verb (validate) and a specific resource (alert-message bytes and JSON template structure), and distinguishes itself from alert_create/alert_prepare by noting it does not send a request. It does not name the neighboring alert_* validation/prepare siblings directly, so the differentiation is implicit rather than explicit.

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?

Usage is implied by 'without ... sending a request' — a pre-flight check — but it never states when to choose this over alert_prepare, alert_verify, or alert_create. An agent must infer the position in the workflow.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral detail by saying the comparison is exact and includes webhook URL bytes, message bytes, conditions, symbol, timeframe, and activation; it still does not describe the return result or the expected_layout_id guard behavior.

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

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

The description is a single front-loaded sentence with no wasted text. It puts the comparison purpose first and then enumerates the exact dimensions being compared, making it easy to scan.

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

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

For a verification tool with a complex nested schema and no output schema, the description should ideally explain what the comparison returns and how mismatches are reported. It covers the compared fields well, but does not describe the result shape, error behavior, or the role of expected_layout_id, leaving meaningful gaps for an agent to infer.

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 50% and the definition object is deeply nested. The description clarifies several compared definition fields, including exact webhook URL and exact message bytes, but it omits alert_id, target_id, expected_layout_id, and many nested definition fields; the schema does describe target_id and expected_layout_id, so this is adequate but incomplete.

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, 'Compare', and clearly identifies the resource: the independent stored alert versus a desired native definition. It also scopes the comparison to exact webhook URL, exact message bytes, conditions, symbol, timeframe, and activation, which makes it readily distinguishable from sibling tools like alert_get, alert_create, and alert_update.

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 implied use case is verifying that a stored alert matches an intended definition, which is clear from the word 'Compare'. However, the description does not explicitly say when to use this instead of alternatives such as alert_get or alert_reconcile, nor does it state exclusions or prerequisites.

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 readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely useful context that sensitive fields (arguments, JSON bodies, cookies, webhook URLs) are deliberately excluded, which shapes what an agent can expect to find. It does not describe log ordering, retention, or response shape.

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 zero waste; the read action is front-loaded and the privacy exclusion follows immediately.

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-optional-param tool with no output schema, the definition covers purpose and privacy scope but omits the 'limit' semantics and any hint about log entry format, ordering, or volume, leaving gaps an agent must trial-and-error.

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 single 'limit' parameter has 0% schema description coverage (only default/min/max bounds), and the description never mentions it. An agent must infer that limit caps returned log entries. The description does not compensate for the schema gap.

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

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

States a specific verb and resource: 'Read local operation metadata logs.' Clear what it does. However, it doesn't differentiate from any sibling or clarify what 'local operation' means in this trading-platform context (audit of tool calls? order operations?).

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

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

No indication of when to use this audit log versus other introspection tools (security_status, session_health, tools_catalog, job_get). No exclusions or alternatives named; usage is only implied by the name.

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 non-read-only, open-world, non-idempotent, and non-destructive behavior. The description adds meaningful operational context: sequential execution, per-step reporting, default stop-on-failure, and explicit handling of partial success. It does not explain rollback/atomicity or what happens to already-executed steps after a failure, but the core behavior is substantially disclosed.

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

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

The description is front-loaded with the core action and scope, then adds failure and reporting semantics in a compact single sentence. Every clause carries useful information with no filler.

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

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

For a four-parameter batch executor with no output schema, the description covers purpose, ordering, reporting, failure defaults, and partial-success status. It could be stronger by stating whether prior successful steps persist after failure and what stop_on_error=false means, but the essential behavioral picture is present.

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

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

Schema coverage is 50%, with target_id and expected_layout_id already documented. The description adds the 100-call cap and the default stop-on-failure behavior, but it does not explain stop_on_error=false semantics, the arguments object, or how target_id and expected_layout_id affect execution beyond what the schema says.

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

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

The description gives a specific verb and resource: executing tool calls, up to 100, sequentially in one browser queue slot. It clearly describes batch execution rather than a single tool call, though it does not explicitly name sibling alternatives such as job_submit or direct single-tool invocation.

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 use case is implied by the batching scope and the one-queue-slot constraint, but there is no explicit guidance on when to choose this over individual tool calls, job_submit, or stream-based execution. It also gives no exclusions or prerequisites beyond what is embedded in the schema.

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 annotations already say readOnlyHint=false, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the description needs to explain only the browser focus side effects. It does not say whether the activation steals OS focus, what happens on failure, or that the layout guard can abort the operation; that guard appears only in the schema. It adds nothing 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?

It is a single front-loaded sentence with no filler. It is efficient, though arguably too terse for a mutating, non-idempotent action.

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

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

With no output schema and 100% schema coverage, the description has a low burden to meet. Still, for a non-idempotent, open-world tool, it does not describe failure behavior, effect on the user's visible window, or the layout verification step. That makes it adequate rather than 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%, and both parameters (target_id, expected_layout_id) are fully documented in the schema, so the baseline is 3. The word 'exact' reinforces that target_id must be exact, but it adds no 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: bringing a TradingView chart tab to the foreground. It is clearly distinguishable from browser_list_tabs, browser_close_tab, and browser_navigate. However, it does not name which sibling to use when the goal is actually switching panes (pane_focus) or opening a new tab.

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 no when-to-use guidance, no prerequisites, and no alternatives. It never says that target_id should come from browser_list_tabs or how this differs from browser_navigate/pane_focus. The only hint is 'this exact ... tab', which implies a precondition but does not state 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, openWorldHint=true, and destructiveHint=false. The description usefully adds that results distinguish actual availability from live validation and entitlements, but it does not explain the probing mechanism, latency, return shape, or why idempotentHint is false.

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

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

The definition is a single front-loaded sentence with no filler. It is dense and somewhat jargon-heavy, but it is appropriately sized and does not waste sentences.

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

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

This is a low-complexity read-only probe with fully described parameters and safety annotations. Still, there is no output schema and the description does not say what a capability report contains or how availability results are grouped, leaving a meaningful gap.

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

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

Schema description coverage is 100%, so both optional parameters are documented in the schema. The description adds no meaning about target_id or expected_layout_id or how they affect capability probing, 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?

It states a diagnostic action ('probe') and a reporting outcome ('report actual availability'), but 'known native browser interfaces' is jargon and the scope is left vague. No sibling tool is named, so the agent must infer how this differs from browser_list_tabs, security_status, or other diagnostic 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?

Usage is implied: use this to check capability availability, and the result separates availability from live validation and account entitlements. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many browser and diagnostics 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 destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds two pieces of non-redundant context: that the operation verifies the tab actually disappeared afterward, and that unsaved work should be preserved beforehand. It stops short of describing failure behavior for a failed close.

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

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

Three short sentences, front-loaded with the action, followed by the verification outcome and then the safety caveat. Nothing is padded and every clause carries information an agent can act on.

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

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

For a two-parameter tool with full schema coverage, rich annotations, and no output schema, the description covers action, safety precondition, and post-condition. Only the behavior on a failed close or a layout-ID mismatch (documented only in the schema) is left implicit.

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

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

Schema coverage is 100%: target_id's origin (browser_list_tabs) and expected_layout_id's mismatch-abort behavior are fully documented in the schema. The description's "this exact tab" only loosely gestures at target_id and adds nothing about the layout guard, so baseline 3 applies.

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

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

States a specific verb (close) and a scoped resource (this exact TradingView tab), plus an added post-condition (verify the target disappeared). This distinguishes it from browser_open_tab, browser_activate_tab, and browser_navigate, though no sibling is named explicitly.

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

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

"Save work first" gives a useful precondition for invoking the tool, but there is no explicit when-to-use/when-not guidance or pointer to alternatives (e.g., deactivate instead of close). Usage is only implied by the verb.

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 readOnly=true, destructive=false and openWorld=true, so the safety profile is covered; the description adds two genuine behavioral facts beyond them — results are filtered to eligible Superchart targets and browser cookies are never read. It still says nothing about pagination, ordering, or what happens when no eligible target 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?

Two sentences, zero filler, and the eligible-target scope is front-loaded before the privacy caveat. Nothing to trim.

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

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

There is no output schema, and since downstream calls need an exact target ID sourced from this tool, an agent would benefit from knowing the return shape and whether non-Superchart tabs are silently omitted. The read-only annotations and full schema coverage make this adequate but not complete.

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

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

Schema description coverage is 100%, so both parameters (target_id, expected_layout_id) are already fully documented in the schema, and the description adds no meaning about them. Notably it never explains why a list tool accepts an expected_layout_id guard, which would be worth a sentence.

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 ('List ... browser targets') and narrows the scope to 'eligible TradingView Superchart' targets, which lets an agent distinguish it from browser_open_tab, browser_activate_tab, and browser_capabilities listings. It never names a sibling explicitly, so it stops short of full differentiation.

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 sentence says when to call this versus alternatives; usage is only implied by the schema note that target_id comes 'from browser_list_tabs' (i.e. discover tabs before acting on them). The negative scope statement ('never lists unrelated tabs') constrains results but is not usage guidance.

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

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

Annotations declare openWorld=true, non-idempotent, non-destructive, non-readonly, so the description doesn't need to restate safety. It adds real behavioral context beyond them: the dirty-chart refusal guard and the post-navigation widget-ID verification, telling the agent the call can hard-fail rather than silently redirect.

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 zero waste; the action and its scope come first, the failure guard second. 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?

No output schema exists, and the description mentions the verification of the destination widget ID, giving the agent a sense of what confirms success. It could say more about what happens on a dirty-chart refusal (error vs. no-op) but is largely complete for a 3-param navigation 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 67% and target_id/expected_layout_id are well described there. The description frames the URL as a saved chart URL and implies expected_layout_id gates the write (mismatch stops), but the raw 'url' parameter itself has an empty schema description and the description adds no format or constraint detail beyond the schema's own fields. Baseline 3.

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

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

States a specific verb+resource ('Navigate this exact chart tab to a saved TradingView chart URL') plus the verification step (destination widget ID). An agent can tell this apart from browser_open_tab or layout_open, which create/open rather than navigate an existing tab to a saved chart URL.

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?

Clear usage context ('this exact chart tab', 'saved TradingView chart URL') and an explicit precondition/guard: it refuses to navigate away from an observed dirty chart. It does not name the sibling alternatives (browser_open_tab, layout_open) that an agent might confuse it with, so it stops short of full when/when-not routing.

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

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

Annotations already declare openWorldHint=true, idempotentHint=false and destructiveHint=false. The description adds real value beyond that: it states the tool returns the new exact target ID (the handle needed for subsequent operations) and warns that opening a saved URL does not create an independent layout, which is a non-obvious side effect an agent would otherwise miscalculate.

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 the main action front-loaded and the return-value/caveat second. The saved-URL clause is slightly compressed and could be misread, but nothing is filler.

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

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

For a mutating, non-idempotent browser tool with no output schema, the description supplies the return handle and a key side-effect caveat, and annotations cover the safety profile. Minor gaps remain on session prerequisites and what happens on failure, but the essentials for correct invocation are present.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the expected_layout_id mismatch guard. The description only reinforces the target-ID concept; it adds no syntax, format, or interaction details beyond the schema, so the baseline 3 applies.

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

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

A concrete verb and resource ('Open an HTTPS TradingView chart URL') plus the execution context ('dedicated Chrome session') and the return value. It partially differentiates from browser_navigate and layout_open via the target-ID return and the saved-URL caveat, but never names either sibling explicitly.

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

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

The 'HTTPS TradingView chart URL' qualifier and the saved-URL note imply when this applies, and the schema's 'target_id ... Required for changes' hints at the follow-up flow. However, there is no explicit 'use this instead of browser_navigate / layout_open when ...' guidance, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-obvious context — that images may contain chart/account information and stay local rather than being uploaded. However, with no output schema, it never explains how the PNG is delivered (inline payload versus file path) or any size limits, which is the key remaining behavioral gap.

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

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

Two sentences, zero waste: purpose first, privacy/data-handling second. Nothing is padded or restated from the title or schema.

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

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

For a two-optional-parameter read tool with full schema coverage and no output schema, the definition covers purpose and data-handling adequately. The missing return-format detail is the one thing an agent would still want, but the core call decision is supported.

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

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

Schema description coverage is 100%, so both parameters are documented in the schema and the baseline is 3. The description adds nothing about target_id (e.g., that omitting it captures the active tab) or about why a read-only capture would need expected_layout_id, leaving a meaningful semantic gap unfilled.

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?

"Capture the current TradingView tab as a PNG image" gives a specific verb, resource, and output format, which is enough for an agent to know what it gets back. It does not distinguish itself from nearby capture-style siblings such as ui_snapshot, layout_snapshot, or strategy_capture, so an agent must infer the boundary from the name alone.

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?

There is no statement of when to use this instead of ui_snapshot, layout_snapshot, or drawing_export, and no prerequisites such as requiring the tab to be activated first. The phrase "current tab" only weakly implies that context, leaving routing to guesswork.

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, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds that it reads both the native session ID and symbol-advertised sessions, but it does not explain why the tool is marked non-idempotent or what openWorld implies about the live chart read.

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?

It is a single front-loaded sentence with no filler, and every clause contributes to explaining what the tool reads. Nothing is buried or repeated.

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

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

There is no output schema, so the description must convey what comes back, and it does identify the returned content (native session ID plus advertised regular/extended sessions). It could more fully describe the response shape, but it is nearly complete for a simple read operation with fully documented parameters and safety 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?

Schema description coverage is 100%, so both optional parameters are fully documented in the schema. The description does not mention target_id or expected_layout_id at all, so the baseline 3 is appropriate since it adds no parameter-level context beyond what the schema provides.

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

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

The description names a specific verb ('Read') and resource ('native trading-session ID and symbol-advertised sessions'), making the purpose unambiguous. It doesn't explicitly distinguish itself from the mutating sibling chart_set_session, so it falls short of a 5.

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?

Usage is only implied: a getter for session info, so an agent can infer it should be used when it needs to know the current session rather than change it. There is no explicit when-to-use, when-not-to-use, or named alternative guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds the returned components, which is useful because there is no output schema, but it does not disclose browser-tab interaction, optional target_id behavior, or the expected_layout_id guard.

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 front-loaded sentence with no filler. It identifies the verb and the three return categories efficiently.

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

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

No output schema exists, so the description must carry return-value context. It names the top-level outputs but leaves 'selected chart' undefined and omits how target_id or expected_layout_id affect behavior; with full schema coverage and annotations, this is minimally adequate but not 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?

Schema coverage is 100%, so the parameter descriptions already explain target_id and expected_layout_id in detail. The tool description does not mention either parameter or add syntax or usage semantics beyond the schema, so baseline 3 applies.

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

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

States a specific read operation on chart state and names three concrete outputs: the selected chart, saved layout ID, and registered study IDs. It is distinguishable from layout_get or indicator_list because it returns combined chart state, though it does not explicitly contrast with chart_get_session.

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?

Implied use is to inspect current chart context, but there is no explicit guidance on when to choose this over chart_get_session, layout_get, or indicator_list, and no prerequisites or exclusions. The read-only framing gives some context but not decision rules.

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 the useful detail that values are Unix seconds, but says nothing about what the range covers (main chart vs pane), whether it changes during replay, or how it behaves if a chart is not ready.

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 front-loaded sentence with no filler. It is arguably too terse rather than too long, but nothing in it is wasted.

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

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

With no output schema, the description should convey the return shape, and "Unix seconds" only partially does so — an agent cannot tell whether it returns a start/end pair, an object, or a duration. For a simple two-optional-param read tool this is adequate but not complete.

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

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

Schema description coverage is 100%, so both optional parameters (target_id, expected_layout_id) are already documented and the baseline of 3 applies. The description adds no clarification, and notably does not resolve the oddity that target_id is marked "Required for changes" on a read-only tool.

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

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

States a specific verb and resource ("Read visible time range") plus the unit (Unix seconds), which is enough to distinguish it from the write counterpart chart_set_visible_range. It does not explicitly name the sibling it replaces or contrast with chart_get_zoom/chart_get_state, so it falls short of a 5.

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 no when-to-use context, no prerequisites, and no alternatives. An agent must infer from the name alone whether to use this versus chart_get_zoom, chart_get_state, or chart_scroll_to_date.

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's read-only phrasing is consistent with readOnlyHint=true and destructiveHint=false, and it adds useful context by naming the visible range measurements returned. However, with annotations already covering the safety profile, it does not add much behavioral detail such as target requirements or failure behavior beyond what the schema provides.

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 with no wasted words. It efficiently lists the three pieces of information the tool returns.

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

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

For a simple read tool with no output schema, the description does state what is returned, which is helpful. It remains incomplete because it does not clarify the relationship to the very similar chart_get_visible_range sibling or explain how target_id and expected_layout_id affect reads.

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 target_id and expected_layout_id are already fully documented in the schema. The description does not add any parameter-specific meaning, which is acceptable given the complete schema, 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 uses a specific verb, 'Read', and names the returned chart view details: visible logical bar-index range, time range, and bars per screen. It is clear what the tool does, but it does not distinguish itself from the sibling chart_get_visible_range, which sounds closely related.

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 what is read but gives no guidance on when to use this tool instead of chart_get_visible_range, chart_zoom, or chart_get_state. There are no exclusions, prerequisites, or alternative-selection rules.

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, destructiveHint=false, and openWorldHint=true; the description only reinforces this with 'without repair mutations,' clarifying it does not fix what it finds. It adds nothing about cost, timing, or what a failure state looks like, so it is a modest supplement rather than a substantive one.

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 with the core action front-loaded and no filler. The trailing clause 'without repair mutations' is slightly elliptical but earns its place by scoping behavior.

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 burden of describing returns and does so by enumerating the three report categories. It is adequate for a two-optional-parameter read tool, though the terminology would benefit from a word on what each finding means.

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

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

Schema description coverage is 100%, so both target_id and expected_layout_id are already fully documented, and the description adds no further meaning about them. Baseline 3 applies; the description does not explain why a read-only health check accepts an 'expected layout' guard.

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

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

States a specific verb ('Read') plus three concrete resource categories: chart capabilities, bar availability, and unaddressable studies. This distinguishes it from chart_get_state and session_health, though 'unaddressable studies' and 'bar availability' are jargon that requires domain inference.

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

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

The diagnostic/preflight intent is only implied by 'health' and 'capabilities'; the description never says when to call this versus chart_get_state, chart_get_session, or session_health, nor does it name any precondition such as loading a chart first.

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=false and idempotentHint=false, so the agent knows this mutates chart view state and is not repeat-safe. The description adds a useful post-condition ('verify it is visible') and the requirement that a visible span already exist, but says nothing about what happens on failure or whether the scroll is animated/awaited.

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 compact sentence with the operation front-loaded and no filler. The trailing 'and verify it is visible' is terse and slightly ambiguous, which keeps it from a 5.

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

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

For a mutating tool with no output schema, the description covers the core action and one post-condition but omits failure behavior (e.g., timestamp outside loaded data), whether the call blocks until the scroll settles, and what the verification result looks like to the agent.

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, including 'Unix seconds' for time and the layout-ID guard. The description's mention of 'Unix-second timestamp' merely restates the schema and adds no new semantics for target_id or expected_layout_id. 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 ('Centre') applied to a specific resource ('the existing visible span') on a chart, anchored to a Unix-second timestamp. The phrase 'existing visible span' implicitly distinguishes it from range-setting siblings like chart_set_visible_range, though no sibling is named.

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?

Using 'the existing visible span' implies this is a pan operation that preserves the current zoom, which hints at when to prefer it over chart_set_visible_range, but that guidance is only implied. There are no explicit when/when-not statements or named 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 this is a non-read-only, non-destructive mutation with open-world behavior. The description adds meaningful behavioral detail beyond annotations: it verifies the exact session and resolved symbol, and refuses during replay. It does not describe the return or error behavior, but the annotations cover the safety profile sufficiently.

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 with no filler. Every clause contributes either the primary action or a key operational constraint.

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 annotations and the schema's rich descriptions for most parameters, the description covers the essential behavior and constraints for this mutation tool. It leaves some context unexplored, such as failure modes beyond replay and layout mismatch, but no output schema exists and the remaining schema gaps are minor.

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

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

Schema coverage is 75%, with descriptions for session, target_id, and expected_layout_id already explaining exact ID sourcing and mismatch handling. The description reinforces exactness but does not add meaning for timeout_ms, nor does it compensate for the one undocumented parameter.

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: 'Set an advertised native trading session.' It also adds verification constraints, making the operation's purpose clear. However, it does not explicitly distinguish itself from the sibling chart_get_session beyond the verb difference.

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 includes a clear exclusion ('refuse during replay') and implies prerequisites through 'verify exact session and resolved symbol.' Yet it does not explicitly say when to use this tool versus chart_get_session or other session-related siblings, leaving usage partially inferred.

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 this is a non-readonly, non-idempotent, open-world mutation, and the description adds that it verifies both the chart label and the resolved main-series instrument identity – meaningful behavioral context beyond the annotations. It stops short of describing failure modes or what a failed verification looks like.

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

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

A single front-loaded sentence with no filler; the write action and the verification behavior are both stated up front.

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 3-parameter mutation with no output schema, the definition is mostly sufficient because the schema carries the parameter detail. However, since no output schema exists, the description should say how the verification outcome is reported, and it doesn't.

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

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

Schema coverage is 100%, so all three parameters (including the guard-rail expected_layout_id and target_id) are already documented in the schema. The description only echoes the symbol parameter's 'exchange:symbol' format and adds no new semantics for the other two.

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 ('Set') and resource ('full exchange:symbol') plus a verification step, so the agent knows it writes the chart's symbol and checks the result. It doesn't explicitly contrast with sibling pane_set_symbol, so it falls short of a 5.

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?

There is no explicit when/when-not guidance and no mention of alternatives such as pane_set_symbol or chart_symbol_search. The usage is only inferable from the verb and the parameter names.

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 this is a non-read-only, open-world, non-idempotent, non-destructive mutation. The description adds meaningful behavioral context beyond the annotations: it verifies the readback after setting and refuses to operate during replay. It could say more about failure handling or expected response, but the added traits are valuable.

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 with no wasted words. It communicates the action and two key behavioral constraints efficiently.

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

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

For a three-parameter mutation tool with fully documented schema fields and annotations covering safety traits, the description supplies the critical extra context: replay refusal and readback verification. It is nearly complete, though it could briefly clarify the distinction from pane_set_timeframe.

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 required parameters are already documented in the input schema. The description does not add any parameter-specific meaning, which is acceptable at baseline 3 when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Set timeframe') and adds a behavioral verb ('verify readback'), making the core action clear. However, it does not distinguish this chart-level operation from the sibling tool pane_set_timeframe, leaving some ambiguity about scope.

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

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

The description gives one useful context clue ('refuses during replay'), which implies when the tool will not work. It does not explicitly say when to use this tool versus alternatives such as pane_set_timeframe or chart_set_symbol, so guidance is implied rather than complete.

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 this is a non-read-only, open-world, non-idempotent, non-destructive mutation. The description adds the useful behavioral detail that the operation verifies readback, but it does not explain failure behavior, permissions, or what the verification actually 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?

The description is a single, front-loaded sentence with no filler. It states the action and the verification behavior without unnecessary repetition.

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 tool is a mutation with a layout guard and no output schema, so the description should clarify verification results and chart-type mapping. It mentions readback verification but does not explain what is returned or how to choose the numeric chart type, leaving important context to inference.

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 moderate at 67%; target_id and expected_layout_id are documented in the schema, while chart_type has only a 0-30 integer constraint. The description adds that chart_type is a numeric ID, but it does not explain which numeric ID corresponds to which chart type, leaving a meaningful semantic gap for the key parameter.

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

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

The description names a specific verb and resource: setting the TradingView chart type by numeric ID, plus a readback verification. This distinguishes it from nearby chart tools such as chart_set_symbol and chart_set_timeframe, though it does not explicitly reference those siblings.

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

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

It states what the tool does but gives no guidance on when to use it versus alternatives, no prerequisites, and no exclusions. The only implied usage is that the chart type should be changed and verified.

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 annotations already declare that this is a non-read-only, open-world, non-idempotent, non-destructive operation. The description adds useful context by saying the tool verifies the range "within the stated tolerance," but it does not explain failure handling or what verification entails beyond the schema's expected_layout_id guard.

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 with no wasted words. It communicates the core action and verification behavior immediately.

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 five-parameter mutation tool with required target and layout guard fields, the description covers the essential action and verification. However, it omits usage context and does not explain what the verification behavior means operationally, leaving some reliance on the schema 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?

Schema coverage is 80%, so the schema already documents from, to, target_id, and expected_layout_id. The description reinforces Unix-second semantics and refers to the tolerance parameter, but it does not add detail for the optional tolerance_seconds or clarify the guard parameters beyond what the schema provides.

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

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

The description names a specific verb and resource: "Set visible Unix-second time range," and adds a verification behavior. It is clear what the tool does, though it does not explicitly distinguish itself from sibling navigation tools such as chart_get_visible_range or chart_scroll_to_date.

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 states the action but gives no when-to-use guidance, prerequisites, or alternatives. An agent is left to infer that this is the write counterpart to chart_get_visible_range and when to choose it over chart_scroll_to_date or chart_zoom.

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 only the "selected chart" scoping, and it does not explain the surprising idempotentHint=false on a read tool — presumably because it depends on which chart/tab is active — nor does it say what happens if no chart is selected.

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

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

One short, front-loaded sentence with no padding, but it is terse to the point of under-specification — the brevity costs information rather than saving 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?

There is no output schema, so the description should indicate what "symbol metadata" contains and what happens when no chart is active. Instead the agent is left to call blind and discover the return shape from the response.

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 baseline 3 applies. The description adds nothing about target_id or expected_layout_id, and notably does not clarify that expected_layout_id (a write-guard) is even meaningful for a read-only call.

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

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

It states a verb (Read) and resource (symbol metadata) scoped to the selected chart, but "symbol metadata" is undefined — tick size? exchange? session? — and the description does not distinguish this from chart_get_state, chart_get_session, or chart_symbol_search, all of which plausibly touch the same symbol.

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

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

There is no statement of when to use this instead of a sibling. The most obvious near-neighbor, chart_symbol_search, and chart_get_state are never mentioned, so the agent must guess which one returns symbol metadata.

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, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description usefully adds that lookups hit TradingView's live browser API rather than a cached external service, which explains the open-world behavior. It does not explain the tab-context requirement or whether results are ranked, so credit stops at 3.

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

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

One short, front-loaded sentence with no filler, which is good. However, the sentence spends its only content on implementation trivia ('no external lookup service') rather than on information the agent actually needs, so brevity here comes at the expense of usefulness.

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 should say what a result looks like (symbol, exchange, asset type, ranking) and that a live chart tab identified by target_id is required. Instead it omits return shape entirely and leaves the strange mutation-flavoured parameters (target_id, expected_layout_id) unexplained for a readOnly tool.

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

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

Schema description coverage is 75% (query, target_id, expected_layout_id documented; limit undocumented), so the schema carries most of the burden and baseline 3 applies. The description adds nothing about how query is matched (prefix vs fuzzy), what limit defaults to, or why a read-only search takes a target_id and expected_layout_id.

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

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

States a specific verb+resource (search symbols) and adds the implementation route (TradingView's native browser API). It is reasonably distinguishable from chart_symbol_info, but it never names that sibling or clarifies that this returns candidate matches rather than details for one symbol.

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

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

The clause 'no external lookup service' implies the search runs against the live browser session, so an agent can infer a tab is needed. But there is no explicit when-to-use guidance, no mention of chart_symbol_info as the follow-up, and no note about what to do when results are empty.

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, openWorldHint=true, non-destructive, and non-idempotent. The description adds real value by defining the wait's scope and explicitly disclaiming a freshness guarantee, but it says nothing about what happens on timeout, what a successful wait returns, or that timeout_ms caps out at 30s. 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?

One short sentence with the operation front-loaded and the caveat trailing. No waste, though it is dense enough that the caveat clause is easy to skim past; a slightly longer explicit contrast would cost little.

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 five-parameter, zero-required wait tool with no output schema, the description covers purpose and scope but not outcome semantics: an agent cannot tell whether this returns the observed state, a boolean, or throws on timeout. That is the main missing piece for a blocking call.

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 80% and most params are well documented, so the baseline would be a 3. The description earns a bump by tying the wait semantics to the symbol and timeframe parameters, clarifying that those are expectations to be matched rather than values to set — a distinction the schema's one-line 'Expected symbol' only weakly conveys.

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 (wait) and the exact conditions being waited on (symbol, timeframe, loaded bars), which separates it from chart_get_state (a point-in-time read) and from mutation tools. The clause 'does not assert strategy freshness' carves out a scope boundary, though it never names the sibling (strategy_wait) that presumably covers that case.

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 negative guidance ('does not assert strategy freshness') hints at when to prefer another tool, but it is never made explicit — no named alternative and no statement of when this tool must be called (e.g., after chart_set_symbol before reading data). Usage is only implied.

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 it is not read-only, is non-idempotent and open-world. The description adds genuinely new context by saying it verifies actual range movement or requested bar endpoints after zooming, hinting at a post-condition check. However it omits what happens on verification failure, how tolerance is applied, and whether bars and direction are mutually exclusive.

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 front-loaded sentence with no wasted clauses. It is dense to the point of jargon ('native step', 'bounded count of loaded bars'), which costs a little clarity but keeps it tight.

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?

A 7-parameter mutation tool with no output schema and sparse schema descriptions needs more from the description. Mode exclusivity, failure behavior, and the verification result are all unaddressed, leaving material gaps for correct invocation.

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 only 29% (target_id and expected_layout_id only). The description obliquely gestures at direction ('one native step in/out'), bars ('bounded count of loaded bars') and tolerance/right_index ('verify ... endpoints'), but does not explain right_index, tolerance_bars, timeout_ms, or whether bars and direction are alternative modes. With low coverage the description should compensate more than it does.

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 (zoom) and resource (chart view) and distinguishes itself from chart_get_zoom/chart_set_visible_range by naming two distinct modes: a single native step and a bounded bar count. It's clear what the tool does, though the mapping of mode to parameter is left implicit.

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 on when to use this versus chart_set_visible_range, chart_scroll_to_date, or chart_get_zoom, and no exclusions or prerequisites. Usage is only implied by the verb 'zoom'.

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?

Goes beyond the annotations by disclosing a fail-fast consistency guard: the export aborts if the loaded range or selected market changes mid-pagination, and the file is "confined" (sandboxed). This is meaningful context consistent with idempotentHint=false. It stops short of saying where the file lands or whether prior files are overwritten.

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 with the action and the consistency guarantee front-loaded; no filler or redundant restatement of the schema.

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

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

For a tool with zero required params, no output schema, and no explanation of the return value (file path? job handle? summary counts?), the definition leaves a real gap. Annotations cover safety, and the failure semantics are covered, but the agent cannot predict what it gets back.

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

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

With 50% schema coverage, the description compensates for format by naming JSON and CSV explicitly, but says nothing about max_bars, which is only bounded (1–1,000,000) in the schema with no explanation of truncation behavior. target_id and expected_layout_id are already documented in the schema.

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

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

States a concrete verb+resource ("Export all currently loaded bars") and the output shape (JSON or CSV file). It implicitly separates itself from data_get_ohlcv by producing a file rather than returning values, but it never names that sibling or clarifies how the two differ in practice.

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?

Usage is implied by "currently loaded bars" — you must have data loaded first — and the failure condition during pagination hints at large-range exports. However, no explicit when-to-use/when-not guidance and no named alternative among data_get_ohlcv, strategy_export, or research_export.

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, so the bar is lower. The description adds meaningful behavioral context by saying the value is the 'latest loaded candle' and not a live bid/ask quote, implying chart-data freshness semantics rather than real-time quote semantics. It does not describe missing-data behavior or return shape, which keeps it below a 5.

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

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

The description is a single efficient sentence with no wasted words. The key distinction from a quote is front-loaded after the action statement.

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

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

For a simple read-only tool with full parameter documentation and annotations, the description covers the core action and the quote distinction. However, with no output schema, it could say more about the returned candle fields or behavior when no bar is loaded, leaving a modest completeness gap.

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

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

Schema description coverage is 100%, so both optional parameters are already fully documented in the schema. The description adds no parameter-specific semantics, which is acceptable given full schema coverage but not above baseline.

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: 'Read the latest loaded candle.' It also distinguishes the result from a bid/ask quote, which helps separate it from quote_get and quote_batch siblings. It does not explicitly distinguish itself from data_get_ohlcv, so it is clear but not fully sibling-differentiated.

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

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

The phrase 'this is not a bid/ask quote' gives useful negative guidance about when not to use this tool. However, it does not state when to use it instead of data_get_ohlcv or quote_get, nor does it mention prerequisites or 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds two genuinely useful behavioral facts: only 'loaded' history is served and responses carry explicit units and coverage. It says nothing about what 'loaded' means in practice (which symbol/timeframe/pane supplies the data) or pagination traversal cost.

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 front-loaded sentence with no filler; the pagination and ceiling claims come first. However, the terseness leaves no room for the scope caveats the tool actually needs.

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

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

For a 5-parameter tool with 40% schema coverage and no output schema, the description is thin: there is no way to learn which chart/pane/symbol the 'loaded' data comes from, how limit/offset interact, or why browser- and layout-oriented parameters appear on an OHLCV read. The 'explicit units and coverage' claim is not expanded enough to substitute for the missing output schema.

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

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

Schema coverage is only 40%, so the description must compensate, yet it explains none of limit, offset, or order beyond the word 'paginated'. It also leaves the two described parameters (target_id 'Required for changes', expected_layout_id 'A mismatch stops the operation before writing') unaddressed, which is especially confusing for a read tool.

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

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

States a specific verb and resource (read OHLCV history) plus the scoping traits 'paginated' and 'loaded'. It does not name or distinguish itself from closely related siblings like data_get_last_bar or data_export_ohlcv, so an agent must still infer which read path applies.

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 indication of when to prefer this over data_get_last_bar (single bar), data_export_ohlcv (export), or data_get_study_values. The phrase 'no fixed 500-bar ceiling' hints at large-range use, but no explicit conditions, prerequisites, or exclusions are stated.

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 cover readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is provided elsewhere. The description adds no behavioral context beyond that: nothing about whether the target tab is required, whether results come from the live chart or a saved layout, or how pagination behaves — notable because target_id is annotated "Required for changes" yet this is a read tool.

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

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

A single short sentence with zero filler and the disambiguation front and center. It is efficiently written, though its brevity shades into under-specification rather than tightness.

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?

Five parameters, no output schema, and 40% schema coverage means the description should explain the return shape and the pagination/scoping semantics — it explains neither. For a read tool whose data model (box primitives) is non-obvious, one disambiguation sentence is not enough to call it safely or interpret results.

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 only 40%, so the description carries real burden for limit, offset, and entity_id — and it says nothing about any of them. It does not clarify whether entity_id scopes to a chart object or a script, nor what ordering limit/offset apply to.

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 verb+resource ("Read Pine box primitives") and does distinguish the data from manual chart drawings, which is a useful boundary against a large family of drawing_* siblings. But "primitives" is jargon and the description never says what a box record actually contains or returns, so an agent still has to guess at the payload shape.

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 only guidance is negative framing — don't confuse with manual chart drawings — with no positive when-to-use, no prerequisites, and no named alternative tool to use instead. Siblings like drawing_list and data_get_pine_lines are present but none are routed to explicitly.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only 'Pine-generated' context and does not explain pagination behavior, default limits, whether an empty result means no labels vs no chart, or why idempotentHint is false for a read operation.

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

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

A single short sentence with the resource front-loaded and no filler. It is efficient, though efficient at the cost of under-specifying the call contract.

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 does at least enumerate the returned values (text, prices, native coordinates), which is the minimum an agent needs for a read tool. However, for a 5-parameter paginated read exposed alongside four sibling Pine readers, it omits filtering, paging, and scoping details that materially affect a correct call.

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 only 40%, and the description says nothing about limit/offset paging, the entity_id filter, or how target_id scopes the read to a Chrome tab. Those parameters are left to their bare types, so the description fails to compensate for the coverage gap.

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

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

States a specific verb (read) and resource (Pine-generated labels), and names the returned fields (label text, prices, native coordinates), which distinguishes it from data_get_ohlcv/study_values. It does not explicitly differentiate itself from the other Pine drawing readers (lines, tables, boxes), leaving that inference to the name.

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?

There is no when-to-use guidance, no mention of prerequisites (chart open, script running, target tab), and no routing to alternatives such as data_get_pine_lines for line objects. The agent must infer everything from the tool name.

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, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds that pagination is scoped per study, which is real behavioral context, but it leaves unexplained why a read tool carries write-guard parameters (target_id, expected_layout_id) and does not mention what happens when offset exceeds available data.

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

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

One short sentence with the resource and the pagination scope front-loaded and no filler. It is efficient but so terse that some of the omission is under-specification rather than true conciseness.

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?

A 5-parameter read tool with no output schema and 40% schema coverage needs more from the description: what a 'line' primitive contains, what entity_id identifies, and the default/max paging behavior. As written, an agent cannot confidently construct a call without guessing at entity_id.

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

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

Schema coverage is only 40%: limit, offset, and entity_id have no descriptions at all. The description's 'per-study pagination' hints that limit/offset operate within a study, but entity_id — the key selector — is never explained in either place, so the gap is not compensated.

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

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

Specific verb ('Read') plus a specific resource ('Pine-generated line primitives') and a scope qualifier ('per-study pagination'). The sibling set (data_get_pine_labels, data_get_pine_tables, data_get_pine_boxes) makes the resource distinction inferable, though the description never names those alternatives explicitly.

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

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

There is no guidance on when to call this versus the other data_get_pine_* readers, and no stated prerequisites (e.g., a chart/study must be loaded). Only the pagination scope is mentioned, which is behavioral, not usage-selecting.

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, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds one behavioral trait beyond annotations: it preserves original row/column coordinates and blanks. It does not mention pagination behavior, the role of target_id, or what happens when expected_layout_id mismatches, leaving some behavioral gaps.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and the key preservation behavior compactly.

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 five parameters, no required fields, low schema description coverage, and no output schema, the one-sentence description is too thin. It does not explain pagination via limit/offset, the purpose of entity_id, or the significance of target_id and expected_layout_id, leaving an agent without enough context to invoke the tool confidently.

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 only 40%, with limit, offset, and entity_id undocumented in both schema and description. The description does not explain any parameter semantics, so it fails to compensate for the low coverage. The two documented parameters (target_id and expected_layout_id) are explained only in the schema, not in the description.

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

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

The description states a specific verb and resource: "Read Pine table cells." It also specifies a distinctive behavior, preserving original row/column coordinates and blanks. It does not explicitly differentiate itself from sibling tools such as data_get_pine_lines, data_get_pine_labels, or data_get_pine_boxes, so it falls short of a 5.

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 no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The implied usage is simply reading Pine table cells, but there is no context about pagination, target_id, or expected_layout_id usage.

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 safety is covered structurally. The description adds that this reads current values and can target all studies or one exact entity, but it does not disclose return behavior, pagination, or any operational constraints beyond what annotations and schema 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 with no filler. The read action and scope are immediately clear.

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 tool is a read-only operation with three optional parameters and no output schema. Annotations and schema cover much of what an agent needs, but the description leaves gaps around what a Data Window value is, what happens when entity_id is omitted, and what shape the result takes.

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 67%, with descriptions for target_id and expected_layout_id but none for entity_id. The phrase 'one exact entity' gives some meaning to entity_id, but the description does not explain the relationship between entity_id, target_id, and expected_layout_id. Baseline 3 is appropriate given partial 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 gives a specific verb and resource: reading current Data Window values. It also states the scope, all studies or one exact entity. It does not explicitly distinguish itself from nearby data_* siblings, but the resource is concrete enough to identify the tool.

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

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

Usage is implied by 'Read current Data Window values' and the all-studies versus one-entity scope. There is no explicit when-to-use guidance, no exclusions, and no named alternatives such as other data retrieval 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 flag destructiveHint=true and idempotentHint=false, but the description adds real value beyond them: it discloses an optimistic-concurrency guard ('refuses if the live set has changed') and that only the supplied IDs are touched. It stops short of saying whether the removal is atomic across the whole set or what error surfaces on refusal.

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, zero waste, with the scope restriction and the refusal behavior front-loaded. Nothing could be removed without losing 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?

For a destructive, non-idempotent mutation with no output schema, the definition covers scope and the concurrency guard but omits recovery guidance (re-run drawing_list after a refusal) and how an agent should obtain expected_layout_id. Adequate but leaves a real operational gap.

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

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

Schema coverage is 67%: target_id and expected_layout_id are self-documented, while expected_ids has no top-level description. The description compensates by stating the array must be the COMPLETE set (not a subset), which is semantics the schema does not convey, and explains that a layout mismatch blocks the write.

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?

Names a specific verb (remove) and resource (the supplied set of drawing IDs), and adds the distinguishing constraint that the set must be complete. However, it never distinguishes itself from the sibling drawing_remove, and the tool name ('clear') suggests clearing everything while the description says only the supplied IDs — an agent must reconcile that on its own.

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?

'after inspection' implies a precondition (inspect via drawing_list first) but never states it explicitly, and there is no guidance on when to pick this over drawing_remove or drawing_update. Usage is inferable from the intent of the tool but not spelled out.

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 cover the safety profile (openWorld, non-idempotent, non-destructive), so the description earns credit for adding real context: it discloses that the tool reports coordinate/property fidelity rather than assuming them, implying the resulting shape type or points may differ from what was requested. It still doesn't disclose failure modes or whether partial writes can occur.

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 the verb and the verification behavior front-loaded; nothing is padded. Slightly dense phrasing ("native drawing", "fidelity") costs a bit of immediate 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 an 8-parameter mutation tool with no output schema, the mention that it reports coordinate/property fidelity usefully substitutes for return-value documentation. However, it leaves the shape-to-points relationship, the target tab requirement, and the layout-ID guardrail entirely to the schema, which is thinly described.

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 only 38% across 8 parameters, including a nested points array and a free-form properties object. The description mentions no parameters at all — not shape, points cardinality per shape, target_id, or the expected_layout_id precondition — so it fails to compensate for the coverage gap.

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 ("Create a native drawing") and adds a distinctive post-condition: verifying the new entity ID and actual shape type. This differentiates it well from drawing_update/drawing_import, though it never names those siblings explicitly.

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

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

There is no statement of when to use this versus drawing_import, drawing_update, or drawing_create alternatives, and no prerequisites are given in prose. The only usage signal is implicit in the verb 'Create', which an agent must infer.

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, destructiveHint=false and openWorldHint=true, so safety is covered; the description adds genuinely new context by disclosing that the export is lossy ('Marks missing fields; does not advertise perfect restoration'). That lossiness warning is exactly the kind of characteristic an agent cannot get from the annotation flags. It does not mention where the file lands or how conflicts between repeated exports are handled, keeping it below a 5.

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

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

Two short sentences with the purpose front-loaded and the caveat second; nothing is wasted. The trailing clause 'does not advertise perfect restoration' is slightly awkward phrasing where a direct 'restoration may be incomplete' would read cleaner.

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, a fully documented three-parameter schema, and read-only annotations, the description covers what an agent most needs: that this is a bulk, lossy export to a local file. Remaining gaps are modest — the destination/return shape of the JSON is not described, though the readOnlyHint=true combined with local file output could confuse an agent about side effects.

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 schema, including the important note that target_id comes from browser_list_tabs and that expected_layout_id acts as a guard. The description contributes no additional parameter meaning, 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 opens with a specific verb+resource pair ('Export every available drawing point and property to local JSON') and clarifies the scope as a complete dump rather than a targeted read, which distinguishes it from drawing_get and drawing_list. It stops short of naming those siblings explicitly, so differentiation is implied rather than stated.

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

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

The 'every available' phrasing implies this is the bulk-export path versus the single-object drawing_get, and the local-JSON framing implies a persistence use case. However, there is no explicit when-to-use, when-not-to-use, or prerequisite statement (e.g., that target_id is needed to scope the export to a specific 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 establish the safe-read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely non-obvious behavior: it returns a preimage fingerprint (useful for expected_layout_id compare-and-swap) and explicitly flags that some fields may be unavailable — details an agent could not get from 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?

Two compact sentences, front-loaded with what is returned and followed by the notable extras. Zero filler.

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

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

With no output schema, the description does a good job enumerating return contents and edge cases (unavailable fields, fingerprint). It stops short of explaining how the fingerprint is meant to be consumed or what 'unavailable' means operationally, leaving a small gap for a read tool.

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

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

Schema description coverage is 100%, so `id`, `target_id`, and `expected_layout_id` are fully documented in the schema itself. The description adds no parameter-level meaning (e.g., that target_id is only needed for changes, or how the fingerprint relates to expected_layout_id), so baseline 3 applies.

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

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

The description uses a specific verb ("Read") and enumerates exactly what state is returned: points, properties, visibility, lock and selection state. Combined with the name drawing_get, the resource is unambiguous. It does not, however, explicitly contrast itself with siblings like drawing_list or drawing_export.

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?

There is no statement of when to use this versus drawing_list, drawing_export, or layout_snapshot, and no note that it requires a specific drawing id. Usage is only inferable from the name and required `id` parameter.

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?

Adds behavior the annotations cannot express: fail-fast semantics ('stops at the first failure'), the return of created IDs, and an explicit warning that partial writes are not rolled back. This tells the agent exactly how to reason about a non-atomic, non-idempotent mutation.

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 dense sentences with zero filler: the first states creation plus verification, the second states failure and return behavior. The key safety caveat is front-loaded.

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

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

Covers the return value (created IDs) despite no output schema and discloses the non-atomic failure model, which is the main risk for a bulk mutation. What's missing is guidance on the drawings payload structure, which the nested schema leaves largely undescribed.

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 67%, and the two scalar parameters already have descriptions in the schema (target_id, expected_layout_id). The description's 'per-item identity verification' hints at validation semantics but does not explain the drawings array, its shape/points structure, or what identity is verified against.

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 (create a bounded list of drawings) and adds batch semantics that separate it from the single-item drawing_create sibling. It never names drawing_create as the alternative for single items, so the differentiation is implied rather than stated.

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

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

The description implies bulk use and per-item verification, but gives no explicit guidance on when to pick this over drawing_create or when an import should be split into smaller batches. No prerequisites (e.g., layout must be open) are stated beyond what the schema fields already carry.

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, destructive=false and openWorld=true, so the safety profile is covered. The description adds only that results carry entity IDs and 'actual shape names' (implying no name normalization), but doesn't say what scope is listed (active chart vs target_id tab) or whether results include user-drawn vs Pine-generated drawings despite the word 'native'.

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 front-loaded sentence with no filler — the key distinction (entity IDs, shape names) is right there. It is a sentence fragment, but every word 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?

With no output schema, the description usefully sketches the return payload (entity IDs, shape names). However it leaves open the scoping question an agent must resolve — whether target_id is needed to list a non-active tab — and says nothing about pagination or how many drawings come back.

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

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

Schema description coverage is 100%, so both target_id and expected_layout_id are already documented in the schema; the description adds nothing about them. Baseline 3 applies since the schema does the heavy lifting.

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

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

Specific verb ('List') plus resource ('native chart drawings') and an explicit statement of what the result contains (exact entity IDs, actual shape names). It reads clearly against siblings like drawing_get/drawing_create, though it never explicitly says how it differs from drawing_get or drawing_export.

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?

There is no explicit when-to-use statement or named alternative, but the phrase 'exact entity IDs' strongly implies this is the discovery step that feeds drawing_get/update/remove. That implication is left for the agent to infer rather than stated.

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