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

With no annotations, the description carries the full burden and does disclose two meaningful traits: one action per call and a mandatory precondition revision (optimistic concurrency, implying stale revisions are rejected). It leaves critical behavior undisclosed: what happens on revision mismatch, whether actions are retry-safe, what "approved" gates, and what the call returns.

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

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

Two tight sentences, front-loaded with the core operation and immediately followed by the key constraint, then the safety boundary. No filler. It is arguably under-specification rather than verbosity, but as prose structure it is efficient.

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

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

For a 12-parameter, mutation-capable browser automation tool with no annotations and no output schema, the description is too thin. An agent still cannot tell how to obtain expected_revision, how to target elements, which parameters apply to which action, or what failure looks like.

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 12 parameters, including a nested expected_target object, so the description must compensate and does not. Only expected_revision is indirectly explained ("observed revision"); the targeting model (element_id vs role/name vs url), value/checked/direction applicability per action, and timeout_ms semantics are 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?

"Perform one approved semantic action" gives a verb but the resource is abstract — "semantic action" only becomes concrete via the schema's enum (click, fill, scroll, navigate, read_state…). It does not distinguish itself from siblings like adl_execute, adl_gesture, or adl_prepare_input/adl_commit_input, so an agent cannot route confidently from the description 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?

"Mandatory observed revision" strongly implies a read-then-act workflow (observe first, then act on the returned revision), which is real usage guidance. "No arbitrary JS, files or physical input" sets a negative boundary. But there is no explicit statement of when to prefer this over adl_execute or adl_gesture, nor what "approved" means or who approves.

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

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

With no annotations, the description carries the full burden and does a reasonably good job: it discloses that no paths/commands/shell are passed, that no input or focus changes occur, and crucially that quit only affects instances this server launched. What it omits is what status returns, whether launch is blocking, and what failure modes look 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?

The sentence opens with the core action set, front-loading what the agent needs most. The three consecutive 'never ...' clauses are slightly repetitive but each adds a distinct safety boundary. No wasted preamble or filler.

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

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

For a two-parameter, no-annotation, no-output-schema tool, the definition covers safety boundaries and quit scope well. It is still incomplete on the return value of 'status' (no output schema exists to compensate), the blocking behavior of 'launch', and how this tool relates to adl_open/adl_close.

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. It does clarify that application_id identifies a configured opted-in application rather than a file path or command, which is real added meaning. But it doesn't explain what 'status' reports, what 'launch' does beyond being in the background, or how invalid IDs are treated, leaving the enum values under-specified.

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 set of verbs (status, background-launch, quit) acting on a specific resource (the one configured opted-in application). An agent can tell what the tool does without opening the schema. However, it never distinguishes itself from siblings like adl_open or adl_close, which sound like overlapping application-lifecycle operations.

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

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

The 'never ...' clauses describe behavioral limits, not when to choose this tool over adl_open, adl_close, or adl_execute. There is no positive routing guidance, no prerequisite mentioned (e.g., that the app must appear in adl_applications first), and no explicit exclusion criteria an agent can act on.

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?

readOnlyHint=true already declares the safety profile, and the description only restates 'Read-only', which earns no credit. It does add one useful trait beyond annotations: the result is at most a single application and may be absent ('if any'). No mention of permissions or error behavior.

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

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

Two short sentences with the core fact front-loaded. The trailing 'Read-only' is redundant with the annotation and is the one sentence that does not earn its place.

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

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

For a zero-param read with no output schema, the description should describe the returned object's shape, but it only says 'the one ... application'. Adequate to call safely, but thin on what comes back.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no input is needed.

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

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

States a specific verb ('List') and a specific resource ('the one configured opted-in application for noninterfering background lifecycle'). An agent can tell it returns applications rather than the single app in adl_app, though the sibling distinction is left implicit and the qualifier 'noninterfering background lifecycle' is 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?

No guidance on when to call this instead of adl_app, adl_targets, or adl_capabilities. The only implied usage cue is 'if any', which hints the result can be empty but does not tell the agent what to do in that case.

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

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

readOnlyHint=true already tells the agent this is a safe read with no side effects, so the description doesn't need to cover safety. It does add value by naming the information classes returned (adapters, safety modes, limits), but with no output schema it omits anything about the shape or format of that response.

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

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

A single sentence, front-loaded with the verb and the three categories of information, with zero filler. Nothing is repeated from the title or schema.

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

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

For a no-param read tool this is close to adequate, but with no output schema the agent has no idea what the response looks like (a list of adapter names, a capability matrix, limit values) or how to use it. One short clause on the return shape or on calling this before invoking other adl_* actions would complete it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly mentions no argument requirements, consistent with 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 (Inspect) and names the specific resources exposed: adapters, safety modes, and resource limits. It is clearly distinguishable from the action-oriented siblings (open, observe, capture), which all perform operations rather than report capability, though the description never says so 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: an agent can infer this is a discovery/introspection call to make before invoking the act/resource siblings, but the description never states when to call it or that it should precede other adl_* calls. No alternatives or exclusions 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?

Beyond readOnlyHint=true, it discloses that capture is gated by a trusted visual policy, returns PNG plus frame metadata, operates on retained frames (so results are stale-able), and that returned pixel content is untrusted. It doesn't say what happens when policy denies the request or how failures surface, but the added context clearly exceeds the single annotation.

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?

Four short sentences, front-loaded with the purpose and return type, followed by the frame-retention usage pattern and the untrusted-content caveat. Nothing is padding, though the policy clause is suggestive rather than precise.

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?

It covers purpose, return type, and one usage pattern, but with no output schema, five parameters at 0% description coverage, and only readOnlyHint for annotations, gaps remain around size-limit semantics and policy-denial behavior for a tool whose output is pixels.

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

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

Schema description coverage is 0%, so the description must carry the load. It usefully clarifies frame_id (must match a retained frame) and region (source coordinates), but leaves max_pixels and max_dimension — presumably downscale or cap limits — completely unexplained, so half the non-obvious parameters remain 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 (capture/observe) applied to a specific resource (actual rendered browser or exact-window pixels) and declares the return type (PNG plus frame metadata). It doesn't explicitly contrast with close siblings like adl_observe or adl_record, so an agent must infer which of the visual tools to pick.

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 one concrete usage pattern — combine frame_id with a source-coordinate region to inspect the SAME retained frame — and a precondition (trusted visual policy must permit). It never says when not to use it or names an alternative sibling, so selection 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?

With no annotations, the description carries the full burden and does disclose the key destructive effect: all handles and cursors are invalidated. It stops short of stating reversibility, idempotency (what happens if the session is already closed), error behavior for unknown session ids, 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 sentence with no filler; the destructive side effect is stated immediately after the action.

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

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

For a one-parameter tool with no output schema and no annotations, the description covers the core action and its consequences. Only the semantics of session_id and post-close error behavior are left undocumented, which are modest 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?

There is a single parameter, session_id, at 0% schema coverage, and the description adds nothing about its format, expected origin (presumably obtained from adl_open), or behavior for an invalid value. The word 'session' hints at the linkage but does not document the parameter.

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

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

States a specific verb ('Close') and resource ('session') plus the effect on handles and cursors. It reads as the natural counterpart to the sibling adl_open, though it never names that counterpart 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: an agent infers it should close a session when finished, but there is no explicit when/when-not guidance, no note on what state the session must be in, and no mention of alternatives such as simply abandoning a session.

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

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

With no annotations, the description carries the full burden and does well: it discloses single-use semantics ('consume... once'), target re-verification, per-chunk focus checks, a capability restriction (clipboard and control keys unavailable from text), the return payload (acknowledgement plus fresh PNG), and critically that failures may report partial execution. The main omission is permission/authorization context and what state remains after a partial failure.

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

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

Two dense sentences, front-loaded with the core action and followed by behavioral caveats. Every clause carries information (restrictions, return value, failure mode) with no filler, though the jargon-heavy phrasing ('bounded chunk', 'released-input acknowledgement') costs some readability.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema coverage, the description does substantial work on behavior, return value, and failure modes. It still leaves the two required parameters unexplained and omits any authorization or confirmation-lifecycle details an agent needs to call it 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 the description must compensate. It does clarify value semantics indirectly ('click or enter plain text' implies value presence selects typing vs. clicking) and links confirmation_id to the consumed confirmation, but session_id is never explained and the 4096-char bound and optionality of value are left entirely to the schema.

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

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

The description names specific verbs and resources: consuming an interactive_desktop confirmation, reverifying the hovered/focused target, and clicking or entering plain text. This distinguishes it functionally from the other adl_* siblings, though it never names adl_prepare_input or adl_act explicitly, so the pairing/ordering relationship must be inferred.

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?

'Consume an interactive_desktop confirmation once' implies this must follow a prior confirmation-issuing step (presumably adl_prepare_input), which is useful implied usage. However, there is no explicit statement of when to use this vs. adl_act/adl_execute, no preconditions (e.g., what happens if the confirmation is expired or already consumed), and no 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?

With no annotations, the description carries the full burden: it does disclose two valuable traits — cancellation is supported and partial execution is never rolled back. However, it says nothing about permissions, what happens on revision conflict, or what handle the call returns to poll on adl_task.

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

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

Two tight sentences with the key constraint and the rollback caveat front-loaded and nothing redundant. It is arguably too terse for the underlying complexity, but there is no wasted wording.

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

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

For a mutation tool with a nested 8-action step schema, a required optimistic-concurrency parameter, no annotations, and no output schema, the description is materially incomplete — an agent cannot infer how expected_revisions must be formed or what constitutes a failed step.

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 schema is deeply nested. The description conveys only the maxItems=20 limit on 'steps' and explains nothing about the required 'expected_revisions' map or the action/session_id/expected_revision fields that determine whether a step succeeds or aborts the batch.

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: 'Start a cancellable batch of up to 20 steps.' The word 'batch' implicitly contrasts with the singular adl_act sibling, though no sibling is named explicitly.

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

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

Gives a concrete follow-up workflow ('Poll adl_task') and implies batching semantics, but never says when to prefer adl_execute over adl_act or adl_wait, nor what preconditions must hold before starting a batch.

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

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

With no annotations, the description carries the disclosure burden and does so well: frame freshness bound (max 5s), optimistic-concurrency revision, point-count and timing constraints, pre/mid-motion safety checks, and the return contract (released-input acknowledgement plus fresh PNG, with application success explicitly not inferred). It stops short of permissions/auth and failure/error semantics, which keeps it below a 5.

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

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

Purpose is correctly front-loaded in the first clause and no sentence is purely filler. But the text is telegraphic and compressed to the point of ambiguity — 'age5s', 'and2–64', 'first0' — which costs readability on constraints an agent must parse exactly.

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

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

This is a high-complexity, 7-parameter, no-annotation, no-output-schema tool, and the description still covers preconditions, timing/point constraints, staleness rules, and the shape of the response. The remaining gaps are session/surface identity scope and error behavior, which are meaningful but secondary.

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

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

Schema coverage is 0%, so the description must do the work. It adds real meaning for frame_id (latest, max age 5s), expected_revision, and the points array (2–64 CSS/window-pixel samples, t_ms starting at 0 and increasing with total <=5000). But session_id, surface_id, and swipe_backend are left entirely to the schema, leaving roughly half the parameters unexplained.

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

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

States a specific action pair (drag/swipe) against a defined resource (a trusted surface), and the kind enum is echoed in prose so the agent knows the two modes. It differentiates context (browser vs interactive_desktop, scroll_swipe vs touch_swipe) but never names a sibling tool, so sibling disambiguation is only partial.

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 explains backend choice (isolated mouse/genuine touch vs physical OS input, scroll vs touch swipe) and lists preconditions (target/focus/human-input checks), which implies when the call is valid. However it never says when to prefer this over adl_act, adl_execute or adl_prepare/commit_input, so the agent gets no explicit sibling routing.

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

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

Beyond the readOnlyHint annotation, it discloses a real behavioral trait: oversized option lists are dropped and signalled via options_truncated:true while control identity/state is preserved. It also adds a security-relevant instruction to treat page text as untrusted data. It omits cursor pagination behavior, which the schema parameter implies but the description never mentions.

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 no filler; the core capability is front-loaded before the truncation/recovery detail. The density of internal jargon (options_truncated, token_budget, id:<element_id>) costs some clarity but each clause carries information.

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

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

For an 8-parameter, no-output-schema tool with only a readOnlyHint annotation, the description covers truncation and safety well but says nothing about the shape of a successful response, cursor paging semantics, or what delta/since_revision do. An agent can call it, but cannot predict the payload structure from the description alone.

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 25% schema description coverage, the description carries much of the burden and does add meaning: the non-obvious 'id:<element_id>' syntax for scope appears nowhere in the schema, and it explains the tradeoff between token_budget and the include list. It leaves depth, cursor, since_revision, and session_id unaddressed, so the coverage is partial rather than 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 clause names a specific verb and resource ('Return ... semantic UI') and immediately qualifies it as bounded and redacted, which tells an agent this is a state-observation tool rather than a screenshot or action tool. It does not name a sibling such as adl_capture explicitly, so the differentiation is inferable rather than stated.

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

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

The description gives a recovery path when output is truncated ('reobserve scope id:<element_id> with a larger token_budget, or omit options via include'), which is genuine conditional guidance. However, it never states the general case for choosing this tool over adl_capture or adl_act, so the primary when-to-use decision is left implicit.

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

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

With no annotations, the description carries the full burden and does substantial work: origin/network grants gate URL opens, interactive_desktop shares the human pointer and keyboard, physical OS input needs trusted opt-in plus an exclusive input lease, and strict isolation fails closed. It omits failure modes, return values, and whether an open is reversible.

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 subsequent sentences each add a distinct constraint rather than restating. The closing sentence, 'Desktop strict isolation fails closed,' is terse to the point of being cryptic, which costs a point.

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

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

For a 3-parameter, zero-annotation, no-output-schema tool, the description covers the permission and safety model well but leaves an agent guessing about what an open returns (a handle? a target_id?), what happens on a denied or failed open, and how to choose between url and target_id.

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

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

Schema coverage is 0%, so the description must compensate, and it partially does by explaining the behavioral meaning of two mode values (background_semantic, interactive_desktop) plus strict isolation. But target_id is never explained beyond the word 'permitted', and nothing clarifies the url-vs-target_id relationship or precedence when neither is marked 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?

States a specific verb and dual resource: 'Open a permitted target_id or HTTP(S) URL.' This clearly distinguishes the open-from-handle case from the open-a-URL case. It does not differentiate itself from siblings like adl_app or adl_act, which also act on targets, 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?

Gives concrete routing advice – 'Use background_semantic for desktop work alongside a human' – and an explicit prohibition: 'Never switch to interactive_desktop to work around a failed semantic action.' That is real when/when-not guidance. It does not say when to prefer this over sibling tools such as adl_app, so it is not fully exhaustive.

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

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

With no annotations, the description carries the full burden and does well: it discloses the pointer-move side effect (no click), the one-shot confirmation with a <=30s validity window, and that target/focus/geometry/human input are revalidated at commit. It does not cover failure modes (expired confirmation, pointer landing on wrong element) or whether moving the real pointer interferes with a user's session.

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

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

Front-loaded with the action and side-effect constraint, then returns, then workflow. Dense but nearly every clause carries information; minor jargon like 'source-image point' could be 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 7-param tool with no output schema, the description usefully enumerates return contents (role/name, pointer hit, keyboard focus, confirmation token, optional crop) and the commit interaction. The remaining gap is the undocumented required parameters, which an agent must infer from the schema alone.

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

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

Schema coverage is 0% across 7 parameters. The description adds meaning only for point (source-image coordinates) and include_image (returns a fresh surrounding crop), and hints at expected_target via 'target... checked again at commit'. The five required params session_id, frame_id, expected_revision, action and expected_target are otherwise 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 specific verbs and resource: inspect the control at a source-image point and move the real pointer onto it without clicking. It explicitly distinguishes itself from the sibling adl_commit_input, so an agent can tell prepare from commit without opening either schema.

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

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

The last sentence gives clear ordering: 'Check this observation before adl_commit_input', establishing the prepare→commit workflow. It doesn't name explicit exclusions or say when not to prepare, but the sequencing context is strong.

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?

Beyond the single readOnlyHint annotation, the description discloses substantial behavior: hard caps of 6 seconds and 6 MiB, a 2–16 frame sampling range, no audio, unobserved gaps between samples, and that output is untrusted content. These are exactly the caveats an agent needs before invoking a capture tool.

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

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

Six short clauses with no filler; the core action and its hard limits come first, followed by the caveats about sampling gaps and untrusted content. Every sentence carries distinct information.

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

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

No output schema exists, and the description does step up by saying frames come with timestamps as PNG and are addressable by frame_id for later cropping. That covers most of the return-value burden; only the resolution/size parameters remain unexplained.

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

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

Schema description coverage is 0%, so the description must compensate. It conveys the frame_count range ("2–16") and the aggregate 6-second window that bounds interval_ms, but max_pixels, max_dimension, and session_id get no explanation, and 'frame_id' refers to a downstream artifact, not an input parameter.

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

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

The description opens with a specific verb and resource: "Sample 2–16 actual rendered frames with timestamps," and quantifies output (6 MiB PNG). It is clear what the tool does, but it never distinguishes the purpose from sibling tools like adl_capture or adl_observe, so an agent still needs to infer which sibling to pick.

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?

"Works on permitted browser/window capture targets" gives a precondition, but the description never says when to choose this over adl_capture or adl_observe, nor does it state when not to use it. Usage is implied rather than directed.

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 readOnlyHint annotation already covers the safety profile, and the description adds a useful behavioral constraint that results come only from trusted local configuration. However, it does not explain whether the lookup is purely local, what happens when no targets are allowed, or any return behavior.

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

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

The single sentence is front-loaded and free of redundancy, but its terseness leaves key terms like 'targets' and 'trusted local configuration' unexplained.

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 one optional enum parameter and no output schema, the description should clarify what targets are, how 'surface' affects results, and how this differs from related adl_* listing tools. It does none of these, so an agent would need to infer too much.

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

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

There is one optional parameter, 'surface' with enum values browser/desktop, but schema description coverage is 0% and the description never mentions the parameter. It therefore does not compensate for the schema gap or clarify what choosing a surface changes.

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 verb ('List') and resource ('targets') plus a filtering scope, but 'targets' is left undefined and it does not distinguish this tool from siblings like adl_applications or adl_capabilities.

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 the results are restricted to trusted local configuration, but gives no explicit guidance on when to use this tool versus adl_applications, adl_capabilities, or adl_app, and no exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: cancellation can interrupt a running wait. It says nothing about whether cancel is idempotent or reversible, what status reports, or how long tasks persist, which are the gaps that matter for a mutation path.

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

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

Two short sentences with no filler, and the destructive caveat is placed second where it is noticed. It is arguably too terse rather than too long, which is an under-specification issue better captured elsewhere.

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

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

No annotations, no output schema, and zero parameter descriptions; the description supplies only a one-line purpose and one caveat. For a tool whose required task_id must be obtained from elsewhere and whose status output is undefined, an agent is left guessing about the lifecycle and return shape.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly maps 'inspect progress' to command=status and 'cancel' to command=cancel, which is useful for the enum, but it never explains where task_id comes from or its format, leaving the required parameter unexplained 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 specific verb pair (inspect progress / cancel) on a specific resource (a task), and the enum values in the schema confirm the two modes. It does not differentiate itself from siblings like adl_wait or adl_execute, which likely produce the tasks this tool inspects, so an agent cannot fully place it in the workflow.

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 by the two verbs: use it to check on or cancel a task. There is no guidance on when a task exists, which sibling creates one, or when to poll status versus use adl_wait, and 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that the wait is bounded, but it does not explain what happens on timeout, whether the tool polls, or what result is returned when the condition is met, which is critical because there is no output schema.

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

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

The description is a single front-loaded sentence with no filler. Its brevity is efficient, though for a tool with a nested condition object it borders on under-specification rather than well-judged concision.

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 three required parameters, a nested condition object, 0% schema description coverage, and no output schema, one sentence is not enough. It omits condition semantics, timeout outcome, session handling, and return behavior, so the agent cannot invoke it reliably without guessing.

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

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

Schema description coverage is 0%, so the description must carry the burden. It vaguely maps 'semantic condition' to the condition parameter and 'bounded deadline' to timeout_ms, but it never explains session_id or the nested condition fields (name, role, state, element_id), leaving most parameter meaning 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 verb and resource ('Wait for a semantic condition') with a deadline qualifier, so it is not a tautology. However, 'semantic condition' is left undefined and the description does not distinguish this from siblings like adl_observe or adl_act, leaving the agent to infer the use case.

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

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

There is no explicit guidance on when to use this tool instead of polling with adl_observe, nor any exclusions or prerequisites. The phrase 'bounded deadline' hints at a blocking wait, but the agent must infer when that is preferable.

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