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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful 'no revoke' limitation, but says nothing about what happens to pre-existing assignments, whether repeated calls duplicate grants (relevant given idempotentHint=false), or 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?

A single front-loaded clause with no filler; the negative constraint is placed immediately after the core action. The terseness is appropriate in form, though it masks an under-specification problem rather than a verbosity one.

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

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

For a non-idempotent admin mutation whose only parameter is an opaque nested array and whose schema coverage is 0%, the description leaves critical gaps: assignment object shape, merge-vs-replace behavior, and any return/outcome information (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 0% and the single required parameter is an array of untyped objects — the agent has no way to know the shape of a license assignment. The description supplies nothing about the assignments structure or allowed keys, so it fails to compensate for the coverage gap.

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

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

States a clear verb ('Apply') and resource ('license assignments'), so an agent knows this writes license assignments. However, the qualifier 'explicit documented' is jargon that adds no discriminating meaning, and no sibling tool is named as a contrast — though none of the listed siblings appear to overlap.

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 genuine boundary condition: 'this operation does not support revoke', which tells the agent when this tool is NOT the right one. It stops short of naming an alternative for revocation or stating prerequisites/context for when assignment is appropriate.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds one genuine behavioral fact beyond annotations — that license revocation is unsupported — which is useful, but it stops well short of describing output or environment reach.

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 read action front-loaded. It is efficient, though the trailing 'report that license revoke is unsupported' clause is a bit of a non-sequitur alongside the inventory read.

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

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

With no output schema and no parameters, the description carries the full burden of communicating what comes back, yet it only says 'inventory and limits' without indicating structure or scope. Adequate to call the tool, but thin for an admin-facing read.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing the description could add, and it does not mislead about inputs.

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

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

The description uses a specific verb+resource ('Read ... license inventory and limits') and explicitly carves out the revoke case, which separates it from the sibling dl_admin_assign_licenses. The word 'documented' is slightly obscure, but overall an agent can tell what the tool returns.

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

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

It implies usage (read license inventory/limits) and rules out revocation by stating revoke is unsupported. However, it never explicitly says when to reach for this versus dl_admin_assign_licenses or dl_server_info, so guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real context beyond that: it is a single probe ('one'), it is harmless, and the returned status is secret-free — a meaningful disclosure about output hygiene that annotations cannot express.

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 that names the action, its scope, its safety, and the nature of the return value, with no filler.

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

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

With no output schema, the description does carry some burden for return semantics, and 'secret-free status' tells the agent a status is returned without leaking credentials. It stops short of describing possible status values or failure behavior, but for a zero-parameter check that 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?

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a parameterless tool is 4. Nothing in the description misrepresents or omits an input.

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

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

States a specific verb and resource: 'Run one harmless DataLens authentication probe,' with the added scope constraint of a single probe. It is distinguishable from dl_auth_refresh by implication (probe vs. refresh), but the sibling is never named, so the agent must infer the split.

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 word 'probe' and 'check' imply a preflight verification role, and 'one harmless' signals a cheap, safe call, but the description never states when to run it versus dl_auth_refresh or whether it should precede other calls. Usage is implied rather than prescribed.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds that it resolves defaults across five layers (generic, user, project, reference, explicit), which is useful behavioral context, but it does not describe precedence, output, or side effects.

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 dense but every word contributes to the scope, making it appropriately sized for a one-line summary.

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 four undocumented parameters, no output schema, and no usage guidance, the description is too thin for an agent to invoke the tool correctly. It names the operation but omits prerequisites, parameter formats, and return 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 0%, so the description must carry parameter meaning. It mentions 'explicit' and 'reference' and hints at 'project' via 'project_root', but gives no meaning for the 'family' parameter or the format of the object parameters, leaving most parameters unexplained.

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

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

States the verb 'Resolve' and the resource 'authoring defaults', scoped to 'one visual family'. It lists the default categories (generic, user, project, reference, explicit), giving a clear sense of the operation, though it doesn't differentiate from any sibling because none is directly comparable.

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

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

No sentence explains when to call this tool, what prerequisites exist, or what alternatives exist. The description only describes what it does, leaving usage entirely implicit.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is known. The description adds real context beyond them: the call refreshes exactly once, depends on the configured yc profile, and deliberately does not return the token, which tells the agent it cannot read the credential from the response. Error/failure behavior is still undisclosed.

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, no filler, and it front-loads the action (refresh) before the constraints (once, via yc profile, no token returned). 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 zero-parameter, no-output-schema authentication utility, the description covers the essentials: what it does, the profile dependency, single-shot semantics, and the fact that no token is returned. Only failure/expiry behavior is unaddressed, 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?

The tool takes zero parameters, so there is no per-parameter semantics to convey; the schema already constrains additionalProperties=false. Baseline 4 applies for a zero-parameter tool.

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

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

States a specific verb and resource (refresh the process IAM credential) plus qualifiers that scope the operation: 'once', 'through the configured yc profile', 'without returning the token'. It is clearly distinguishable from dl_auth_check, though it does not explicitly name that sibling.

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

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

Usage is implied rather than stated: 'once' hints at a single, non-repeatable invocation and 'through the configured yc profile' signals a prerequisite (a configured yc profile must exist). There is no explicit when-to-use/when-not guidance and no pointer to dl_auth_check as the alternative for inspecting credential state.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds useful context beyond that: it writes to local files and produces a completeness manifest, plus the caveat that this is not a restore guarantee. It still omits failure behavior and how partial exports are reported.

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 that leads with the core action and appends the scope caveat. No filler, but it is terse enough that no further elaboration is offered where it would help.

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 0% parameter coverage, the description should carry more of the load than one sentence. It omits how targets/revisions are resolved, what the manifest contains, and how export outcomes or failures surface.

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

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

Schema description coverage is 0% and the description says nothing about the two required parameters (targets, output_dir) nor the nested target fields (branch, revision_id, expected_saved_revision). With the schema bearing no descriptions, the description fails to compensate for the gap.

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

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

States a specific verb (export) with clear resources (exact object snapshots plus a completeness manifest) and destination (local files). The scope caveat ('not a full-restore claim') sharpens the purpose, though no sibling is named for differentiation.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling (e.g. dl_dashboard_snapshot, dl_object_get) is referenced. The 'not a full-restore claim' caveat implies a boundary but does not route the agent or state preconditions.

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=true and openWorldHint=true, so safety is partly covered. The description adds a genuinely useful behavioral guard beyond them: it deletes only the exact objects that match an unchanged preview, implying drift between preview and apply causes deletion to be skipped or rejected.

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 tightly-written sentence with the safety constraint front-loaded. No filler or repetition.

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

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

For a destructive tool with no output schema, zero schema description coverage, and nested object parameters, the description covers intent and the preview-freshness safety contract but says nothing about the structure or content expected inside the two nested parameters.

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

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

Schema coverage is 0% and both parameters are nested objects with no inner descriptions, so the description must carry the load. It does clarify the semantics of 'preview' (must be unchanged) and 'confirmed_delete' (the exact ordered objects), but gives no hint about the nested shape or fields either parameter requires.

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 a specific scoped resource (the exact ordered objects confirmed from an unchanged cleanup preview), and implicitly distinguishes itself from the dl_cleanup_preview sibling. It stops short of naming what kind of objects are deleted, so the resource remains somewhat abstract.

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 'confirmed from an unchanged cleanup preview' encodes a clear prerequisite workflow: a preview must exist and must not have changed before this call is safe. It does not explicitly name dl_cleanup_preview as the required precursor, leaving the agent to infer the ordering.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the 'dependency-based' framing, telling the agent the computation traces dependencies rather than doing a naive set diff, but says nothing about output format or side effects beyond what annotations provide.

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

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

A single tight sentence that front-loads the operation and its key constraint. No filler, no redundancy.

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

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

There is no output schema and no parameter documentation, so the description should carry more weight. It never explains the shape of the preserve/delete result or what candidates/preserve_roots should contain, leaving the agent without enough to invoke the tool precisely.

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?

Both required parameters (candidates, preserve_roots) have 0% schema description coverage, and the description does not explain what either represents or how they interact with dependency resolution. With two undocumented required inputs, the description fails to compensate for the coverage gap.

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

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

The description uses a specific verb ('compute') and names the concrete artifacts produced ('dependency-based preserve and delete sets'), which is materially more informative than the tool name. 'Without deleting anything' distinguishes its intent from a cleanup apply operation, though it never names the sibling explicitly.

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

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

'Without deleting anything' implies this is the safe preview step before a destructive cleanup, but the description never states when to use it versus dl_cleanup_apply or what to do with the computed sets. Usage is only inferable, not 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 idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is partially covered. The description adds the useful fact that it writes only a local artifact and never touches DataLens, but does not explain what gets written, whether it overwrites a previous artifact, or any auth/permission needs.

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

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

A single compact clause that is front-loaded with the core action and ends with the key constraint. No filler, though it is arguably too terse given the undocumented parameter surface.

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 tool with a nested object, no output schema, and zero parameter documentation, the description is far too thin. An agent gets no help understanding bindings, the output artifact location, or what a successful compile returns.

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

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

Schema coverage is 0% across 6 parameters including a nested 'bindings' object, and the description mentions none of them. The required recipe_id/bindings and optional reference/output_dir/presentation/project_root are left entirely unexplained, so the description fails to compensate for the coverage gap.

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

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

States a specific verb+resource: 'Compile a typed recipe to a compact local artifact reference,' and distinguishes itself from the DataLens-centric siblings by noting it never accesses or writes DataLens. It is clear what the tool produces, though 'artifact reference' and 'typed recipe' remain somewhat jargon-y.

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 alternatives, nor on prerequisites (it implies a recipe_id and bindings must already exist, but says nothing about where they come from). The 'never access or write DataLens' note implicitly frames scope but is a constraint, 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the non-recursive scope ('only its direct dependencies') and that the style reference is kept separate, which is real behavioral context. However it says nothing about pagination behavior (max_pages/page_size/continuation exist) or how view/branch affect the result.

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

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

A single front-loaded sentence with no filler. The clause 'keep an optional style reference separate' is slightly opaque but does convey a real distinction.

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 9-parameter tool with no output schema and zero parameter documentation, the description is far too thin. An agent cannot determine how view/branch alter the read, how pagination works, or what the snapshot actually returns.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate and largely does not. It only gestures at reference_dashboard_id ('optional style reference separate') and dependency depth; view, branch, fields, revision_id, max_pages, page_size, and continuation are entirely undocumented in both schema and description.

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

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

States a clear verb and resource ('Read one dashboard') plus a scoping constraint ('only its direct dependencies') and a distinction for the style reference. It does not name or differentiate itself from siblings such as dl_object_get or dl_object_relations, which likely overlap with 'read an object and its relations'.

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 versus alternatives guidance. Given siblings like dl_object_get, dl_object_relations, and dl_object_diff, an agent cannot tell from the description when a dashboard snapshot is preferred over those.

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, non-destructive and openWorld, so the safety profile is covered structurally. The description adds a genuine behavioral caveat about the epistemic weight of results ('data evidence, not chart branch proof'), which is useful context. However, it says nothing about pagination interaction (max_pages/offset), result size limits, or cost despite 'bounded' implying a constraint.

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 the action verb first and the qualifying caveat second; nothing is wasted. The second clause is somewhat cryptic jargon, which slightly reduces how much structure is achieved per word.

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 10-parameter query tool with no output schema, no annotation gaps and zero schema description coverage, the description is far too thin — it omits how results are shaped, how paging works, and how the two required parameters relate to the rest. Adequate only in the narrow sense that annotations cover the safety profile.

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

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

Schema description coverage is 0% across 10 parameters, so the description carries the full burden and only partially discharges it by clarifying that GUIDs are exact field GUIDs. It never explains the distinction between required 'columns' and optional 'fields', nor the roles of filters, params, sort, limit, offset, or max_pages.

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 ('Run a bounded Dataset query') and the keying mechanism ('by exact field GUIDs'), so the agent knows it is a data-query tool rather than a metadata tool. It does not name or differentiate itself from siblings like dl_dataset_validate or dl_dashboard_snapshot, leaving that inference to the agent.

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

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

The clause 'this is data evidence, not chart branch proof' gestures at a use boundary but never names an alternative tool or a concrete condition for choosing this over dl_dashboard_snapshot or dl_dataset_validate. An agent can only guess when this is the right call.

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 destructiveHint=false, and "without mutation" largely restates that, so little new behavioral value is added there. The description does add useful scope information (what is actually validated), but no error/warning semantics or auth requirements are disclosed.

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

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

A single front-loaded sentence with no filler; the verb and scope come first. It is efficient, though it lacks the structural separation (e.g., a usage line) that would make it more scannable.

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

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

There is no output schema, so the description should explain what a validation result looks like (pass/fail, error list) and how the two mutually optional inputs behave. Neither is covered, leaving the agent unable to predict the outcome of a call.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does not. It never explains the anyOf contract (supply either dataset_id or fields), when to use one versus the other, or the per-field structure (guid, formula, data_type, aggregation) that the validator consumes.

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

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

States a specific verb (validate) and enumerates the validated surface: field GUIDs, calculation levels, and cross-field formula restrictions. It is clear what the tool does, but it does not distinguish itself from the nearby dl_editor_validate sibling, 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?

"Without mutation" implies a safe pre-flight check, so the intended usage (dry-run validation before committing changes) is inferable. However, no alternative tools are named and no explicit when-to-use/when-not conditions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world behavior. The description adds that validation covers artifact references and performs no execution, which reinforces (but largely echoes) the read-only annotation. It does not disclose what a failure response contains or how errors are surfaced.

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

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

A single front-loaded sentence with no filler. It states the scope and the key constraint (no execution) in one pass.

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

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

With no output schema and no annotations describing return values, the description should say what validation produces (pass/fail, error list, artifact-resolution errors). It omits this entirely, which is a meaningful gap for a validation tool whose value is in its error reporting.

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

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

Schema description coverage is 0%, so the schema only gives types (object/array) and a oneOf requirement. The description compensates partially by mapping 'one Editor draft' to draft and 'a mixed typed draft batch' to drafts, but 'mixed typed' and the structure of a draft object remain unexplained.

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

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

States a specific verb (Validate) and resource (one Editor draft or a mixed typed draft batch), which distinguishes it from the sibling dl_dataset_validate by scope. The 'without execution' qualifier further narrows intent. It stops short of naming the sibling alternative 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 when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as dl_dataset_validate or dl_compile_recipe. The reader must infer that this is a pre-execution check from the phrase 'without execution' alone.

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, destructiveHint=false, and openWorldHint=false. The description adds no behavioral context beyond those safety guarantees, such as auth needs, rate limits, or what 'versioned' implies operationally.

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

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

The description is a single front-loaded sentence with no filler. Every phrase contributes to stating what is returned and for what scope.

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

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

With no output schema, the description should explain the return value more concretely than 'versioned backend and effect contract.' It also leaves the required 'method' input entirely unspecified beyond a vague scope hint, making the definition incomplete 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 0%, so the description must compensate for the single 'method' parameter. It only says 'one supported DataLens operation,' which hints the parameter is an operation identifier but gives no format, valid values, or relation to the parameter name.

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 ('Return') and resource ('versioned backend and effect contract') scoped to 'one supported DataLens operation.' It clearly says what the tool does, though it does not distinguish itself from siblings like dl_operation_get or dl_editor_validate.

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 only identifies the scope as one operation, leaving the agent to infer when this contract lookup is appropriate versus other DataLens introspection tools.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-idempotent write. The description adds that it saves AND reads back, and that dependencies are honored, which is useful beyond the annotations, but says nothing about auth, permissions, 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?

Front-loaded with the verb and outcome, but the follow-up sentences are dense jargon ('top-level object_type/name/client_ref and nested dataset.connection_id/source/fields') that requires re-reading. Nothing is wasted, yet clarity could improve with structure.

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 nested objects, no output schema, and zero schema description coverage, the description partially fills the gap on drafts but leaves destination, operation_id, and delivery_mode unexplained. An agent can call it but must guess at destination shape and the read-back return.

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

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

With 0% schema description coverage the description must compensate, and it does explain the drafts item shape (artifact_path as absolute path, top-level object_type/name/client_ref, nested dataset fields, override rules). However it says nothing about the required destination object (workbook_id/collection_id/path variants), operation_id, or delivery_mode, leaving half the contract opaque.

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 clear verb (Create) and two resource types (typed DataLens drafts, local JSON artifact references), which reads distinctly against siblings like dl_object_get, dl_object_update, and dl_object_publish. Differentiation is implied by the create semantics rather than stated, so it falls short of 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 guidance on when to choose this over dl_object_update, dl_object_publish, or dl_compile_recipe, and no prerequisites or exclusions are given. 'In dependency order' hints at sequencing but is not a usage rule.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that it returns a 'narrow semantic diff' rather than the full object, providing some behavioral context about the return nature. However, it does not explain what the diff contains, how large it may be, or any auth requirements, so the added transparency is modest.

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 efficient and immediately states the core action and constraint. It could be slightly more structured given the tool's complexity, but it avoids verbosity.

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

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

The tool has a nested patch parameter, no output schema, and 0% schema description coverage, yet the description is a single sentence. While annotations cover the safety profile, essential invocation details—such as patch shape or the meaning of object identifiers—are absent. It is therefore incomplete for an agent to call correctly without further guessing.

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

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

Schema description coverage is 0% across three required parameters, so the description must carry the burden. It implies that object_type and object_id identify a 'saved object' and that patch is a 'typed patch', but it gives no syntax, format, or relationship details for any of them. For a nested patch object especially, this leaves callers without needed guidance.

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

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

The description uses a specific verb ('Read') and resource ('saved object'), and distinguishes the tool from mutation siblings by stating 'without mutation'. It also indicates the return is a 'narrow semantic diff for a typed patch', which separates it from a plain getter. However, it does not explicitly name or contrast with sibling tools like dl_object_get or dl_object_update.

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

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

The phrase 'without mutation' implies the tool is used to preview a patch before applying it, which is an implied usage context. There is no explicit guidance on when to choose this over dl_object_get, dl_editor_validate, or dl_object_update, and no stated prerequisites. Implied usage without alternatives yields a 3.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the notable behavioral constraints that lookup is by exact type/ID and supports branch/revision scoping, but it does not explain branch semantics, revision fallback behavior, or failure modes for a missing object.

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 efficient sentence with the core action front-loaded and no filler. It is appropriately sized, though the brevity contributes to the parameter gaps noted elsewhere.

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

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

There is no output schema, so the description should say what is returned, but it does not (e.g., whether a summary or full object is returned, how 'view' affects output). Given a read tool with two undocumented enum/array params and no output schema, this is only adequate.

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

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

Schema description coverage is 0%, so the description must carry the load. It names object type, ID, branch and revision (4 of 6 params), but the 'view' enum (full/summary/projection) and the 'fields' projection array are left entirely undocumented in both description and 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 (Read) and resource (DataLens object) with the precise scope 'one' and 'by exact type, ID'. This distinguishes it from write siblings like dl_object_create/update/publish and from multi-object tools. It does not, however, differentiate itself from read-oriented siblings such as dl_object_relations or dl_object_diff.

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 usage ('exact type, ID') but never says when to choose this tool over alternatives like dl_object_relations, dl_object_diff, or any listing tool. There is no mention of prerequisites, branch selection rationale, or exclusions.

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

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

Annotations already declare destructiveHint=true, non-idempotent and open-world, so the safety profile is covered. The description adds useful behavior beyond that: the publish must originate from a verified saved revision, and it also reads the published branch afterward. It omits what gets overwritten, auth requirements, and error behavior for stale revisions.

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 that front-loads the verb and subject with no filler. It is appropriately sized, though it sacrifices detail for brevity given the undocumented parameters.

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

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

For a destructive, non-idempotent mutation on a nested target array with five undocumented sub-fields and no output schema, the description is too thin. It gives the high-level contract but leaves the agent without enough detail to construct correct target entries.

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

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

Schema description coverage is 0%, so the description must compensate and does not. It alludes to the saved/published branch concept, but never explains object_type, object_id, revision_id, expected_saved_revision, or operation_id, leaving the nested target structure largely opaque.

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 (publish) and resource (chart or dashboard objects), plus the source constraint (fresh verified saved revision). It reads as the only publish operation among siblings, though it doesn't name them for contrast. Clear enough for an agent to select it.

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

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

'Only from a fresh verified saved revision' is a genuine precondition that tells the agent when this tool is appropriate. However, there is no guidance on when to use alternatives (e.g., dl_object_update or dl_object_create) or what to do when no fresh saved revision exists.

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, openWorldHint, and destructiveHint, covering the safety profile. The description adds that relations are 'compact' and 'direct' for an exact object ID, which hints at return shape, but it does not describe pagination behavior or auth requirements. With annotations doing the heavy lifting, a 3 is appropriate.

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

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

The description is a single efficient sentence with the verb front-loaded and no filler. It is appropriately concise, though the terseness leaves important parameter and behavioral details unaddressed elsewhere.

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

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

Given 4 parameters, 0% schema description coverage, and no output schema, the one-sentence description is insufficient. It omits pagination parameters, return format details, and any indication of how many relations or how to page through them.

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

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

Schema description coverage is 0% for 4 parameters. The description only clarifies object_id as an 'exact DataLens object ID'; max_pages, page_size, and page_token are entirely undocumented in both schema and description, so the description fails to compensate for the coverage gap.

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

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

The description states a specific verb ('Read'), resource ('compact direct relations'), and scope ('for one exact DataLens object ID'), which distinguishes it from siblings like dl_object_get or dl_object_diff. However, it does not explicitly name an alternative tool or condition, so it falls short of the top score.

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

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

There is no guidance on when to use this tool versus alternatives such as dl_object_get or dl_object_diff. It also lacks any prerequisites or exclusions, leaving the agent to infer usage from the tool name alone.

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

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

Annotations already declare destructive=true, non-idempotent, and open-world, so safety is covered. The description adds real behavioral context beyond them: revision-check semantics imply optimistic concurrency, 'per-object saved readback' describes the response, and the artifact branch explains tab mapping without echoing renderer source.

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

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

Two dense sentences, front-loaded with the core action and scope. No filler, though 'without echoing renderer source' is somewhat cryptic jargon that borders on noise.

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

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

No output schema exists and 'per-object saved readback' only gestures at return behavior. For a destructive, multi-object mutation with unexplained operation_id and delivery_mode, the description leaves gaps an agent may need.

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

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

Schema description coverage is 0%, so the description must carry the load, and it only partially does. It clarifies how artifact_path sits beside object_type/object_id/expected_revision and what happens to tabs, but patch, operation_id, and delivery_mode are left unexplained.

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

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

States a specific verb and resource ('Apply narrow saved-object patches') and adds scope detail (revision checks, per-object readback). It implicitly separates itself from dl_object_create/publish by emphasizing patching of existing objects, though it does not name any sibling explicitly.

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

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

The word 'narrow' hints at intended scope, but there is no explicit when-to-use, when-not-to-use, or reference to alternatives like dl_object_create or dl_object_publish. An agent must infer routing from the name alone.

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, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds that returns are 'compact' by default and that lookup is exact-match rather than fuzzy, but it says nothing about the include_detail flag that toggles the detailed form, which is the one behavioral lever an agent would want explained.

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 scope qualifier and lookup mode are front-loaded. It is efficient, though arguably it is short because it omits needed information rather than because it is tightly edited.

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 two-parameter read-by-ID tool with annotations covering safety and no output schema, one sentence is close to sufficient. However, include_detail's effect and the distinction from dl_operation_reconcile are both absent, so an agent lacks the last pieces needed to call it optimally.

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

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

Schema description coverage is 0% for both parameters. 'By exact ID' does convey that operation_id is an exact-match key rather than a pattern, and 'compact' faintly implies a non-compact counterpart, but include_detail is never named or explained, leaving half the parameters undocumented in both the schema and the description.

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

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

States a specific verb (Read), a specific resource (a single modifying-operation record), and the lookup mode (by exact ID, one record). An agent can distinguish this from a list/search tool, but it never names or contrasts with the near sibling dl_operation_reconcile, which also targets operation records.

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 mention of alternatives (dl_operation_reconcile, dl_object_get), and no stated prerequisites. The only implicit hint is 'by exact ID', which tells the agent it must already hold an ID, but nothing routes it here versus elsewhere.

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 destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it performs a readback of the target and deliberately does not replay the write, clarifying the mechanism and the no-side-effect recovery contract.

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

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

One dense sentence with zero filler and the key constraint ('without replaying the write') front-loaded. It is efficient, though the compressed phrasing borders on cryptic for an agent that has no other guidance.

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, annotation-backed tool this covers the action and mechanism, but with no output schema the description should indicate what the reconcile yields (e.g. whether the operation is confirmed applied, failed, or still unknown). That outcome semantics is the main missing piece.

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

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

Schema description coverage is 0% and the single required parameter operation_id is given no explanation in either the schema or the description. 'Uncertain modifying result' hints that operation_id identifies that operation, but the format, source, and scope of the id are left entirely to inference.

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 ('Reconcile') and a specific object ('an uncertain modifying result'), plus the mechanism (exact target readback). It is distinguishable from the many dl_object_* and dl_operation_get siblings, though the term 'reconcile' is somewhat jargon-heavy and the framing is abstract.

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 trigger condition is implied ('uncertain modifying result') and the alternative behavior is ruled out ('without replaying the write'), which points the agent away from a retry. However, no sibling is named and no explicit when/when-not statement is given; the agent must infer this is the recovery path after an ambiguous write.

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=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond those annotations: it performs no DataLens or project access, implying no credentials, no network/project side effects and no state change. It does not describe output shape, but the key behavioral trait (isolated, local, non-invasive) is disclosed.

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

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

A single sentence that front-loads the action and enumerates the returned fields with no filler. Every clause earns its place, including the scope qualifier.

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 parameters, no output schema and full annotation coverage, the description carries its share: it names the three returned items and clarifies the isolation guarantee. Slight gap in that the exact structure of the 'installed version comparison' is not hinted at, but for a simple info endpoint this is adequate.

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

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

The tool takes zero parameters and the schema is an empty object with additionalProperties false, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool; the description correctly signals no input is required.

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 (Return) and concrete resources (process/package identity, capability revision, installed version comparison), so the agent knows exactly what it gets back. The trailing scope note ('without accessing DataLens or the project') implicitly separates it from siblings like dl_auth_check or dl_object_get, though it never names an alternative explicitly.

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

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

Usage is only implied: a diagnostic/identity tool used before or independently of project work. The phrase 'without accessing DataLens or the project' hints at when it is safe or appropriate to call, but there is no explicit when-to-use, when-not-to-use, or named alternative among the 24 sibling tools.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description contributes real context: pagination is bounded and results carry an explicit completeness marker. It stops short of naming the marker or explaining what happens when the page bound is hit.

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 padding, and the key traits (compactness, bounded pagination, completeness marker) appear immediately. The jargon ('bounded full pagination') is slightly dense but earns its space.

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

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

With no output schema and no annotation detail about return shape, the description carries the burden in that area. It hints at return content (compact objects plus a completeness marker) but leaves the definition of a 'workbook entry', its relation to dl_workbooks_list, and the pagination defaults unexplained.

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

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

Schema description coverage is 0% across three parameters, so the description must compensate. It partly does by tying the tool to pagination ('bounded') and mentioning a completeness signal, but says nothing about max_pages vs page_size interaction, their defaults (100), or the 1000 cap that govern the call.

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

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

States a specific verb ('List') and resource ('compact workbook objects'), and adds a scoping qualifier ('compact') that tells the agent these are trimmed representations. It does not, however, distinguish itself from the closely-named sibling dl_workbooks_list or clarify whether entries live inside a given workbook, so an agent still has to infer the boundary.

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 prerequisite beyond the required workbook_id, and no mention of alternatives such as dl_object_get or dl_workbooks_list. The agent must guess which of the ~24 siblings is appropriate for retrieving workbook contents.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds one behavioral detail beyond them — that results carry a completeness marker and pagination is bounded — which is genuinely useful context for a listing call. It stops short of explaining what the marker is or what happens when bounds are hit.

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, and the scoping information is stated first. It is efficient, though its brevity contributes to the gaps in the other dimensions rather than offsetting them.

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

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

For a low-complexity list tool the annotations cover safety, but with no output schema the "explicit completeness marker" is never named or described, so an agent cannot know which field signals truncation. Combined with 0% schema coverage on the two pagination parameters, an agent lacks what it needs to page 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 0%, so both max_pages and page_size are undocumented literals with only defaults and min/max ranges. The phrase "bounded pagination" gestures at these two knobs but never defines their meaning, defaults, or the trade-off between page count and page size, leaving the schema to carry semantics it does not carry.

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+resource ("List DataLens workbooks") and the pagination behavior, which is enough to separate it from write-oriented siblings like dl_object_create or dl_object_update. It does not, however, distinguish itself from the adjacent read sibling dl_workbook_entries.

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 dl_workbook_entries, dl_object_get, or dl_object_relations, and no prerequisites or exclusions. "Bounded pagination" hints at a calling context but stops short of guidance.

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