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 read-only, idempotent, non-destructive, open-world behavior, but the description adds two traits they do not cover: results are 'secret-free' (no credential material is returned) and failures are cached and reused until explicit recovery. The latter is important staleness context for an agent diagnosing auth. It does not describe what a healthy result looks like.

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

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

A single semicolon-linked sentence with the action front-loaded and no filler. It is dense and slightly jargon-heavy ('explicit recovery'), but every clause carries information and nothing is redundant.

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

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

With no output schema, the description must characterize the return, and it only covers the error path ('classified ... errors'). It is silent on what a successful probe returns, which is exactly what an agent needs to branch on. Zero-parameter input is fully covered, but the output contract is incomplete.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 a harmless API probe' that returns 'classified secret-free authentication or scope errors'. An agent can tell this is a diagnostic auth-check rather than a mutation tool. It stops short of explicitly distinguishing itself from the sibling dl_auth_refresh, whose relationship is only hinted at.

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 'reuse a failed automatic refresh until explicit recovery' implies this check consumes cached refresh failures, so usage is implied rather than stated. It never says when to choose this over dl_auth_refresh or what 'explicit recovery' concretely means. Adequate but leaves routing 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description's second sentence talks about what 'recipe_contract' exposes rather than what this tool does or returns, which adds confusion rather than behavioral 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?

It is short and front-loads the core action, which is good. However, the second sentence introduces an entity ('recipe_contract') that is neither this tool nor a sibling, spending a full sentence on material the agent cannot act on.

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

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

With no output schema and four fully undocumented parameters, the description should explain what the resolved presentation looks like and what each input contributes. Instead it describes a different surface ('recipe_contract'), leaving the agent unable to invoke this tool correctly.

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

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

Schema description coverage is 0% across four parameters (family, explicit, reference, project_root), so the description carries the full burden and fails to name or explain any of them. 'One family' faintly gestures at the family parameter, but 'explicit', 'reference' and 'project_root' remain entirely 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?

The description gives a verb ('resolve') and a resource ('effective presentation') scoped to 'one family', but 'effective presentation' is domain jargon whose meaning an agent cannot pin down. It never distinguishes this from closely-named siblings like dl_compile_recipe or dl_object_get, so the agent must guess which one produces a resolved presentation.

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 whatsoever: no preconditions, no mention of an alternative tool, and no indication of when a caller should reach for this versus dl_compile_recipe or dl_object_get. The conditional phrase 'For a registered recipe' hints at a precondition but never states what to do when the recipe is not registered.

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

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

Annotations declare a non-read-only, non-idempotent, open-world mutation, and the description is fully consistent while adding substantial detail beyond them: which external resource is touched (system browser, SSO provider), the 120-second vs 15-second timeouts, cached-sign-in behavior, and — critically — that no tokens or login URLs are returned. That last point is exactly the kind of disclosure 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?

Three dense sentences, front-loaded with the action and default behavior before the edge-case parameter guidance; every clause carries information. Slightly jargon-heavy ('yc account/profile') but 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 single-parameter, no-output-schema mutation with annotations already covering safety and world scope, the description supplies everything an agent needs: what state changes, what it will not return, and how the one flag alters runtime behavior. Nothing material 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 coverage is 0% and the single parameter has no description, so the description carries the full burden and does: it establishes the default (browser enabled), the semantics of false (noninteractive attempt), and the operational consequence of each branch including timing. This fully compensates for the empty 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 ('Refresh IAM') and adds concrete scope: update API/SDK credentials and verify API access. It implicitly separates itself from the sibling dl_auth_check by describing refresh-and-update rather than a status read, but never names or contrasts the alternative explicitly, which keeps it 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?

Gives clear operational context for the one meaningful choice: browser SSO is attempted by default (up to 120s, cached sign-in may complete automatically), and allow_browser=false is for when browser sign-in is disallowed (15s noninteractive). It stops short of routing guidance against the sibling dl_auth_check, so no explicit alternatives are 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 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?

Against annotations that already declare destructive, idempotent, and open-world behavior, the description adds meaningful constraints: unchanged-preview requirement, repeat_of authorization rules, and no automatic retries. It does not describe permissions, rate limits, or budget effects beyond the repeat_of nuance.

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 action, then a focused clarification about repeat_of. Every sentence earns its place; there is 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?

The tool has six parameters including nested objects, low schema description coverage, and no output schema. The description gives only the core action and one behavioral nuance, leaving most parameter semantics and operational limits unaddressed.

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

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

Schema description coverage is only 17%, so the description must compensate, but it only partially explains repeat_of and implies preview's role. Other parameters such as confirmed_delete, operation_id, budget_sec, and max_provider_calls remain undocumented.

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

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

The description states a specific verb and resource: 'Delete exact ordered objects from an unchanged preview.' The condition 'unchanged preview' distinguishes it from the sibling preview tool, but no sibling is explicitly named. Clear enough for an agent to understand the core action.

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 from an unchanged preview and gives context for repeat_of after an unknown delete, but it does not explicitly state when to use this tool instead of alternatives such as dl_cleanup_preview. No when-not conditions or alternatives are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that computation is dependency-based and non-mutating, but says nothing about what happens when budget_sec or max_provider_calls are exhausted, whether results may be partial, or that external provider calls are involved (despite openWorldHint and a max_provider_calls 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 front-loaded sentence with no filler or redundancy. It is efficient, though for a four-parameter tool with no schema documentation it is arguably too compact to carry the required 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 0% schema description coverage, no output schema, two required array parameters, and tunable budget/provider-call caps, the description should explain inputs and the shape of the computed plan. It covers only the high-level intent, leaving the agent without enough to call the tool correctly or interpret partial results.

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

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

Schema description coverage is 0% across all four parameters, so the description must compensate and largely fails. It only loosely gestures at preserve_roots (preserve set) and candidates (delete set) without naming either parameter, and completely ignores budget_sec and max_provider_calls, which materially shape the result.

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 ('Compute') and resource ('dependency-based preserve and delete sets'), and the qualifier 'without deleting anything' functionally separates it from the sibling dl_cleanup_apply. It stops short of naming the sibling explicitly, but the operation 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?

Usage is implied rather than stated: the tool is only sensible as a dry run before applying cleanup changes, and the description hints at that with 'without deleting anything.' It never names dl_cleanup_apply as the follow-up action, gives no prerequisites, and does not state when a preview is unnecessary.

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

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

Adds a meaningful behavioral guarantee beyond annotations: it is a local-artifact operation that 'never access or write DataLens', clarifying the scope of the write implied by readOnlyHint=false. Confirms idempotentHint implicitly. Does not disclose side effects on output_dir 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 tight clauses with the core action front-loaded and the prerequisite follow-up second. Every clause earns its place; 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?

Covers the compile output type and the required upstream read, but for a 6-parameter, no-output-schema tool with low schema coverage it omits what output_dir/project_root control and what the returned artifact reference contains. Adequate but leaves gaps an agent must guess.

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

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

Schema coverage is only 17%, so the description must compensate, and it partially does by explaining that bindings comes from recipe_contract.bindings_schema and by referencing 'distinct create/static/compiled-update inputs'. However it leaves reference, output_dir, presentation, and project_root entirely undocumented, so it does not fully bridge 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+output: 'Compile a typed recipe to a compact local artifact reference.' The 'never access or write DataLens' clause implicitly distinguishes it from publish/write siblings. Clear purpose, though it does not name a specific sibling it could be confused 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?

Explicitly prescribes a prerequisite workflow step: 'First read dl_authoring_defaults(family=recipe_id).recipe_contract for bindings_schema...'. It names the sibling to call and what to extract from it, which is strong usage guidance. No explicit exclusions or 'when-not-to-use' statements.

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 establish the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful context: no save occurs, no field replacement is forced, and the output is not a saved result or chart execution. These negative-space clarifications reduce real ambiguity for a tool whose name and 'refresh_source_ids' wording could otherwise read as mutating.

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 main purpose is front-loaded, but the remaining text is a dense run-on chain of clauses ('for an explicit revision-guarded save; this is not a saved result or chart execution') that is hard to parse and repeats the same no-side-effect idea. Information density is high but readability suffers.

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 5 parameters, no output schema, and 0% schema coverage, the description should do more to explain the input contract (especially the dataset_id/fields anyOf) and what a successful validation returns. It explains the include_provider_state return, but leaves the core return shape and the required-input rule implicit.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it only partially does: provider, refresh_source_ids, and include_provider_state get real semantics, but dataset_id and fields do not, and the anyOf requirement (dataset_id OR fields) is never surfaced. It compensates for some but not all of 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+resource ('Validate Dataset fields') and distinguishes the two operating modes (local validation vs. provider=true validation of a saved Dataset). It does not name or differentiate itself from the sibling dl_editor_validate, so an agent must infer the boundary, keeping this short of a 5.

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

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

The description implies when provider mode is appropriate ('through the provider without saving') and hints at the revision-guarded save workflow, but gives no explicit when-to-use vs. dl_editor_validate or other validation siblings, and no prerequisites. 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 readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds genuinely new behavioral context: validation happens without execution, artifact references are included, the accepted input shape is the Editor draft form rather than raw provider data keys, and a static draft is not a substitute for the full saved snapshot.

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

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

Purpose is front-loaded in the first clause, and the three sentences each add distinct information about scope, input shape, and constraints. Some phrasing is dense jargon ('observed variant', 'filename-keyed tabs') that could be tighter, but there is no filler.

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

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

There is no output schema, so the description carries more burden for explaining what validation returns, yet it says nothing about the result shape or failure reporting. It adequately covers input semantics for a read-only validation tool but leaves the outcome side undefined.

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 neither parameter (draft, drafts) is documented in the schema. The description maps loosely onto them ('one Editor draft' vs 'a mixed typed draft batch') but never names the parameters or explains the singular/multiple relationship, nested draft structure, or what 'typed' means, so it under-compensates 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: validate an Editor draft or a mixed typed draft batch including artifact references. It also clarifies the draft format (observed variant, filename-keyed tabs) versus raw provider keys. It does not, however, differentiate itself from the sibling dl_dataset_validate, leaving the agent 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?

The phrase 'without execution' implies this is a dry-run check, which gives implicit usage context, and the note that 'required tabs depend on subtype' hints at preconditions. But there is no explicit when-to-use statement and no mention of alternatives such as dl_dataset_validate or dl_object_publish, so routing 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=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 readOnly=false, idempotent=false, destructive=false, and openWorld=true, so the safety profile is covered. The description adds useful beyond-annotation context: creation happens in dependency order, results are saved and read back, and references may only override client_ref/depends_on. It does not disclose failure behavior, auth/permission needs, or partial-create semantics.

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 verb and the primary object, with no filler. It is tightly packed to the point of being dense, but every clause carries payload rather than redundancy.

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

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

For a complex nested-object creation tool with no output schema and low schema coverage, the description is only partially complete. It covers the draft payload shape but omits destination resolution, operation_id usage, delivery_mode semantics, and error/readback behavior an agent needs to invoke it confidently.

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

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

Top-level schema description coverage is 0%, so the description must compensate. It explains the draft shape (top-level object_type/name/client_ref with nested dataset.connection_id/source/fields) and that artifact_path is an absolute path, adding real meaning beyond the schema. However, destination's three modes (workbook_id/collection_id/path), 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 (Create) and resource (typed DataLens drafts or local JSON artifact references) with concrete scope, including the dependency-ordered save/readback flow. It is distinguishable from siblings like dl_object_update or dl_object_publish, though the dense jargon slightly obscures the plain-purpose statement.

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 prerequisites, and no alternatives named despite a rich sibling set (dl_object_update, dl_object_publish, dl_compile_recipe). The mention of 'dependency order' implies ordering behavior but does not tell the agent when to prefer this tool over others.

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 real behavioral context beyond that: it discloses the output mode (compact diff vs full merged snapshot via include_proposed) and clarifies that no mutation occurs, which shapes how an agent interprets 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?

Three tightly-packed sentences with the core purpose front-loaded. Dense and efficient, though the parameter-routing sentences are terse enough that they lean on the schema to be understood.

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

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

For a 5-parameter tool with heavy nesting, no output schema, and 0% schema coverage, the description covers the main input choice and the include_proposed flag but leaves most nested input semantics unexplained. Adequate but with clear gaps given the complexity.

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

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

Schema description coverage is 0%, so the description must carry the burden. It names patch, dashboard_patch (with the 'native dashboard tabs' qualifier and items/layout/connections sub-fields), and include_proposed, but says nothing about object_type/object_id and nothing about the deeply nested items/add/remove/update structure. Useful but incomplete compensation 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 ('Read one saved object and return a compact diff') and the key modifier 'without mutation', which distinguishes it from sibling mutators like dl_object_update and from the plain reader dl_object_get. It does not explicitly name a sibling, 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?

Implies a dry-run/preview use case ('without mutation') and gives parameter-level routing (patch vs dashboard_patch, when to set include_proposed), but never explicitly says when to choose this over dl_object_get or as a pre-flight before dl_object_update. Usage is inferred 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description correctly spends its budget elsewhere: alias resolution for chart/widget, the returned observed_identity, and strict subtype handling. That alias-resolution behavior is materially useful context an agent could not get from annotations or schema, though error modes and auth requirements remain 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?

Three tight sentences with the core read behavior front-loaded; no filler. The mutation sentence is terse and jargon-dense ('observed type') but is not padding — it is load-bearing context for choosing this 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?

No output schema exists and schema coverage is 0% across 6 parameters, so the description carries the full explanatory burden. It covers type aliasing and view selection but omits the `fields` projection parameter, revision_id semantics, and the many node-type variants, making it only adequate for a tool of this complexity.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it partially does: it explains object_type alias/strict semantics, branch, revision, and the view trade-off. It never mentions the `fields` parameter at all and gives no format guidance for revision_id, leaving real gaps.

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

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

States a specific verb and resource ('Read a known target by ID, branch and optional revision') and pins down which identifiers scope the read. It differentiates itself from write siblings implicitly by noting 'Mutations require the exact observed type', but never names an alternative read tool (dl_object_revisions, dl_object_relations), so routing relies on inference.

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

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

'Use summary/projection for inspection, full state for preservation' is genuine when-to-use guidance for the view parameter, and the type-strictness sentence implies when this tool is required before a mutation. However there is no explicit statement of when NOT to use this tool, nor any pointer to sibling read 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 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 cover readOnly/idempotent/non-destructive, and the description adds non-obvious behavioral context: results are 'direct API-visible' (permission-scoped) and completeness is bounded by the selected pagination rather than a transitive or revision-bound graph. That scoping caveat is exactly the kind of disclosure annotations cannot carry. It omits pagination mechanics and rate/limit behavior, so not a 5.

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

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

Two tight clauses, front-loaded with the action and the direction semantics before the completeness caveat. Dense and terse in a way that fits this engine's voice, though the second clause packs two distinct limitations (transitive vs. revision-bound) into one phrase.

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% schema description coverage on a five-parameter paginated tool, the description should explain the pagination round trip (page_token, page_size, max_pages) and what a relation record looks like. The completeness caveat is valuable, but an agent still cannot tell how to page through results 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 0% across five parameters, so the description carries the full burden. It only addresses 'direction' (partially, since the default is already in the schema) and gestures at pagination without explaining page_size, page_token, or max_pages, and never clarifies the required object_id. The undocumented pagination contract is a real gap for a paged read tool.

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

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

States a specific verb ('Read') and resource ('direct API-visible relations') and goes further by defining the meaning of each direction value, which distinguishes it from generic object readers like dl_object_get or dl_object_revisions. It stops short of fully defining what a 'relation' is or naming a sibling it must not be confused with, so it lands at a clear 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?

The description gives semantic guidance for choosing a direction ('from for dependencies, to (legacy default) for consumers'), which is real usage help for operating the tool. It offers no when-to-use vs. when-not-to-use framing relative to siblings such as dl_object_diff or dl_object_get, so usage 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, and non-destructive, but the description adds genuine behavioral context beyond them: it warns that saved/published flags are not a multi-page snapshot and that absence in limited history cannot prove a write did not apply, which prevents false conclusions. It also discloses that results are a bounded, provider-ordered page.

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

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

Three front-loaded sentences lead with the verb and waste little, and the pagination caveat is placed after the core action. The phrasing is dense and jargon-heavy, but each sentence carries functional content.

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

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

For a 4-parameter, 0%-schema-coverage tool with no output schema and no annotations gap, the description covers pagination and continuity semantics well but omits the shape of a returned revision entry and the page_size bounds. An agent knows how to page but not fully what it will receive.

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 coverage the description must carry all four parameters, and it only clarifies entry_id (known entry), rev_ids (known revision IDs), and page_token (opaque continuation). page_size, its default, and the 1-1000 / maxItems bounds are not addressed, and no value formats are given, so the compensation is incomplete.

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

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

The description states a specific verb (Read) and resource (a bounded provider-ordered revision page) scoped to a known entry, which is clearly distinct from siblings like dl_object_get or dl_object_diff. An agent can tell this is the paginated history reader without opening any schema.

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

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

It gives one concrete usage rule ('Use the returned opaque continuation unchanged') and implicitly frames rev_ids as an optional restriction, so usage is partly implied. However, it never names when to prefer this over dl_object_get, dl_object_diff, or dl_operation_get, and there are no explicit exclusions.

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

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

Annotations already declare destructive=true, idempotent=false and openWorld=true. The description adds real behavioral value beyond that: exact no-ops do not write, revisions are checked with readback, 'writes retain private receipts' and 'unknown effects are not replayed' signals the write/transaction semantics. This is meaningful disclosure a caller needs before mutating saved objects.

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

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

The purpose is front-loaded in the first clause, and most sentences carry non-obvious schema semantics rather than filler. But it reads as one dense run-on paragraph with no structural separation between purpose, sub-mode routing, and write semantics, which hurts scannability for a tool this complex.

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

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

For a tool with a deeply nested schema, no output schema, and 0% schema-description coverage, the definition is largely complete: it covers the patch modes, the destructive/no-op/receipt behavior, and the key field conventions. The unexplained operation_id and delivery_mode are the only material gaps.

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

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

Schema description coverage is 0%, so the description must carry the load, and it substantially does for the complex `changes` payload: keying by id with optional namespace, group children via `group`, layout by `i`, connections by `from`/`to`, and the add/update/remove shape. It is silent on `operation_id` and `delivery_mode`, which are load-bearing for operation tracking, so it falls just short of full compensation.

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 opening states a specific verb and resource: 'Apply narrow saved-object patches with revision checks and readback.' It is distinguishable from dl_object_create (new objects) and dl_object_publish, though it never names those siblings. The purpose statement is clear but heavily wrapped in domain jargon.

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 routes among internal sub-modes ('For existing dashboard tabs use dashboard_patch plus expected_revision', 'Named global parameter removal uses remove_global_params', 'Compiled Editor updates use artifact_path'), which is useful context. However it never states when to choose this tool over a sibling like dl_object_create or dl_object_publish, and offers no when-not-to-use condition, so usage guidance remains implied by the internal modes.

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 declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the per-page cap and the caveat that 'a partial listing cannot prove absence' – an important completeness constraint that changes how the agent reasons about 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?

Three sentences that are front-loaded with the main action and free of obvious padding. However, 'Retains scope, renderer subtype, typed identity and completeness' is opaque jargon that costs tokens without conveying actionable meaning.

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

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

For a three-parameter listing tool with no output schema, the description correctly skips return values and adds the completeness caveat. But it is under-specified on parameter behavior (defaults, ranges, workbook_id) and on what an 'entry' actually contains, which the description gestures at only via vague terms.

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 carries the full burden, yet it explains only the page-size cap ('up to 200 per page'). It says nothing about max_pages, its default (100) or maximum (1000), or workbook_id's role. With three undocumented parameters, the description leaves the bulk of the schema 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?

The description gives a specific verb+resource ('Discover workbook entries') and the pagination scope ('across numeric pages, up to 200 per page'), which an agent can act on. It also explicitly distinguishes itself from the sibling dl_object_get ('A known target uses dl_object_get directly'). The secondary 'establish inventory completeness' framing and the jargon list ('scope, renderer subtype, typed identity') slightly blur the core purpose, keeping it from 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?

It states an alternative (dl_object_get) and a condition that selects it ('a known target'), plus a clear use case for this tool (establishing inventory completeness). It does not, however, cover when-not to use it beyond the known-target case, nor prerequisites such as required workbook_id.

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

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

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.