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/idempotent/non-destructive, so the lower bar is met. The description adds real behavioral value beyond them: 'zero provider calls', 'static_validity_only', results written to 'a private local artifact', and the caveat that a static draft 'does not replace 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 and there is no filler, but the prose is dense and jargon-heavy ('exact typed-dashboard wire', 'observed variant and filename-keyed tabs'), packing four ideas into four sentences that would benefit from plainer structuring.

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

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

For a nested-object, 0%-coverage tool with no output schema, the description covers the behavioral modes reasonably but never indicates what validation results/errors are returned or how the draft payload relates to the resulting artifact, leaving gaps an agent must guess at.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies the draft/drafts oneOf ('one Editor draft or a mixed typed draft batch') and ties 'destination and output_dir' to a specific preparation behavior, but does not document the draft object shape or which tab keys are required per subtype.

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: 'Validate one Editor draft or a mixed typed draft batch... without execution.' The 'Editor draft' framing implicitly distinguishes it from the sibling dl_dataset_validate, though it never names that 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?

'Without execution' and the conditional 'With destination and output_dir...' hint at when each mode applies, giving implied usage context. But it never names a sibling as the alternative or states an explicit when-not-to-use condition, leaving 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. 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?

The annotations already declare readOnly, idempotent, and non-destructive, so 'without mutation' is largely redundant. The description does add one behavioral fact beyond the annotations: include_proposed=true yields the full merged snapshot instead of the compact diff, which signals a response-size tradeoff.

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, front-loaded with the purpose followed by parameter-condition guidance. No padding, though the middle sentence is dense and compresses several conditions into one line.

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

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

A complex 8-param tool with a deeply nested dashboard_patch schema, no output schema, and 0% parameter documentation. The description covers only a fraction of the inputs and never explains artifact_path/artifact_sha256 or expected_revision (likely optimistic concurrency), so an agent could easily mis-supply parameters.

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

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

Schema description coverage is 0% across 8 parameters, so the description must carry the load. It explains patch, dashboard_patch (items/layout/connections), and include_proposed, but says nothing about object_type, object_id, artifact_path, artifact_sha256, or expected_revision, leaving five parameters undocumented.

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

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

States a specific verb+resource (read one saved object) and a distinctive output (compact diff without mutation), which separates it from dl_object_get. It does not explicitly name the sibling alternatives, but the diff-preview scope is clear enough for an agent to distinguish 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?

Gives conditional guidance on when to use patch vs dashboard_patch and when to set include_proposed=true, which is genuinely useful. However, it never says when to prefer this tool over dl_object_get, dl_object_revisions, or dl_editor_validate, so routing among siblings 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 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 the safety profile (readOnly, idempotent, non-destructive), so the description only needs to add context — and it does: it discloses that completeness is bounded by the selected pagination rather than a transitive or revision-bound graph, and that publish_targets yields a read-only manifest with no automatic publication. That is meaningful behavior beyond the structured fields.

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

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

Three dense sentences with no filler; the primary read semantics are front-loaded before the completeness caveat and the optional manifest behavior. The jargon density is high but each sentence earns its place.

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

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

No output schema exists, and the description covers the two non-obvious behaviors an agent needs (pagination-bounded completeness and the read-only publish_targets manifest). The main remaining gap is that pagination parameters (page_size, page_token, max_pages) are undocumented, but for a read-only tool the coverage is close to sufficient.

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 burden, and it does define direction's two values and the purpose of publish_targets (intended saved revisions producing a read-only manifest). It leaves object_id, max_pages, page_size, and page_token entirely unexplained, so it only partially 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?

The description pairs a specific verb ('Read') with a specific resource ('direct API-visible relations') and immediately qualifies scope (direct, API-visible). It does not name a sibling, so an agent must infer differentiation from the resource noun alone, which is nonetheless distinctive against tools like dl_object_diff and dl_object_revisions.

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 explains the semantics of direction=from (dependencies) vs to (consumers, legacy default), which implicitly tells the agent which value yields which view. However, it never states when to prefer this tool over sibling graph/diff/revision tools, nor any prerequisites, leaving usage 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 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, so the safety profile is covered. The description adds real behavioral context beyond that: exact no-ops do not write, revision checks and readback occur, writes retain private receipts, and unknown effects are not replayed. It does not fully explain revision-mismatch handling, keeping it short of a 5.

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

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

The core constraint is front-loaded, but the body is a dense, run-on block that is hard to parse without rereading. Most sentences carry unique information, so it is not padded, but structure and separation of the four patch modes could be far clearer.

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 mutation tool with no output schema and a large nested schema, the description covers the key modes, no-op behavior, and receipt/replay semantics adequately. Gaps remain around operation_id and delivery_mode interaction at the description level, but the schema handles the structural detail.

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 only 33% schema description coverage, the description must compensate, and it does for the nested structures: it explains keying conventions (items/globalItems by id with optional namespace, group_control children via group keyed by native id, layout by i, connections by from/to) and the add/update/remove shape. It leaves operation_id and top-level changes semantics unaddressed, so it is short of complete.

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 more precise than a bare 'update' and conveys the narrow, patch-oriented scope, though the phrase 'saved-object' is jargon that requires domain familiarity to place against siblings like dl_object_create.

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 routes the agent between sub-modes explicitly: dashboard tab edits use dashboard_patch plus expected_revision, named global parameter removal uses remove_global_params, and compiled Editor updates use artifact_path. What is missing is differentiation from sibling tools (create vs publish vs update), so it is strong on intra-tool routing but silent on tool-selection context.

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

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

Annotations already declare 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 readOnly/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: ACKed historical updates may resolve with unverified content, new changes require fresh CAS, unknown effects and connection provisioning stay held, and names or absence never establish effect. This is genuinely useful disclosure of edge-case behavior, though it could be more explicit about the returned status values.

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?

Reasonably compact with little filler, but the structure is a wall of specialized jargon ("fresh CAS", "persisted metadata marker", "unverified content") that is not front-loaded or organized for quick scanning. Every sentence is dense and assumes deep domain knowledge.

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

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

Annotations cover the safety profile and there is no output schema to explain, so the main gaps are operation_id semantics and what a reconcile result looks like. The description covers edge-case behavior well but leaves the core contract (what is being reconciled, what the outcome means) under-specified.

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 burden. It meaningfully explains investigate_create=true (investigates legacy unmarked creates by name) and the caveat that names never establish effect, but operation_id is left entirely undescribed. Partial compensation for a two-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 mechanism ("Reconcile by exact target readback without replay"), so the general action is discernible. However, it never names the resource being reconciled in plain terms (an operation, keyed by operation_id), and it does not distinguish itself from siblings like dl_operation_get, leaving the agent to infer the relationship from jargon alone.

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

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

The description catalogs outcomes for various effect categories but never states when an agent should call this tool, when it should not, or what alternative (e.g. dl_operation_get) to use instead. No trigger condition or prerequisite is given.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=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 readOnlyHint, idempotentHint, non-destructive and openWorld. The description adds meaningful context beyond that: the page ceiling (up to 200 per page) and the caveat that a partial listing cannot prove absence. It does not disclose auth needs, rate limits, or return format, so it is moderate value on top of the annotations.

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

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

Purpose and pagination are front-loaded, and the alternative/caveat sentence earns its place. However, the middle sentence ('Retains scope, renderer subtype, typed identity and completeness') is dense jargon whose meaning is not clear, weakening otherwise tight 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?

With no output schema, the description is expected to convey more about the return shape, but it offers only the cryptic 'Retains scope, renderer subtype, typed identity and completeness.' Annotations cover safety, and the alternative routing is present, so it is adequate but leaves the agent guessing about parameter usage and result structure.

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

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

Schema description coverage is only 25%, so the description is expected to compensate, but it does not. It only restates the page size ('up to 200 per page') that the schema already caps, and says nothing about max_pages, workbook_id, or how continuation should be obtained, leaving half the parameters undocumented in both places.

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

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

The description gives a specific verb and resource ('Discover workbook entries') plus the pagination scope, and explicitly names the sibling it is not ('A known target uses dl_object_get directly'). This lets an agent distinguish it from dl_object_get without opening the schema, though the phrase 'establish inventory completeness' is somewhat jargon-heavy.

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 names an alternative (dl_object_get) and the condition that selects it (when the target is already known), and states the key caveat that 'a partial listing cannot prove absence.' There is no explicit prerequisite or exclusion otherwise, but the routing guidance is clear.

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 two genuinely useful behavioral facts (pagination is bounded, results carry a completeness marker), but it never explains what the marker means or how truncation affects the agent.

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. "Explicit completeness marker" is slightly cryptic, but nothing is wasted and the key qualifiers come first.

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 carry more of the return-shape burden. It mentions a completeness marker and a scope-bound cursor but never clarifies how to detect an incomplete inventory or how continuation relates to the marker, leaving a real gap for a paginated listing tool with three parameters.

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

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

Schema coverage is only 33% — continuation is documented, but max_pages and page_size carry no descriptions. The phrase "bounded pagination" gestures at the page-cap parameters but adds no semantics (e.g. whether hitting max_pages truncates silently or what defaults imply), so the description does not compensate for the coverage gap.

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

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

States a specific verb and resource ("List DataLens workbooks") plus scope qualifiers (bounded pagination, completeness marker). An agent can tell this is the workbook inventory lister, though it does not explicitly distinguish itself from siblings like dl_workbook_entries or dl_admin_inventory.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative despite several closely related sibling tools (dl_workbook_entries, dl_admin_inventory). Usage is only implied by the verb "List".

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