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

Annotations already declare readOnlyHint/idempotentHint, so safety is covered. The description adds real behavioral value beyond them: output is auto-paginated, and deleted entries are still returned with an isDeleted marker. This is exactly the kind of non-obvious behavior an agent needs when interpreting results.

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, front-loaded with the core purpose, then the audit payload and the isDeleted caveat. No filler. Slightly terse but 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 read-only paginated list with no output schema, the description covers purpose, period scoping, pagination behavior, and a notable return-field detail (isDeleted). The main omission is explicit guidance on time-zone/window edge cases already handled by the schema.

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

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

Schema description coverage is 100%, so the schema already documents from_, to, and limit (including the YCLI__HTTP__MAX_ITEMS cap). The description adds no parameter syntax or format beyond what is in the structured fields, so baseline 3 is correct.

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

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

The description states a concrete verb and resource: entries changed in a period, and adds the audit payload (what, when, by whom). It is clearly distinguishable from the sibling datalens_entries_revisions_list by its audit framing, though it never explicitly names or contrasts 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?

Usage is implied by the audit/changed-in-a-period framing but never stated: no explicit when-to-use, no exclusions, and no routing to the closest alternative (datalens_audit_entry_permissions_get or datalens_entries_revisions_list). Acceptable but leaves selection inference to the agent.

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, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating the permission levels returned (execute, read, edit, admin), but says nothing about result shape, how absent permissions are represented, or the one-user-per-call scope.

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

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

A single compact sentence with the key scope (one user, per-entry, by id) front-loaded and no wasted clauses. It is terse to the point of being slightly oblique, but nothing is extraneous.

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 two fully documented parameters and annotations covering safety, the description is adequate; it even supplies the set of permission values an agent needs to interpret the response. No output schema exists, yet the return semantics are largely conveyed.

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

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

Schema coverage is 100%, with both user_id and entry_ids fully documented in the schema. The description only echoes 'by entry id' and adds no syntax or semantic detail beyond the 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 states a specific resource and scope: the permissions ('execute, read, edit, admin') one user has on a set of entries identified by id. This is specific enough to understand the operation, but it does not differentiate from close siblings such as datalens_entries_permissions_get or datalens_permissions_get_bulk, which an agent must distinguish to pick correctly.

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 and no mention of alternatives. With near-duplicate siblings like datalens_entries_permissions_get and datalens_permissions_get_bulk present, the absence of any routing signal is a real gap.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description goes further by disclosing real behavioral traits: pivot tables are unsupported, the chart executes with its saved settings (no ad-hoc reconfiguration), and an unreachable source returns an error rather than partial 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?

Front-loaded with the return shape, then the mode of execution, limitations, and how to find a chart id — each sentence carries information. The trailing entries_list sentence is slightly tangential but functionally useful for argument discovery.

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 the return shape, and it does ('tables of columns and rows') plus the chartType discriminator describing how the output is produced. It stops short of covering result size, pagination, or row-limit behavior, which would matter for a data-returning 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%, with both chart_id and params documented in the schema itself, so the baseline of 3 applies. The description adds no syntax or format detail for params beyond the schema's 'one value or several' explanation, though it does indirectly confirm these are the chart's saved-parameter values.

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

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

States a specific resource and result: 'The data a saved chart shows, as tables of columns and rows,' which clearly distinguishes this read-data tool from the sibling chart-config getters (charts_wizard_get, charts_ql_get, charts_editor_get). It does not name those siblings explicitly, so an agent must infer that this returns rendered data rather than the chart definition.

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 supplies a routing hint for locating the required argument ('entries_list with the scope widget finds charts') and notes the chart runs with its saved settings, implying params are the only override. However, it never says when to use this over datalens_datasets_data_get or datalens_sqlqueries_run, so alternative selection is left to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety/mutation profile is covered. The description adds one useful behavioral fact – that the created chart is returned with its id – but says nothing about permissions, validation failures, or side effects on the target workbook.

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 efficient. It is arguably too terse for the complexity involved, 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?

Annotations cover the safety profile and the schema is fully self-documenting, which lowers the burden. Still, for a tool with a very large polymorphic schema and no output schema, one sentence leaves important context (which chart kinds exist, that 'entry.type' selects the variant, and where the entry must live) unstated in the prose.

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

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

Schema description coverage is 100% and the single nested 'entry' parameter is exhaustively documented, including the discriminator const values. The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Create') and resource ('a chart of the editor'), so the agent knows this is a write/create operation on an editor chart. It does not, however, distinguish itself from close siblings like datalens_charts_wizard_create or datalens_charts_ql_create, leaving the agent to infer which chart flavor 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?

There is no when-to-use guidance, no prerequisites (e.g. that a workbook or key must be supplied), and no mention of alternatives among the many sibling create tools. The agent gets no routing help at all.

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 and openWorldHint=true, so the safety profile is covered. The description goes beyond that by disclosing a cascade consequence — dashboards showing the chart lose it — which is exactly the kind of impact context annotations cannot express. It still omits whether deletion is permanent/undoable or requires elevation.

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 clause, front-loaded with the action and immediately followed by the consequence. Nothing extraneous; every token earns its place.

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

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

For a one-parameter, no-output-schema delete tool with strong annotations, the description supplies the key missing piece — downstream impact on dashboards. It is nearly complete, only lacking reversion/permission notes that would round it out.

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 chart_id is already documented, establishing the baseline of 3. The description adds no format, ID-source, or lookup detail beyond the schema.

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

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

States a specific verb and resource ('Delete a chart'), so the action is unambiguous. It does not distinguish this editor-chart delete from the sibling deleters datalens_charts_wizard_delete and datalens_charts_ql_delete, so an agent relying on the description alone cannot tell which chart type it targets beyond the name/title.

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 use this versus the wizard/ql delete siblings, nor any note about prerequisites such as ownership or permissions. Only the vague implication that deletion removes something 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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the shape of the returned object (kind + code tabs), which is real value, but says nothing about auth requirements, the branch/rev read semantics, or what happens when workbook_id is omitted.

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 tight sentence with zero waste and the core output content front-loaded. It is arguably too terse for a 7-parameter tool, but nothing in it is redundant.

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

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

With no output schema, the description carries some of the return-value burden and does gesture at the payload (kind and code tabs), but does not enumerate the optional enrichment fields the include_* flags add or the revision/branch semantics of the response. Adequate but leaves visible gaps for a 7-param 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 all seven parameters already carry precise documentation, including the saved/published branch rule and the rev_id-or-branch exclusivity. The description adds essentially no parameter-level meaning beyond “its kind”, 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?

Identifies a specific resource (one chart) and its provenance (“written in the editor”), and tells the agent the payload is the chart kind (entry.type) plus its code tabs. It implicitly separates this from the sibling wizard/QL chart getters, though it never names them explicitly.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. The agent must infer from the name that this reads editor-type charts rather than wizard or QL charts, with no explicit statement of 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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower, and the description still adds real behavior: no revision check, a save silently clobbers anything written since the last read. That concurrency hazard is exactly the kind of context annotations cannot express; the parenthetical '(measured)' is unclear noise.

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 core action front-loaded and the overwrite caveat immediately after. The trailing '(measured)' is a cryptic, unexplained token that slightly weakens an otherwise tight 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 two-parameter write tool with full schema coverage and annotations covering the safety profile, the description supplies the one missing behavioral fact an agent needs: this save is blind to revisions. It does not mention the save/publish distinction outside the schema or any return information, but neither is essential here.

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

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

Schema description coverage is 100% and the schema itself carries the mode semantics ('save keeps a draft; publish makes it the version shown') plus per-field tab descriptions. The description restates the payload as 'entryId, kind, and code', which adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Save a chart of the editor'), which is clearly distinct from the create/delete siblings in the datalens_charts_editor_* family. It does not, however, name or route against the neighboring update tools (charts_wizard_update, charts_ql_update), so differentiation relies mostly on 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?

The description implies the tool is for persisting an already-read editor chart and warns about the overwrite condition, which is useful timing context. It never states explicitly when to choose this over create or over the wizard/QL update tools, so usage remains 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, open-world, non-idempotent create. The description adds one useful behavioral note: the reply is the raw DataLens response and its shape is undocumented, warning the agent the return payload is opaque. It says nothing about permissions, side effects, or what happens on repeat calls, so it adds modest value over annotations.

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

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

The operation is front-loaded well in a single phrase. The second sentence is short but is a meta-disclaimer ('the specification describes neither...') rather than actionable information, so its value is marginal and it partly calls attention to its own incompleteness.

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 mutation tool creating nested-object content, with no output schema and no annotation coverage of the data contract. The description explicitly admits it does not describe the chart content or the reply, leaving an agent without guidance on what 'data' should contain or 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?

Schema description coverage is 100%, and parameters like template, data, and workbook_id are documented in the schema itself. The description adds no syntax, format, or default detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Create a QL chart'), which is clear enough that an agent knows the operation type. However, it never distinguishes this from the sibling creation tools (datalens_charts_wizard_create, datalens_charts_editor_create), leaving the choice between chart flavors unexplained.

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 prerequisite (e.g. workbook_id requirement), and no mention of the wizard/editor alternatives. The second sentence is a caveat about unspecified content, 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 already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds useful collateral-impact context beyond annotations: dashboards displaying the chart will lose it. It still omits permissions, reversibility, and confirmation 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 filler: it begins with the action and immediately states the side effect. Every clause earns its place.

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

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

For a simple one-parameter delete tool with no output schema, the description covers the action and one important side effect, while annotations carry the destructive safety profile and the schema documents chart_id. It is complete enough to call correctly, though it could mention required permissions or irreversibility.

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

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

There is one required parameter, chart_id, and schema description coverage is 100%, so the schema already documents it fully. The description adds no parameter-specific meaning beyond the schema, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: "Delete a chart," and adds the consequence that dashboards showing it lose the chart. This is clear and concrete, but it does not distinguish this QL-chart deletion from sibling deletion tools such as datalens_charts_editor_delete or datalens_charts_wizard_delete.

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 does not say when to delete a QL chart versus another chart type or how to recover from deletion, so the agent must infer usage entirely 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, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds a genuine structural detail that the response is flat with no `entry` wrapper, unlike wizard charts, which helps the agent interpret output, but says nothing about permissions, pagination, or error behavior.

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

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

Two short sentences, front-loaded with the resource and followed by the one differentiating fact. Every word earns its place, though the fragmentary phrasing ("comes flat") is slightly more cryptic than it needs to be.

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 partially compensates by noting the flat shape with no `entry` wrapper. However, for a 7-parameter read tool it does not describe the branch/rev_id read semantics or what the returned chart contains, leaving some gaps for an agent working without an output schema.

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

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

Schema description coverage is 100% (branch, rev_id, chart_id, workbook_id, include_* flags are all documented in the schema), so the schema carries semantics. The description adds no parameter-level meaning beyond that, which is the baseline 3 case.

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

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

The description states the resource ("One QL chart") and explicitly distinguishes it from the wizard chart variant, which is a real sibling (datalens_charts_wizard_get). The retrieval verb is only implied by the tool name rather than stated in the description, 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?

"One QL chart" implies fetching a single chart, but there is no explicit when-to-use guidance, no mention of prerequisites (chart_id, workbook_id), and no named alternative such as datalens_charts_wizard_get or datalens_charts_editor_get that would tell an agent which chart-get to pick.

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 adds real value beyond the annotations by disclosing that no revision check occurs and that a save overwrites whatever was written since the last read, i.e., a lost-update hazard. This goes meaningfully further than the idempotentHint/destructiveHint flags, and it also comments on the reply. It stops short of describing mode behavior (save vs publish), which the schema covers.

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: the action comes first and the concurrency caveat second. Phrasing like "as it came" and "(measured)" is slightly cryptic, but nothing is wasted and it is front-loaded.

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

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

For a mutation tool with full annotation coverage, a fully described schema, and no output schema, the description supplies the critical missing piece: the lack of revision checking and the resulting overwrite risk, plus a note on the reply. An agent has what it needs to call this safely.

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

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

Schema description coverage is 100%, so the parameters (entry_id, template, mode, data, annotation) are already documented in the schema. The description adds no parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ("Save") and resource ("a QL chart") that matches the name, and clarifies it writes the chart "as given". It does not explicitly differentiate itself from datalens_charts_ql_create or datalens_charts_ql_get, but the save/overwrite framing is clear enough to distinguish a write from the get/create 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?

No when-to-use guidance or named alternatives are given; the reader must infer that this is for persisting changes to an existing chart. The only contextual note is a concurrency caveat, which is behavioral rather than usage-routing information.

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 the full safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), so the bar is lowered. The description adds genuinely useful non-annotation context — that the created entry is returned with its id — but says nothing about required permissions, side effects on the workbook, or what happens on repeated calls.

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, front-loaded with the core action and return value, with no filler. The second sentence is somewhat fragmentary in phrasing ('is a valid ``data``') but earns its place by encoding the interop 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 correctly compensates by stating the return value (the chart with its id). It also addresses the nested `data` object by pointing to schema_get(service="datalens", name="WizardChartData") rather than leaving it opaque. The remaining gap is the absence of workflow/alternative guidance in a crowded field of chart-create siblings.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents key, name, annotation, and workbook_id. The description adds one piece of meaning beyond the schema for the `data` parameter: that it is interchangeable with `entry.data` from charts_wizard_get, which is a helpful compatibility cue but not a syntactic or structural clarification.

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 chart of the wizard in a workbook') and even notes the return payload (the id), so an agent knows exactly what it produces. However, it does not differentiate itself from the sibling creation tools (datalens_charts_ql_create, datalens_charts_editor_create), leaving the agent to infer that 'wizard' is the distinguishing axis.

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 or when-not guidance, nor a named alternative among the wizard/ql/editor create siblings. The only usage signal is the implied round-trip workflow: data fetched via charts_wizard_get is valid input, which hints at a get-then-create pattern but stops short of stating it as 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 destructiveHint=true and idempotentHint=false, but the description adds real value beyond them: dashboards displaying the chart lose it, the dashboards continue to reference the deleted id, and deletion cannot be undone through the API. This is meaningful consequence disclosure. It stops short of stating permission requirements or failure behavior.

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

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

Two short sentences, and the destructive effect is front-loaded. But the second sentence is garbled ('a dashboard that shows it keeps naming its id (measured)') and the parenthetical '(measured)' reads like an internal spec artifact rather than agent-usable guidance, hurting clarity.

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

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

For a one-parameter delete with annotations covering the safety profile and no output schema, the description covers consequences adequately. It nevertheless omits permissions/auth requirements and any note on error conditions (e.g., deleting a chart still referenced by a dashboard), leaving gaps an agent may hit at call time.

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% for the single chart_id parameter, so the schema already carries parameter meaning. The description adds nothing about the id format, source, or validity, so the baseline 3 applies.

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

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

The description states a specific verb (Delete) and resource (a chart) and clarifies the effect on dashboards. However, it never distinguishes this wizard-chart delete from the closely named siblings datalens_charts_ql_delete and datalens_charts_editor_delete, which an agent could easily confuse it with.

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 describes the consequence of deletion but gives no guidance on when to choose this tool over the ql/editor chart-delete variants, nor any prerequisite such as detaching the chart from dashboards first. The irreversibility statement is useful but is a warning, not usage 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, openWorldHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuine non-annotation behavior: ``isFavorite`` and ``permissions`` are returned only when explicitly requested, and ``entry.data`` is the round-trippable payload for update. It does not note error/empty-revision behavior, keeping it below 5.

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

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

Three short, front-loaded sentences with no filler; the return shape leads and the sibling references follow. The backtick-heavy telegraphic style is dense but 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?

With no output schema, the description does the work of explaining what comes back (datasets read, what the chart shows, entry.data, and conditionally favorite/permissions). That covers the key retrieval contract for a 7-param get tool; only revision/branch read semantics and error cases are left to the schema.

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

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

Schema description coverage is 100%, so the schema already documents branch, rev_id, include_links, include_favorite and include_permissions. The description's mention that favorite/permissions 'come only when asked for' largely restates the schema's 'Also say whether...' wording rather than adding new semantics, 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 conveys a specific resource and scope: 'One chart built in the wizard: the datasets it reads and what it shows.' It distinguishes the wizard chart from the editor/QL siblings implicitly via the 'built in the wizard' framing, but the read verb itself is only carried by the title, not the description text.

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 concrete routing context: '``entry.data`` is what ``charts_wizard_update`` takes back' implies read-before-update, and '``entries_list`` with the scope ``widget`` finds charts' names the alternative for discovery. No explicit when-not or exclusion, so it stops short of a 5.

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

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

It adds key behavioral context beyond the annotations: DataLens does not check the revision, and saving overwrites anything written since the chart was read. This is important for avoiding lost concurrent edits. There is mild tension with destructiveHint=false, but the warning concerns overwrite risk rather than direct resource deletion, so it is not a clear contradiction.

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 essential workflow and followed by a critical overwrite warning. There is no wasted text.

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

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

For a mutation tool with rich schema descriptions, no output schema, and annotations covering idempotency and destructiveness, the description supplies the critical operational warning about overwrites. It could still say more about when to choose this tool over sibling chart-update tools, but it is largely 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 parameter meanings are already well documented. The description reinforces whole-object replacement and ignored revision checking, but adds little parameter-specific detail beyond what the schema provides.

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

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

The description states a specific verb and resource: saving/updating a wizard chart, with the full read-change-send workflow. It clearly distinguishes the wizard chart subtype, though it does not explicitly contrast with sibling update tools for editor or QL charts.

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

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

The description implies the update workflow: read the chart, change it, send it back whole. However, it gives no explicit when-to-use guidance versus alternatives such as datalens_charts_wizard_create, datalens_charts_editor_update, or datalens_charts_ql_update.

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 cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds non-obvious context beyond them: the call may incur billing requiring user confirmation, and the API is experimental/untested ('never called: not measured'). That is real disclosure, though it lacks detail on auth or the operation object's behavior.

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

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

Front-loads the purpose in the first sentence, then appends billing and experimental caveats. Three short sentences with little waste, though 'the operation that makes it' is slightly awkward phrasing.

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

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

For a 6-parameter create tool with no output schema, the description covers purpose, the billing prerequisite, and experimental status. Return value is only hinted at ('return the operation') but output schema is absent and the schema documents inputs fully, so it is largely 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 the schema already documents all six parameters including required ones and nested storage settings. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Make a cloud environment') plus the return artifact ('return the operation that makes it'). It is clearly a creation tool distinguishable from the sibling list/get/update/delete operations, though it does not explicitly name 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?

Provides one prerequisite-style guideline ('ask the person before calling') driven by potential billing, which is genuinely useful. However, it offers no explicit when-to-use-vs-alternatives routing against the sibling create/update operations, leaving usage largely 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 destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds a useful experimental/never-called caveat but does not explain what gets destroyed, whether deletion is reversible, or required permissions—leaving key behavioral context to 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 sentences, front-loaded with the core purpose, followed by a relevant experimental caveat. 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 destructive delete operation whose safety profile is covered by annotations, the description is minimally adequate but lacks any prerequisites, consequences, or usage context that would help an agent invoke it correctly.

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

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

Schema description coverage is 100% for the single 'id' parameter. The description adds no additional meaning or syntax beyond what the schema already provides, so the baseline of 3 applies.

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

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

States the specific verb 'Delete' and resource 'cloud environment', clearly distinguishing it from siblings like datalens_cloudenvironments_list/get/create/update. It also clarifies the return type as an 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?

Provides no guidance on when to use this tool versus alternatives, nor any prerequisites or warnings. The experimental note is a caveat about reliability, 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 cover the safety profile (readOnly, idempotent, openWorld), yet the description adds two genuinely useful behavioral facts: the endpoint is experimental/'not measured', and an unknown id yields 403 Permission denied rather than 404. The latter is a non-obvious error-semantics disclosure that an agent would otherwise misdiagnose as a rights problem.

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, front-loaded with the resource and returned fields, with the caveat and error-semantics note trailing. Slightly compressed phrasing, but every clause carries information and nothing is padded.

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

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

With no output schema, the description must characterize the return, and it does so by naming the four fields returned. Combined with the experimental-status caveat and the 403-vs-404 behavior, an agent has enough to call it correctly, though it says nothing about attribution or pagination (not applicable here).

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

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

Schema coverage is 100% with only two parameters, both documented in the schema, so the schema carries the burden. The description's field list ('cloud, subnet, status, storage') describes return content rather than parameter meaning, adding little beyond the schema — baseline 3 is appropriate.

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

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

States a specific resource ('one cloud environment') and enumerates what it returns (cloud, subnet, status, storage), which distinguishes it from the list/create/update/delete siblings on the same resource. It does not explicitly name a sibling alternative, but the singular scope makes the get-vs-list distinction obvious.

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 explicit when-to-use or when-not-to-use guidance, and no alternatives are named (e.g. datalens_cloudenvironments_list for many, or the update/delete tools). Usage is only inferable from the name and the 'one cloud environment' framing.

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, idempotentHint and openWorldHint, so safety is covered; the description adds real value by disclosing automatic pagination (no cursor management needed), experimental API status (a stability caveat), and the empty-list behavior for instances with no environments. It stops short of saying whether filters silently narrow results or how the response is shaped.

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 with the resource front-loaded and no padding. The phrasing of the final sentence is slightly awkward ('An instance with none answers an empty list'), 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?

With no output schema and full schema coverage on all parameters, the description covers the essential behavioral facts: auto-pagination, experimental status, and the empty-result case. It leaves the exact pagination mechanics and filter behavior to the schema, which is acceptable for this simple 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% with three well-documented optional parameters (limit, filter, include_permissions), so the schema carries the semantics and a baseline 3 applies. The description contributes nothing about limit, filter syntax, or what include_permissions returns, so it adds no meaning beyond the schema.

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

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

The description names the resource precisely (cloud environments of the DataLens instance) and the auto-pagination note confirms it returns a collection rather than a single item, distinguishing it implicitly from datalens_cloudenvironments_get/create/update/delete. It never states an explicit verb like 'list all', so the differentiation from siblings is inferred rather than declared.

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 and no alternatives named; an agent is not told to use this tool to enumerate environments and reach for datalens_cloudenvironments_get when a single environment is wanted. The only usage-adjacent information is the empty-list edge case.

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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely useful context beyond them: the link is a bearer credential ("works for whoever holds it"), it expires ("for a time"), it is returned in the result, and the endpoint is experimental and untested ("not measured"). It stops short of stating auth/permission requirements.

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

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

Three short sentences, front-loaded with the nature of the artifact before the handling caveat and the experimental disclaimer. Slightly meandering ("and it comes in this tool's result") but every sentence 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?

With no output schema, the description usefully states that the link arrives in the result and that it is time-limited and sensitive. It is nearly complete for a URL-minting tool, though it omits what permissions are needed and the exact response shape.

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% for both parameters, so the schema already documents path and cloud_environment_id. The description adds no format or constraint detail beyond that, which is the expected baseline 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 names the resource and scope precisely ("a signed link to read one object of the bucket"), and the title supplies the verb "Create". It implicitly contrasts with the sibling upload_url_create (read vs upload) but never names it, so sibling differentiation is inferred rather than stated.

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

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

"Hand it to the person and do not repeat it" is guidance on handling the result, not on when to choose this tool. Nothing says when to prefer it over bucket_object_metadata_get or bucket_upload_url_create, and no prerequisites (permissions, bucket state) are given.

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, idempotent, and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the API endpoint is experimental and unmeasured, and an unknown environment returns 403 Permission denied rather than 404, which materially affects error handling.

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

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

Two sentences, front-loaded with the returned data, then a caveat sentence. It is compact and each sentence adds information, though the phrasing ('An environment nothing knows') is slightly awkward.

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 carry the return contract; it does so by naming size and last-modified time. Combined with the error-code note, an agent has enough to call and interpret the tool, though a fuller enumeration of metadata fields would be ideal.

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

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

Schema coverage is 100% with two well-described parameters (path and cloud_environment_id), so the schema does the work. The description adds no additional parameter meaning, which is the expected baseline at full coverage.

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

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

The description names the resource and what it returns ('size of an object, in bytes as a string, and when it last changed'), which together with the title makes the purpose legible. It does not explicitly differentiate from the sibling bucket_objects_list or the download/upload URL tools, so it lands at 4 rather than 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 statement of when to use this tool versus the sibling bucket_objects_list, bucket_download_url_create, or bucket_upload_url_create. The only operational note is an error-code behavior, which 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 already cover readOnly/openWorld/idempotent, but the description adds real value beyond them: auto-pagination behavior, the experimental/unmeasured status of the endpoint, and the notable 403-vs-404 semantics where an unknown environment returns Permission denied rather than not-found. That last point is a genuine behavioral caveat an agent could not infer from structured fields.

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, purpose front-loaded, no filler. The phrasing 'written from its document: not measured' is slightly opaque but is compact and informative rather than 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?

With no output schema, the description usefully tells the agent what comes back (object paths) and that results are auto-paginated, plus the 403 caveat for unknown environments. For a low-complexity list tool this is close to complete; only explicit pagination semantics would improve 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?

Schema description coverage is 100% and all three parameters (limit, prefix, cloud_environment_id) are documented inline, so the schema carries the burden. The description adds no parameter-level detail such as prefix-matching semantics or limit defaults, so the baseline 3 applies.

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

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

The description states a specific verb and resource: it returns the paths of objects in a cloud environment's storage bucket. That is distinguishable from the sibling metadata_get, which targets a single object, though the description never names that sibling to reinforce the distinction.

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

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

It notes the tool is auto-paginated but gives no explicit when-to-use guidance, no prerequisites for calling it, and no routing to or away from the related bucket tools (object_metadata_get, download_url_create, upload_url_create). Usage is only implied by the verb 'list'.

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 state readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. Beyond that, the description discloses important security behavior: the link is bearer-like ('works for whoever holds it'), time-limited ('for a time'), returned in the result, and should not be repeated. It also candidly notes the operation is experimental and not measured, which is valuable context.

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

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

The description is two short sentences plus a brief caveat, and it front-loads the core purpose before operational guidance. There is little filler, though the phrasing is slightly indirect and could state the action more directly. Overall it is appropriately sized for a simple four-parameter tool.

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

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

For a four-parameter tool with full schema coverage and no output schema, the description covers the returned artifact and its handling, which is the most important missing piece. It does not mention required permissions or whether an existing object would be overwritten, but the annotations supply safety hints and the core contract is clear.

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

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

Schema description coverage is 100%, so the schema already documents all four required parameters. The description adds no parameter-specific meaning, syntax, or constraints beyond what the schema provides. Baseline 3 is appropriate when the schema fully carries parameter semantics.

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

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

The title and description together convey the purpose: creating a signed upload link for a bucket object. The description says 'A signed link to put one object into the bucket,' which is clear but phrased as a noun rather than an action verb. It also does not explicitly distinguish this from the sibling download URL tool, though the 'put' wording implies upload.

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 handling instructions for the produced link ('hand it to the person and do not repeat it'), which is useful operational guidance. However, it provides no guidance on when to choose this tool versus alternatives such as datalens_cloudenvironmentstorage_bucket_download_url_create or bucket_objects_list. There are no explicit when/when-not conditions.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that the call returns an operation (valuable since there is no output schema) and flags the experimental, untested status, but says nothing about which fields are optional, how omitted fields are treated, or storage-related failure behavior.

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

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

Two short sentences with the action front-loaded and no padding. The second sentence is meta-commentary about API maturity rather than tool behavior, which is slightly off-purpose but does not bloat the definition.

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 annotations carrying the safety profile, no output schema, and full schema coverage, the description covers the essentials and notes the returned operation. It is adequate but thin for a mutation tool: no prerequisites, no statement that unspecified fields are left unchanged, and no note on the storage-fails-if-no-bucket constraint that the schema hints at.

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

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

Schema description coverage is 100%, so all five parameters (id, name, storage, description, security_group_ids) are documented inline. The description adds no parameter-level detail beyond the generic phrase 'the fields given', so the baseline of 3 applies.

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

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

States a specific verb and resource ('Change the fields given of a cloud environment') and implies partial-update semantics, distinguishing it from the create/get/list/delete siblings in the cloud environments family. It does not explicitly name those siblings, but the action 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?

There is no when-to-use guidance and no comparison to alternatives such as datalens_cloudenvironments_create or _delete. The only guidance-like content is the experimental warning, which advises caution but does not help the agent choose this tool over another.

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 idempotentHint=true, so the safety profile is covered. The description adds only one behavioral detail beyond that: that results are 'auto-paginated'. It does not explain pagination mechanics or interaction with the limit parameter.

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 clause with no wasted words, front-loading the core question and appending the pagination behavior. It is efficient, though arguably terse for the tool's role.

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 list operation, the description combined with annotations and a fully documented schema gives the agent enough to call it correctly. The lack of a return-shape description is mitigated by the straightforward nature of the tool, though no output schema exists.

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

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

Schema description coverage is 100%, so all three parameters are documented in the schema. The description adds no parameter-level meaning beyond what the schema already provides, making the baseline 3 appropriate for high-coverage schemas.

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 clear resource and outcome: querying role assignments on a collection. It distinguishes from sibling datalens_collections_access_bindings_update by implication of listing, but never explicitly names alternatives or scopes like collection vs. workbook vs. shared entry.

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

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

No when-to-use guidance is provided. It does not state prerequisites, when to prefer this over sibling list tools such as datalens_workbooks_access_bindings_list, or any exclusion conditions.

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=false, destructive=false, openWorld=true and idempotent=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: this is a partial/delta update where unnamed roles are left untouched, which is important context an agent cannot derive from the schema or hints. It omits permission requirements and error behavior, keeping it below 5.

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

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

A single compact sentence with the partial-update constraint front-loaded and no filler. Every clause earns its place.

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

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

For a two-parameter mutation with annotations covering safety and no output schema to explain, the description supplies the one behavior that matters most (incremental role changes). Missing only permission requirements and failure semantics, which is a minor 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 the schema already documents collection_id, deltas, action, roleId and subject. The description's phrase 'roles not named stay as they are' echoes the schema's ADD/REMOVE delta semantics without adding syntax or format detail. Baseline 3 applies 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 pair and resource: 'Give or take away roles on a collection.' That is enough to distinguish it from the workbooks/sharedentries variants of the same operation, which target different resources. It stops short of naming the sibling tool explicitly, so it lands at 4 rather than 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 statement of when to use this tool versus alternatives such as datalens_collections_access_bindings_list (to inspect current roles) or the workbooks/sharedentries binding updaters. The agent must infer the use case from the verb alone. No prerequisites or exclusions are given.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds only a hint about response content (ancestor chain from root), and says nothing about ordering guarantees, whether the target collection itself is included, or permission 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 short fragment with no padding, so it is certainly concise and front-loaded. However, it reads as an incomplete sentence and omits the verb, leaving the statement of purpose under-formed rather than 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?

There is no output schema, so the description is the only place return values could be characterized; it gestures at the result being an ancestor chain but does not describe the shape, fields, or ordering. For a simple 2-parameter read it is minimally adequate, 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% and both parameters (collection_id, include_permissions_info) are documented in the schema, so the baseline is 3. The description adds no meaning beyond the schema for either 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 sentence names the resource (collections) and the scope of the result (root down to this one), so an agent can infer it returns an ancestry path. But it states the output content rather than an action verb, and it never distinguishes itself from close siblings such as datalens_collections_get or datalens_collections_list_by_ids.

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 stated preconditions, and no mention of any alternative tool. With ~200 siblings and several collection-listing tools, the absence of routing guidance is a real gap.

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

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

Annotations already declare readOnly, idempotent, and openWorld. The description adds behavior beyond them: results are auto-paginated, and output is capped at the configured item cap unless `limit` is passed. That cap/pagination disclosure is genuinely useful context the agent can't get from the annotations alone.

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 resource meaning and then the navigation hint. Zero filler; the cap caveat is stated precisely.

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

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

For a read-only list tool with full schema coverage and safety annotations, the description covers purpose, navigation, and pagination/cap behavior. Return structure is only loosely sketched (no output schema exists), but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters including `mode`, `limit`, and `collection_id`. The description only reinforces the `limit`/cap interaction already documented in the schema, so baseline 3 is appropriate.

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

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

States a specific verb+resource: it lists what a collection holds (collections, workbooks, entries). This clearly distinguishes it from the flat datalens_workbooks_list and datalens_entries_list siblings, 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?

Provides clear context and a workflow: 'Start here to find a workbook: list the root, then descend.' That tells the agent when to reach for this tool versus a direct by-ids or workbooks-list call. It stops short of explicit exclusions or naming the competing siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond them: it does not mention that repeat calls create duplicate collections (non-idempotent), what permissions are needed, or naming constraints.

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 placement rule front-loaded and no filler. Slightly awkward phrasing ('in another one') but structurally efficient.

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

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

For a mutation tool with no output schema, the description omits what the agent gets back (e.g., the new collection id needed for follow-up calls) and any permission or naming constraints. The schema carries the parameter detail, but the description leaves the agent under-informed on the result of the operation.

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

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

Schema description coverage is 100% and each parameter is documented, including parent_id's root default. The description merely restates the parent_id fallback behavior already present in the schema, adding no new 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?

Names a specific verb and resource ('Create a collection') and adds the placement rule (parent vs root). An agent can distinguish it from siblings like datalens_collections_move or datalens_collections_update, 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 other creation or move tools (e.g., datalens_workbooks_create, datalens_collections_move), nor prerequisites such as required permissions on the parent collection. The only conditional stated is the parent/root default, which is really parameter semantics rather than 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 already flag destructiveHint=true, but the description adds real value by disclosing the recursive blast radius: nested collections, workbooks and entries are all removed. It stops short of stating irreversibility, required permissions, or whether locked entries block deletion.

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 action and immediately followed by the destructive scope. No filler.

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

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

For a destructive single-parameter tool with full annotation coverage and no output schema, the description supplies the key missing behavioral fact (cascade). It omits permissions and irreversibility, but nothing essential to correct invocation is absent.

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

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

Schema description coverage is 100% and the description adds no syntax or format detail for collection_id beyond what the schema states. Baseline 3 applies for a single fully-documented 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?

States a specific verb (delete) and resource (collection) and adds the cascade scope ('everything it holds: nested collections, workbooks, entries'). It does not name or contrast with the close sibling datalens_collections_delete_bulk, so an agent must infer the distinction.

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

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

No when-to-use guidance, no exclusions, and no reference to alternatives such as datalens_collections_delete_bulk for multi-collection deletion or datalens_workbooks_delete for removing a workbook alone. Usage is only implied by 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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered structurally. The description adds real value by disclosing the cascade semantics ('with everything they hold'), which the annotations do not convey. It stops short of stating irreversibility or partial-failure 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?

A single sentence, front-loaded with the verb and the cascade warning, with no wasted words. It is efficient for a one-parameter tool, though extremely terse.

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 one-parameter bulk delete with no output schema and annotations that already carry the destructive/idempotency profile, the description plus structured fields are sufficient to invoke it. The cascade note is the key missing-from-schema detail and it is present.

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

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

Schema description coverage is 100% for the single parameter, so the schema already documents collection_ids as an array of ids. The description adds nothing beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('Delete ... collections') with a clear scope worth ('several') and effect ('with everything they hold'). The 'several/bulk' framing implicitly separates it from the singular datalens_collections_delete sibling, 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?

The description gives no when-to-use guidance, no condition that selects bulk deletion over single deletion, and no prerequisites such as required permissions or confirmation. It only restates the action.

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, idempotentHint, and openWorldHint, covering the safety profile. The description adds that the response includes title, description, and parent, which is useful return context not present in annotations, but it does not disclose behavior around the optional permissions flag or any other operational trait.

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 very short and front-loads the key constraint 'by id'. However, it is a sentence fragment without a verb, and it omits useful context such as the optional parameters. It is concise but too terse to be well-structured.

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-by-id tool, the schema covers inputs and annotations cover safety, so the description need not explain everything. It partially describes the return fields, but with no output schema the description could say more about what is returned, especially when include_permissions_info is set.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description implies the collection_id lookup but adds no format or syntax details beyond the schema, and it does not mention the include_permissions_info parameter. Baseline 3 is appropriate when the schema carries the parameter semantics.

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

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

The description states a specific resource and scope: retrieving one collection by id, with its title, description, and parent. This implicitly distinguishes it from list-style siblings like datalens_collections_list_by_ids. It lacks an explicit verb and does not name sibling tools, 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 guidance on when to use this tool versus alternatives such as datalens_collections_list_by_ids or datalens_collections_breadcrumbs_list. The phrase 'One collection by id' implies a lookup use case, but no when/when-not or alternative routing is provided.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds a useful behavioral detail: ids the caller cannot see are silently omitted rather than causing an error. However, it does not describe return format, ordering, or handling of duplicate ids, so it adds only moderate value beyond annotations.

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

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

The description is a single, tightly worded sentence that front-loads the core operation and appends the key edge-case behavior. Every clause earns its place, with no redundancy or filler.

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

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

For a simple read-only batch lookup with rich annotations and a fully described single parameter, the description covers the essential purpose and the permission-filtering behavior. It does not explain return ordering or pagination, but with no output schema and a low-complexity surface, those omissions 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 description coverage is 100% — the single parameter is fully documented as 'Collection ids.' The description references 'these ids' but adds no format, constraint, or example beyond what the schema already provides. With full schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states that the tool returns the collections matching the given ids, and adds the key behavior that inaccessible ids are omitted. It distinguishes itself from simple single-collection getters by implying batch lookup, but it does not explicitly contrast with siblings like datalens_collections_get or datalens_workbooks_list_by_ids.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as datalens_collections_get or datalens_collections_content_list, nor does it state any prerequisites or selection criteria. The only contextual clue is the input parameter name itself.

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

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

Annotations already declare readOnly=false, destructive=false, and idempotent=false, so the safety profile is covered. The description adds no new behavioral context beyond the schema — it does not mention permission/access-binding effects, required roles, or what happens to existing entry locks when a collection is relocated.

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 zero filler; the core action and the default-destination rule are stated 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?

With annotations present and no output schema, the essentials for calling the tool are covered. However, for a mutation that relocates a container, the description omits any note about permission inheritance or side effects, which an agent would want before invoking 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?

Schema description coverage is 100%, so the schema already documents collection_id, parent_id, and title. The description's root-when-omitted note merely restates the parent_id schema description, adding no syntax or format detail.

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

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

The description states a specific verb and resource ('Move a collection') plus the destination scope, which is clear enough to distinguish it from read/update siblings like datalens_collections_get or datalens_collections_update. It does not, however, differentiate itself from the near-neighbor datalens_collections_move_bulk or datalens_workbooks_move.

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 conditional given is about parent_id behavior ('into the root when no parent is given'), which is parameter behavior rather than tool-selection guidance. There is no statement of when to use this versus move_bulk or any other move/rename tool.

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

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

Annotations cover the safety profile (non-readonly, non-destructive, non-idempotent, open world), and the description adds genuinely non-obvious behavior: atomic all-or-nothing semantics and a 409 when any collection already sits in the destination. That conflict/atomicity disclosure is real value the annotations cannot convey.

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; the core action is front-loaded and the atomicity caveat is a tightly packed second clause. 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 2-parameter mutation with no output schema, the description supplies the two things an agent most needs: destination default and failure semantics. It lacks any note on permissions or limits on batch size, but nothing critical is missing 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 description coverage is 100% and both parameters are documented there, including the root default for parent_id. The description only restates that default ("into the root when none is given"), adding no syntax, id format, or batch-limit detail beyond the schema.

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

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

States a specific verb and resource (move collections, plural/bulk) and the destination semantics (another collection or the root). It implicitly separates itself from the single-item sibling datalens_collections_move, but never names it, so an agent must infer the distinction from 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?

The description implies the bulk use case ("several collections") but gives no explicit when-to-use versus when-to-use-the-single-move rule, nor any prerequisite/permission guidance. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds that the check concerns creating a collection and a workbook in the root, but it does not disclose the return format (e.g., boolean vs. object) or any auth requirements, leaving a 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?

The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple permission check, though it could add a short clause about the return value without harming 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?

For a zero-parameter, read-only tool, the description states the permission being checked but omits what the response contains. With no output schema, this is a noticeable gap for an agent that needs to know whether the result is a simple boolean or a structured permission object.

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

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

The tool has zero parameters, so the schema cannot convey parameter meaning. The baseline for no parameters is 4; the description correctly adds no parameter detail because none exist.

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 specifies a permission check at the root for creating a collection and a workbook, which distinguishes it from generic permission getters. However, it is phrased as a question rather than a verb+resource statement and does not name or differentiate from sibling tools like datalens_entries_permissions_get.

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 explicit when-to-use, prerequisites, or alternatives are provided. The agent could infer it is a pre-flight check before collection or workbook creation, but the description offers no guidance on when to call this tool versus other permission-related siblings.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context with the partial-update semantics (omitted fields are preserved), but says nothing about required permissions or failure modes for a non-existent collection.

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 mutation front-loaded ('Change a collection's title or description') and the semantics clause appended. No wasted words, though it is terse enough that nothing extra is offered.

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 three-parameter update with full schema coverage and annotations carrying idempotency and safety, the description is adequate but thin: it omits permission requirements and any note on what identifies an invalid collection_id. No output schema exists, so return behavior need not be 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 100%, so the schema already documents title, description and collection_id. The description adds the partial-update meaning for the optional fields but no extra syntax, format or constraint detail beyond the schema.

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

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

The description names a specific verb (change) and resource (a collection) and lists the two mutable fields, title and description. It is clearly distinct from siblings like datalens_collections_move or datalens_collections_delete, though it does not explicitly contrast itself with any of them.

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

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

The phrase 'what is not given stays as it is' effectively tells the agent this is a partial update, which is useful usage context. However, there is no explicit when-to-use guidance, no prerequisites (e.g. ownership/permissions), and no named alternative for a full replacement.

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, non-destructive, non-idempotent, open-world write, so the safety baseline is covered. The description adds real value beyond that: credentials are stored server-side and never returned by ``connections_get``, and one connection type is rejected by the API. It omits, however, any warning that repeating the call yields duplicate connections despite idempotentHint=false, and gives no permission requirements.

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

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

Three short sentences, front-loaded with the action and return value, then placement, then the security note and the exclusion. The final sentence is a little long, but each sentence carries distinct information with no filler.

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

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

For a one-parameter create tool with an externally referenced nested schema and no output schema, the description covers the essentials: return value, placement scope, credential handling, and a known unsupported case. Missing only secondary detail such as required permissions or duplicate-creation 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 coverage is 100% for the single top-level ``connection`` object, so baseline is 3. The description goes further by explaining that ``workbook_id``/``dir_path`` sit inside that payload and that the actual type-specific schema is external and must be fetched with ``schema_get`` for ``ConnectionCreate``, which is meaningful guidance for a nested-unknown object.

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

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

The first sentence states a specific verb and resource ('Create a connection') plus the return value ('return its id'), which no sibling duplicates. The description also implicitly separates it from read/update paths by naming ``connections_get`` as the reader. An agent can identify this as the creation primitive without opening the schema.

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

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

It tells the agent where the resource must live (``workbook_id`` or ``dir_path``) and gives an explicit exclusion plus workaround: gsheets connections cannot be created here and must be made in the UI. It does not name a fallback tool or state prerequisites beyond that, so it stops short of full when/when-not/alternatives coverage.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety baseline is covered. The description nonetheless adds real value beyond them: it specifies what gets damaged (datasets lose their source), that the action is unrecoverable ('no way to bring it back'), and a referential side effect (charts keep naming the deleted id). The trailing '(measured)' is an unexplained artifact that slightly muddies otherwise strong disclosure.

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

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

Two tight sentences with the action front-loaded and the consequence trailing. The stray '(measured)' parenthetical is wasted tokens and the only blemish on otherwise efficient structuring.

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

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

For a single-parameter destructive delete with no output schema, the description plus annotations cover the essentials: what the tool removes and that it cannot be undone. It is nearly complete, missing only explicit permission/authorization requirements.

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

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

Schema coverage is 100% with a single documented 'connection_id' parameter, so the schema carries the full burden. The description only obliquely references the id ('keeps naming its id') and adds no format or constraint detail. Baseline 3 is appropriate.

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

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

The description gives a specific verb+resource ('Delete a connection') and immediately qualifies it with the consequence ('the datasets built on it lose their source'). This cleanly distinguishes it from the sibling get/create/update connection tools without ambiguity.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. The irreversibility note implies caution, but it never tells the agent under what conditions deletion is the right choice versus, say, datalens_connections_update or detaching datasets 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, idempotentHint, and openWorldHint. The description adds non-obvious behavior: the response uses db_type instead of type, and passwords/tokens are never returned, which is important for security expectations.

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

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

Three short paragraphs: purpose first, then the db_type nuance, then security and an alternative. No filler; every sentence carries actionable 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?

No output schema exists, so the description must cover return values; it names the main returned fields and the db_type field, plus a secrets warning. It does not detail settings structure or error behavior, but for a read-only get with full input schema coverage this is close to 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 all four parameters are documented in the schema. The description adds no syntax or filtering details beyond noting lookup by id, so it does not exceed the baseline of 3.

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

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

States it retrieves a single connection by id and enumerates the high-level returned fields (name, kind, settings of that kind). The note contrasting db_type with create's type and the reference to workbooks_entries_list distinguishes it from sibling create/list 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?

Names the alternative datalens_workbooks_entries_list for finding a workbook's connections, implying this tool is for when the connection id is known. However, it does not explicitly state when not to use it or list other prerequisites, so guidance is clear but not exhaustive.

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

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

Annotations already declare the safety profile (not read-only, idempotent, non-destructive, open-world). The description adds one genuinely useful behavioral fact beyond them: only the supplied fields change while the rest stay as-is, and the call returns an acknowledgement. It says nothing about permissions, what happens on invalid field values, or concurrency, so it adds some but not rich context.

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

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

A single compact sentence that front-loads the action and the mutation semantics with no wasted words. It is arguably too terse for the underlying nested-schema complexity, but the sentence itself is efficient.

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 minimum: what changes, partial-update behavior, and the acknowledgement return. However, for a mutation tool with a nested, externally-defined data object and no output schema, it does not tell the agent that the ConnectionUpdate schema must be resolved via schema_get, nor what the acknowledgement contains.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'fields given' phrasing aligns with the schema's partial-update note, but adds no new syntax or format detail beyond what the schema already documents, including the pointer to schema_get for ConnectionUpdate.

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

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

States a specific verb+resource combination ('Change the fields ... of a connection') and correctly implies a partial update. It is distinguishable from siblings like datalens_connections_create/delete/get by resource, but it does not explicitly differentiate itself from 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?

There is no guidance on when to use this tool versus datalens_connections_create or the schema_get lookup the nested data parameter requires, nor any prerequisites or exclusions. The agent must infer usage entirely from 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 cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description goes beyond them by documenting the return ('with its id') and a concrete failure mode — the 400 error when entry.meta is omitted — which is genuinely useful behavioral context for a create call.

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

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

Front-loads the purpose in one sentence, then adds the field requirements and error detail without padding. Every sentence carries information, though the backtick-heavy inline markup is slightly noisy.

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, mentioning that the created dashboard with its id is returned is necessary and present, and the nested-type gap is partly compensated by the data/meta field notes. Permissions and post-creation behavior are not covered, keeping it from a 5.

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%, but the sole parameter's real shape is an external type (DashboardCreate) not listed inline, so the description's detail that data needs counter, salt, settings and tabs, that a tab may be empty, and that entry.meta must be an object adds real meaning beyond the schema.

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

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

States a specific verb and resource ('Create a dashboard') plus a return detail ('and return it with its id'), so it is clearly distinguished from the get/update/delete dashboard siblings by the verb alone. It stops short of naming an alternative tool, so it lands at 4 rather than 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 explicit when-to-use/when-not guidance and no mention of prerequisites like required permissions or the relationship to datalens_workbooks_create. A careful agent can infer it creates a new dashboard, but the description offers no routing context.

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