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

With no annotations, the description carries the full burden and does so: it discloses generation-safe fail-closed behavior, the provider-specific routing rules (paired-page vs native), that DOM errors never use native/coordinate fallback, the fallback chain, and the route values returned. This is unusually rich 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?

Dense but front-loaded: the core action and its scoping constraint lead, followed by safety and routing details. Every sentence carries information, though the density is high and slightly demanding, keeping it just below ideal 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?

Despite no output schema, the description explains the result format (route=chrome_extension|ax|uia|web_dom|element_center) and the post-call requirement to rerun ax_read. For a tool this complex, the agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents all three parameters including the background fallback-only note. The description reinforces that snapshot_id is ephemeral/immediately-preceding and node_id must be actionable, but adds little beyond the schema's own descriptions.

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 ('Activate one actionable node from the immediately preceding ax_read') and scopes it with the required snapshot_id and node_id. It is clearly distinguishable from siblings like ax_click and chrome_activate, which do not have the generation-safety constraint.

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 context: activation must follow an immediately preceding ax_read, and the agent must 'rerun ax_read after any result' because an accepted token consumes the generation. It does not explicitly contrast with ax_click or ax_focus (click vs activate), so it falls short of full when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden and does well: no coordinates, no cursor movement, app need not be frontmost, and ambiguous matches fail closed. It does not mention required accessibility permissions or what a successful call returns/reports, which are meaningful remaining gaps for a UI-automation 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?

Three tight sentences, front-loaded with the mechanism and the key routing warning; each sentence carries distinct information (mechanism, matching semantics, failure mode, alternative). Dense with backticked identifiers 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 one-parameter, no-output-schema tool with no annotations, the description covers mechanism, matching semantics, failure behavior, and sibling routing. The main omission is any hint of the return value or post-action confirmation, minor given the absence of an output schema.

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

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

Schema description coverage is 100% and the single parameter is already fully documented in the schema. The description restates the matching rule and adds the useful 'ambiguous matches fail closed' constraint, but contributes little parameter detail beyond the schema, so baseline 3 applies.

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

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

States a specific action (click/query against an element) and the underlying mechanism (macOS Accessibility / Windows UI Automation), and explicitly names the preferred alternatives (ax_read + ax_activate). The phrase 'legacy query action' is slightly loose about what the action does (a click), but the surrounding sentences make the semantics clear.

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 clear negative directive — prefer fresh ax_read + ax_activate for exact, generation-safe actions — which frames this as the legacy fallback path. It also notes when it is appropriate (background operation, no coordinates/cursor). No explicit statement of when the legacy path is the *only* option, but the routing intent is unambiguous.

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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose non-obvious traits: background execution, no cursor movement, and fail-closed behavior on ambiguous matches. It omits permission/accessibility-authorization requirements and what a successful 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?

Three tight clauses, front-loaded with what the tool does, then side-effect profile, then the alternative recommendation. No filler, though 'Legacy' is somewhat imprecise about what it supersedes.

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 action, side effects, and failure mode adequately but leaves the return value and authorization/permission needs unspecified — the latter being genuinely relevant for OS accessibility APIs.

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

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

Schema coverage is 100%, so the single 'query' parameter is already fully documented as a case-insensitive substring. The description's 'ambiguous substring matches fail closed' adds a small amount of resolution semantics beyond the schema, but the baseline of 3 is appropriate.

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

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

States a specific verb and resource (focuses a control) plus the platform mechanism (macOS Accessibility / Windows UI Automation). The word 'Legacy' and the pointer to ax_read differentiate it from sibling focus/activate tools, though it doesn't explicitly compare against ax_activate or ax_click.

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 clear routing rule — 'prefer a fresh ax_read node whenever possible' — which steers the agent toward an alternative, and 'Legacy' implies a fallback status. It stops short of stating explicit preconditions (e.g., when focusing is actually required vs. activating).

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 delivers: no screenshot is taken, page (paired_page) failures never fall back to native or pixel paths, coverage/fallback status is reported explicitly, and permission_denied requires granting Accessibility. It also discloses the ephemeral snapshot_id and the deterministic node-id model that downstream ax_activate depends on.

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 information-dense with little waste, but it is a long unparagraphed block and the opening sentence ('Canonical ax:read capability') is low-value. Several clauses duplicate schema-level detail rather than adding new guidance, so structure and conciseness are only adequate.

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

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

There is no output schema, so the description must describe returns, and it does: ephemeral snapshot_id, deterministic node ids, role/name/description/value/actions/state, optional global-logical bounds, coverage/fallback status, and actionable marks. For a 6-parameter, zero-required, read tool this is complete enough to call correctly.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description reinforces key semantics (target=native default, paired_page mutually exclusive with window, mode=all default) but mostly restates what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource (reads visible semantic UI via macOS Accessibility / Windows UI Automation) and distinguishes itself from screenshot-based and Chrome-document reading paths (target=paired_page vs native). The opener 'Canonical ax:read capability' restates the name, but the rest pins down exactly what is read and how. It does not explicitly differentiate from close siblings like read_ui or dump_ax, 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 clear operational guidance: call ax_activate(snapshot_id,node_id) on a fresh actionable node, use focused OCR when coverage is absent/partial, then screenshot/zoom only for visual-only pixels, and treat permission_denied as a grant-Accessibility signal rather than masking it with a screenshot. These are strong when-to-use and sequencing rules. It omits explicit routing against sibling readers (read_ui, dump_ax, chrome_read), which keeps it from a 5.

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

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

With no annotations, the description carries the full burden and delivers useful traits: background execution, no cursor movement, legacy status, and fail-closed behavior on ambiguous substring matches. It omits permission requirements and what a successful/partial set reports.

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 the operation, its safety behavior, and the alternative all front-loaded; no filler. The closing advisory is slightly terse but earns its place.

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

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

For a no-annotation, no-output-schema mutation tool, the description covers mechanism, side-effect profile, and failure semantics well. It could still say more about permissions and post-condition reporting, but nothing critical 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 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining that ambiguous substring matches against `query` fail closed rather than picking arbitrarily.

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 (sets) and resource (a control value) plus the underlying mechanism (macOS Accessibility / Windows UI Automation). 'Legacy query action' and the reference to ax_read make it distinguishable from the many sibling click/read/type tools.

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

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

Explicitly steers the agent away from this tool in favor of 'a fresh ax_read node whenever possible,' signaling a deprecation/preference order. It stops short of spelling out the conditions under which this legacy path is still required.

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?

No annotations are provided, so the description bears the full behavioral burden. It discloses critical traits: at most 64 actions, stop-at-first-failure semantics, returned fields (completed indices/results, failed_index/reason, not_executed range), possible partial side effects, and no retry or rollback. This is unusually rich and directly useful for safe invocation.

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 front-loaded with the core purpose and constraints, then proceeds to failure behavior and retry guidance. It is dense but every sentence adds information; no obvious padding. A minor reordering or break could improve scanability, but 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 complex batch tool with no output schema and no annotations, the description is remarkably complete. It explains what happens on failure, what is returned, and how to verify results before retrying. An agent has enough context to call and recover from 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 100%, and the schema already documents the actions array, its maxItems limit, and the BatchAction variants. The description repeats the max of 64 and the action list, and adds that coordinates are in screenshot space, but this largely duplicates structured data. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb ('Execute a sequence of input actions'), lists the exact action types, and gives the core purpose ('in one call to reduce round-trips, at most 64 actions'). This clearly distinguishes batch_actions from the individual action siblings like left_click, mouse_move, and type_text that it aggregates.

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 provides clear context for use ('in one call to reduce round-trips') and post-failure guidance ('Get fresh ax_read state before deciding what to retry; use a screenshot for visual outcomes'). It does not explicitly state when not to use it (e.g., for a single action) or compare directly to the individual tools, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden and does so well: it declares fail-closed behavior on stale snapshot, route, capability, or DOM identity, and forbids coordinate fallback. It stops short of describing what activation actually performs (click/keypress) or any return/confirmation signal.

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 with zero waste; the core action is front-loaded and the failure/prohibition constraints follow immediately.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the definition covers preconditions, failure modes, and the prohibited alternative. The remaining gap is what a successful activation returns or how success is confirmed.

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

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

Schema description coverage is 100%, so snapshot_id's ephemeral/perishable nature and node_id's snapshot-local exactness are already documented in the schema. The description reinforces these constraints but adds no syntax or format detail beyond the schema.

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

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

States a specific verb (activate) and a precisely scoped resource: one exact actionable node from the immediately preceding chrome_read snapshot. The chrome_read lineage separates it from the ax_* family, though no sibling is explicitly named as an alternative.

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 clear precondition ('immediately preceding chrome_read snapshot') and an explicit exclusion ('coordinate fallback is forbidden'), which routes the agent away from coordinate-based tools like left_click. It does not directly compare against ax_activate, but the context is unambiguous.

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. 'Fails closed instead of guessing or clicking' is a genuinely useful disclosure that there is no implicit fallback and no synthetic click, but it says nothing about the visible effect of focusing (keyboard focus movement), permission requirements, or the failure signal returned.

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

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

Two short sentences, front-loaded with the action and target, with the failure policy second. 'Guessing or clicking' is slightly redundant with 'fails closed', keeping it just under maximum efficiency.

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-required-parameter, fully documented schema with no output schema, the description supplies what the structured fields don't: the prior-call dependency and the fail-closed policy. Only the observable effect of a successful focus is left 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 coverage is 100%, so both node_id and snapshot_id are already documented in the schema. The description restates the snapshot lineage ('immediately preceding chrome_read') and the node constraint ('focus-capable') but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (focus) and resource (one exact focus-capable node) and scopes it to a node from the immediately preceding chrome_read snapshot, which separates it from the AX-family sibling ax_focus. It does not name an alternative explicitly, but the chrome_read lineage plus the 'focus-capable' qualifier make the target 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?

Gives a concrete precondition: the node must come from the immediately preceding chrome_read snapshot, implying chrome_read is a required prior call. No exclusions or named alternatives (e.g. when to prefer ax_focus) are provided, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and delivers: a 30-second expiry window, the required human-in-the-loop confirmation step, the exact binding scope (tab, documentId, page nonce, new epoch), and an explicit negative guarantee that it never grants access to another tab or later navigation. That is unusually rich behavioral disclosure for a session-establishing 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?

Two sentences, front-loaded with the action and its time bound, followed by the confirmation requirement and binding guarantees. Every clause adds a fact an agent needs; there is no padding.

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 explains what success means, but it does not say how to detect failure or timeout, or what the agent should call next (e.g., chrome_status) while waiting for the user to click Pair. Those gaps keep it from a 5.

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

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

The tool takes zero parameters and the schema is trivially complete, so baseline 4 applies. Nothing in the description is needed to clarify 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?

States a specific verb+resource: 'Begin an explicit 30-second pairing request for the active Chrome page.' This is clearly distinct from siblings like chrome_activate or chrome_read, though the description never names an alternative to route against, 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 clear context and a prerequisite workflow: the request only succeeds after the user inspects the origin and clicks Pair in the Nova extension popup. It does not state when not to use it or which sibling to use instead (e.g., chrome_status to poll for completion), so no exclusions are covered.

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 so well: it discloses that output is bounded, that sensitive fields and invalid/presentation ARIA nodes are filtered, that the snapshotId is ephemeral, and that exact nodeIds are returned for use by mutations. It omits auth/permission requirements and any rate or freshness caveats, 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?

Three front-loaded sentences that move cleanly from what it reads, to exclusions, to return value plus usage. Tight and well-ordered, with only mild redundancy in the closing screenshot/coordinates disclaimer.

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, but the description compensates by naming the returned values (ephemeral snapshotId and nodeIds) and the filtering behavior. Combined with 100% schema coverage on both parameters, an agent has nearly everything needed, though permission/error behavior remains unstated.

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

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

Schema description coverage is 100%, so max_chars and max_nodes (including defaults and hard caps) are already fully documented in the schema. The description only echoes the notion of boundedness without adding syntax or interaction detail, so the baseline 3 applies.

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

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

States a specific verb (Read) and resource (bounded semantic DOM snapshot from the exact paired Chrome document), and the 'No screenshot or coordinates are used' clause distinguishes it from screenshot/ocr/click_mark siblings. An agent can tell it apart from ax_read and the visual tools 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?

Gives an explicit when-to-use directive: 'run this immediately before every Chrome mutation', which is strong operational guidance. It does not, however, name sibling alternatives or state exclusion conditions (e.g. when to prefer ax_read or chrome_status), so it stops short of a full when/when-not treatment.

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 behavioral burden. It does disclose real consequences by naming what gets revoked (epoch, in-flight requests, receipts), which is useful side-effect information. But it omits error behavior if nothing is paired, idempotency, and the resulting state, leaving notable gaps.

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 begins with the action verb and the target, with no padding. It is slightly dense with undefined domain jargon, but every clause contributes to describing the operation.

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

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

For a zero-parameter tool with no output schema, the description covers what the operation does and what it revokes. It stops short of covering preconditions (is a pairing required?), failure cases, or whether the call is idempotent, which for an unannotated tool leaves meaningful context 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no arguments are needed by operating only on the 'currently paired' document, so there is no parameter semantics gap to fill.

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 (release) and a clearly bounded resource (the currently paired Chrome document), and the term 'paired' implicitly distinguishes it from the sibling chrome_pair. However, the jargon 'epoch,' 'in-flight requests,' and 'unexpired receipts' is not explained, which slightly muddies what is actually being released.

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

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

The word 'Explicitly' hints that this is a manual counterpart to some implicit release, but the description never states when an agent should call this versus leaving pairing to lapse. It does not name chrome_pair or any sibling as the alternative action, so usage 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?

With no annotations, the description carries the full burden. It usefully discloses that the snapshot_id is ephemeral and must come from the immediately preceding chrome_read, and that it targets a single node, but it says nothing about side effects, what happens on a stale snapshot, or the return value.

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 core action front-loaded and parameter semantics appended; no filler. Slightly dense but every clause earns its place.

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

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

No output schema or annotations exist, so the description should do more. It covers the snapshot dependency and node targeting adequately but omits return behavior and failure modes, leaving an agent with gaps for a 4-required-param mutation-like tool.

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

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

Schema coverage is 50%, with node_id and snapshot_id already documented in the schema. The description restates the direction enum (up/down/left/right) and amount enum (line/half_page/page) in prose, adding little beyond the self-descriptive enums, so it neither compensates for nor worsens 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 (scroll) and resource (one exact scroll-capable node, including root), and the clause 'no coordinates' implicitly separates it from a coordinate-based scroll sibling. An agent can tell what it does, though it never names the alternative tool explicitly.

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

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

The prerequisite 'from the immediately preceding chrome_read snapshot' implies when to use it, and 'no coordinates' implies when to prefer a semantic scroll. However, there is no explicit when/when-not or named alternative, so usage 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?

No annotations are provided, so the description carries the full burden. It discloses meaningful traits: plaintext is never logged or echoed, and success returns only UTF-8 byte length plus SHA-256. It does not state failure modes, permission requirements, or whether the write 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?

Three dense sentences, front-loaded with the action and constraint, with no filler. Slightly compressed but each sentence carries information.

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

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

For a mutation tool with no annotations and no output schema, the description covers the snapshot freshness requirement, control-type exclusions, and the exact return shape (byte length + SHA-256), which is what an agent needs to call and interpret it. Minor gaps remain around error behavior.

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

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

Schema description coverage is 100%, so the schema already documents snapshot_id, node_id, and value. The description reinforces the security property of the value parameter but adds no syntax or format detail beyond the schema, which is the expected baseline.

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 ('Set one exact non-sensitive text control') and scopes the source of the node to a preceding chrome_read snapshot, which distinguishes it from generic siblings like type_text or ax_set_value.

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 states the precondition (value must come from the immediately preceding chrome_read snapshot) and the exclusions (password, payment, OTP, file, hidden, sensitive controls unavailable). It does not name a fallback alternative such as ax_set_value or type_text, so routing knowledge is incomplete.

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 provided, the description carries the full burden and discloses that the call is a non-invasive status check ('never inspects page content') and what two states it reports. However, it says nothing about whether the check blocks/waits, its latency, or side effects, leaving meaningful behavioral gaps for a no-annotation 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?

Two sentences with zero filler. The core purpose is front-loaded and the behavioral caveat follows immediately, making it easy to scan and 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?

For a parameterless status tool with no output schema, the description adequately states what is checked. It could go slightly further by indicating what an agent should do on a negative result (e.g., pairing via chrome_pair), which is the only notable omission.

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 schema baseline of 4 applies and there is nothing further for the description to clarify. No parameter semantics are required or missing.

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 ('Report') and precisely names the resource: whether the Chrome Native Messaging host is connected and whether a top-level document is paired. This clearly distinguishes it from content-reading siblings like chrome_read and control siblings like chrome_focus or chrome_activate.

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 an explicit trigger ('Call this before Chrome semantic work') and a distinguishing negative scope ('it never inspects page content'), which tells the agent when not to rely on it for content. It stops short of naming the specific alternative (e.g., chrome_pair) for remediating a disconnected state, so not a full 5.

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

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

With no annotations, the description carries the full burden and does so well: it explains that web content is clicked through the page's own JS engine, that an Accessibility press is a silent no-op on web content, native controls go through the AX tree, and otherwise it falls back to a center-coordinate click. It also warns that mark numbers go stale when the UI changes.

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 that are front-loaded with the core purpose and the preferred alternative. Every clause conveys operational information, though the mid-sentence branch description is slightly heavy to parse.

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

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

For a 2-parameter tool with no annotations and no output schema, the description covers activation mechanics, fallback behavior, staleness risk, and the recommended alternative. Nothing needed to invoke it correctly 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 100%, so the baseline is 3, but the description adds lifecycle semantics the schema lacks: mark numbers are ephemeral and go stale on UI change, requiring a fresh read. The background-only fallback nuance is left to the schema, which documents it adequately.

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 (activation/click) plus the exact resource it consumes (the mark NUMBER from the most recent ax_read/read_ui or screenshot(marks=true)). It explicitly differentiates itself from the preferred sibling ax_activate, so an agent can route correctly 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?

Gives explicit when-to-use ('Prefer ax_activate with snapshot_id/node_id because it rejects stale generations') and a concrete precondition ('run a fresh ax_read immediately before acting'). The alternative and the reason to choose it are both 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?

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, has side effects, or requires permissions. It only states it returns coordinates.

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?

Very concise single sentence. Could be improved by elaborating on 'logical coordinates' or units, but currently 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 simple, zero-parameter tool, the description adequately states purpose and return value. However, it does not explain 'logical coordinates' or any limitations, leaving minor 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?

No parameters exist, so schema coverage is 100%. The description adds return format information ('Returns (x, y) in logical coordinates'), which is appropriate for a zero-parameter tool. Baseline of 4 is justified.

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

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

The description clearly states the tool gets the current mouse cursor position and returns coordinates. The verb 'Get' and resource 'mouse cursor position' are specific, and it distinguishes from siblings like mouse_move (which sets position).

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 use this tool versus alternatives (e.g., before clicking, after moving). No exclusions or context provided.

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

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

With no annotations, the description carries the full burden. It usefully discloses the coordinate space ('most recent capture's pixel space') that grounds the click, but says nothing about side effects, required permissions, failure when no capture exists, or whether the target window is brought to the foreground by default.

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

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

Two tight sentences with the action and coordinate frame front-loaded, and the parameter routing appended second. 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 mutating input tool with no annotations and no output schema, the description covers the coordinate-grounding model but omits prerequisites (an existing capture), side effects, and failure modes. Adequate but with clear gaps.

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

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

Schema coverage is 50%: source and background are documented in the schema, while x and y are bare numbers. The description partially compensates by framing x/y as living in 'the most recent capture's pixel space' and clarifying the default route, but adds no format or range detail for the coordinates themselves.

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: a double click 'grounded in the most recent capture's pixel space', which is more informative than the bare name. It implicitly distinguishes itself from left_click/right_click by naming the double-click action, but never explicitly contrasts with those siblings.

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

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

Gives conditional guidance for the source parameter ('pass source=ocr_center for an OCR-returned center; otherwise defaults to visual_coordinate'), which is closest to routing guidance. It does not say when to choose this tool over left_click/right_click or what preconditions (a prior capture) must hold.

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 usefully discloses the output shape (indented text) and target resolution ('current AX/UIA app, or frontmost'), but never states that it is a non-mutating/read-only operation or any performance/cost characteristics, leaving the safety profile to inference.

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 prefixed with DEBUG, using the em dash to separate the action from the diagnostic rationale. Every clause earns its place with no filler.

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

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

For a zero-parameter debug tool with no output schema, the description supplies everything an agent needs: what is dumped, what fields it contains, the output format, and which app it resolves to.

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 baseline there is nothing for the description to disambiguate. The mention that it targets the current AX/UIA app or frontmost is a small bonus, but the baseline of 4 applies for a 0-param 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 ('dump') and resource ('target app's Accessibility tree') and enumerates what the dump contains (roles, subroles, labels, actions, frames). The DEBUG framing and diagnosis intent clearly separate it from siblings like ax_read, read_ui, and inspect_app.

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 context for use: diagnose why some elements are not exposed, distinguishing it from normal read/inspect tools. It does not state when NOT to use it (e.g., prefer ax_read for straightforward reading), so no explicit exclusions or named alternatives.

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 so explicitly: it is read-only and enumerates what it will NOT do (no app launch, focus, permission request, page content, browser attachment). It also discloses the return shape, compensating for the absent 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?

Front-loaded with purpose in the first clause, then returns, then constraints, then usage in a single tight block. Dense semicolon-packed clauses are efficient, though slightly heavy for the amount of information conveyed.

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?

Two optional parameters, no annotations, and no output schema, yet the description supplies the missing pieces: what it returns, what it abstains from, and how it relates to ax_read. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented; the description largely restates the omission semantics and the details=true diagnostics rather than adding syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

Specific verb ('Inspect') plus resource ('a running macOS application's interaction options') and an explicit second mode (discover Chromium apps when app is omitted). It names ax_read as the tool for ordinary native interaction, so an agent can separate it from the ax_* and chrome_* siblings without reading 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?

States when to use it ('optionally for setup/discovery') and where the default path lies ('ordinary native interaction still starts with ax_read'), which routes the agent to the correct alternative. Nothing is left to inference about positioning.

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 behavioral burden, yet it never says where the keystrokes are delivered (focused window, active app, or captured process), whether the call blocks until delivery, or whether it fails silently. The examples convey accepted syntax but no runtime behavior.

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

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

A single front-loaded sentence with an inline example pair; nothing is padded. It is efficient, though the brevity leaves the gaps noted in other dimensions.

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 OS-level input tool with no annotations and no output schema, the description should explain delivery target and focus requirements. As written, an agent cannot tell what state the machine must be in for the combination to land 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 coverage is 50%: the 'background' parameter is self-documented, but 'key' is a bare string in the schema. The description's examples ("cmd+c", "shift+tab") supply the chord syntax that the schema omits, adding real value, but it doesn't cover key names or multi-modifier ordering.

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 (simulate) and resource (key combination) and gives two concrete examples, which lets an agent distinguish it from type_text. It doesn't explicitly name the sibling it differs from, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus type_text or batch_actions, and no mention of prerequisites such as the target window needing focus. Usage must be inferred entirely from the name and examples.

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 usefully discloses the operating space ('most recent capture's pixel space') and that the result reports the grounding route, which is real behavioral context. But it says nothing about side effects of a click (focus changes, foreground vs background behavior), failure modes when no capture exists, or permissions.

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

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

Three short sentences, front-loaded with the core action and operating space before the parameter-routing guidance. Efficient, though the source explanation is dense and partly duplicates the 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 4-parameter, no-annotation, no-output-schema action tool, the definition covers purpose, grounding source, and route reporting, but omits background behavior, click side effects, and what happens when no capture is available. Adequate but with clear gaps.

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

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

Schema coverage is 50%. The description explains source=ocr_center vs source=visual_coordinate, but that largely mirrors the schema's own source description, so it adds little beyond structured data. It adds no meaning for x/y (undocumented in both) and does not touch the background parameter, 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?

States a specific verb and resource: a left click executed in the most recent capture's pixel space, with the 'last-resort/grounded' framing signaling it is a fallback rather than a primary interaction. It implicitly separates itself from sibling ax_click/click_mark/chrome_* tools, but never names them, so the differentiation is inferred rather than explicit.

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?

'Last-resort' gives clear ordering context (use only when other interaction paths fail), and the source guidance tells the agent how to pick the correct grounding route. However, no alternatives are named (e.g. ax_click, click_mark, chrome_click) and there is no explicit when-not condition.

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 provided, the description carries full burden. It only states the tool lists installed applications, revealing no side effects, security implications, or performance characteristics. For a read-only listing, this is minimally adequate but lacks detail.

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 concise sentence that efficiently communicates the tool's purpose without unnecessary words or structure issues.

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

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

Given no parameters, no output schema, and low complexity, the description is mostly complete. However, it omits what format the list returns (e.g., names only, objects), which could be clarified. Still sufficient for a simple list command.

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

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

The tool has no parameters, and the schema coverage is 100% (empty schema). The description adds no parameter information because none is needed. Baseline 4 is appropriate as the description does not need to compensate for missing schema details.

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

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

The description clearly states the action 'list' and the resource 'all installed applications on the system', making the purpose immediately obvious. It is distinct from sibling tools like 'open_application' or 'list_windows'.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving installed apps, but does not mention when not to use it or suggest alternatives for related tasks.

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?

No annotations are provided, and the description does not disclose behavioral traits like read-only nature, speed, or permissions. It only states the basic function.

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 sentence with no wasteful content, efficiently conveying the tool's purpose.

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 parameterless tool with no output schema, the description adequately covers the core function. However, it could mention that the tool returns a list of window identifiers or details.

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?

No parameters exist, and schema coverage is 100%. The description does not add extra semantics but is sufficient given the absence of parameters.

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

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

The description clearly states the tool lists all visible windows across all applications, with a specific verb and resource, distinguishing it from sibling tools like list_applications.

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 is provided on when to use this tool versus alternatives such as list_applications or click tools, nor any context on prerequisites or limitations.

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 behavioral burden, and it discloses only that coordinates are in screenshot space. It says nothing about side effects (hover triggers, focus changes), whether the move is instantaneous or animated, permission requirements, or 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?

A single compact sentence with the key scoping detail ('in screenshot space') placed where it is read, and no wasted words.

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

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

For a simple two-parameter, no-output-schema tool this is close to sufficient, but the coordinate frame is only loosely pinned down (no origin, no relation to screenshot resolution). An agent could call it but might mis-target if the screenshot was scaled.

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; it does define both x and y as coordinates in screenshot space, which is real added meaning. However it omits origin corner, units, and whether values relate to the screenshot's pixel dimensions or the live screen, leaving the semantics partial.

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

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

States a specific verb and resource ('Move the mouse cursor') plus the coordinate target, and adds the important qualifier 'in screenshot space'. It does not differentiate itself from siblings like click_mark or left_click that also position the cursor, so it falls short of a 5.

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

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

There is no guidance on when to use this versus alternatives such as click_mark, left_click, or ax_activate, and no stated prerequisites. The reader must infer usage entirely from the verb.

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 return shape (text lines with clickable centers in screenshot pixel space), that no image is returned, the cheap/fast tradeoff, and the ROI re-capture path. It omits operational caveats like required screen-capture permissions and failure/error behavior, so it stops 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?

Purpose and the cost/return profile are front-loaded, and the sentences are dense with operational detail. It runs long as a single block and repeats some schema content, but nearly every clause adds actionable information.

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

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

Despite no output schema, the description explains exactly what comes back (recognized lines with clickable centers usable via left_click) plus engine selection, modality, and param interactions. An agent has everything needed to call it and use the result 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: the roi/window mutual exclusion, the strict validation and native re-capture of roi (never cropped from a downscaled JPEG), the auto/fast/accurate fallback policy, and the default language pair.

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 on-screen TEXT via the platform OCR engine') and immediately names the concrete engines. It also distinguishes itself from siblings by declaring it returns text only and routes UI-tree cases to ax_read + ax_activate.

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 explicit when-to-use ('after ax_read reports absent/partial coverage', canvas/games/image-rendered views, bulk text grabbing) and explicit when-not-to ('For native/web UI with an Accessibility/UIA tree, ax_read + ax_activate is still more precise'). Alternatives and selection conditions are both present.

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?

No annotations are present, so the description bears the full burden; it does disclose the meaningful launch-or-focus semantics (idempotent behavior). But it says nothing about behavior on an unknown app name, whether it blocks until the app is ready, permission requirements (e.g., accessibility/automation), or failure modes.

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

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

A single tight sentence with the action front-loaded and examples appended; every element earns its place with no filler.

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

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

For a one-parameter, no-output-schema tool this is close to minimally sufficient to invoke correctly. It still leaves the agent guessing about error behavior and name-matching rules, which matters for a launch action whose failure mode is user-visible.

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 single param has 0% schema description coverage, so the description must compensate; the inline examples ('Safari', 'Slack') usefully clarify that the parameter is a human-readable app name. It does not address case sensitivity, exact-name matching, or what identifier forms are accepted.

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 (launch/focus) plus the resource (application) and the argument format ('by name'). It is clearly distinguishable from siblings like list_applications and inspect_app by virtue of being an action, though it never explicitly contrasts itself with app-specific activators such as chrome_activate or ax_activate.

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

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

The phrase 'launch or focus' implicitly signals this is safe to call whether or not the app is already running, which is useful usage context. However, it names no alternatives and gives no when-not guidance, so an agent facing chrome_activate / chrome_focus / ax_focus siblings gets no routing help.

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 burden. 'Read' implies non-destructive, and the simplicity of the tool (no parameters) makes additional disclosure unnecessary. The description is adequate.

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

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

The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded.

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

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

For a simple, parameterless tool with no output schema, the description fully covers the intended behavior. No additional context is required.

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 are zero parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline score of 4 applies.

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

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

The description uses a specific verb ('Read') and resource ('system clipboard contents'), and specifies the format ('as text'). It clearly distinguishes from the sibling 'write_clipboard'.

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?

While the purpose is clear, the description does not provide explicit guidance on when to use this tool versus alternatives, such as noting it is safe for reading without side effects.

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 disclosure burden, and it does add real value by guaranteeing behavioral equivalence to ax_read including the shared action cache. It does not mention safety profile (read-only vs mutating), side effects such as resetting the 'current target app' state implied by the window/target params, or output shape, leaving meaningful behavioral gaps.

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, zero padding, and the most important information (it is an alias for ax_read) is front-loaded before the migration advice.

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 pure alias whose behavior is fully delegated to a named sibling and whose parameters are 100% documented in-schema, the description covers what an agent needs to select and call it. The absence of any return-value or side-effect note is a minor gap with no output schema present to compensate.

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

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

Schema description coverage is 100% across all six parameters, with detailed inline docs for max, mode, filter, target, window, and max_chars. The description adds no parameter meaning beyond that, so the baseline 3 is appropriate.

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

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

The description identifies the tool as a compatibility alias of ax_read and lists what it shares (semantic traversal, renderer, snapshot generation, action cache), which lets an agent equate it with a sibling it likely already knows. However, it never plainly states the verb+resource itself (reading the accessibility/UI tree), so an agent unfamiliar with ax_read gets no direct statement of the 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 explicitly directs the agent to prefer the canonical ax_read name in new prompts and integrations, which functions as a clear when-to-use-this-vs-alternative rule. It stops short of stating the inverse condition (when this alias is actually required, e.g. legacy integrations), but the routing decision is unmistakable.

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 usefully discloses that the click is 'grounded' in the most recent capture's pixel space, a non-obvious behavioral constraint, but it says nothing about side effects (context menu), whether it requires a foreground window, or how it interacts with existing state.

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 core action front-loaded and the source-routing caveat second. No filler, though the second clause is dense and could be marginally easier to parse.

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-param mutation tool with no annotations and no output schema, the definition covers grounding and source routing but omits return behavior, the background-delivery implications, and alternative-selection context. Adequate but with clear gaps.

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

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

Schema coverage is 50%: source and background are well documented in-schema, but x/y carry no schema description. The description partially compensates by establishing that coordinates live in 'the most recent capture's pixel space,' which is essential context for x/y, but gives no format, range, or origin details.

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 ('right click') and scopes it to 'the most recent capture's pixel space,' which clearly separates it from left_click, double_click, and ax_click. It does not explicitly name those siblings, but the action and grounding are 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?

The routing rule for source ('pass source=ocr_center for an OCR-returned center; otherwise defaults to visual_coordinate') is clear, but there is no guidance on when to choose right_click over ax_click, click_mark, or left_click, nor any prerequisite/exclusion context. Usage is implied rather than spelled out.

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 behavioral burden and does so: it discloses the return format (base64 JPEG plus a text note with pixel dimensions), the ~1280px downscale of full-display shots, that marks requires Accessibility permission, that clicks are mapped automatically through the captured image, and that canvas/game surfaces come back empty. This is exactly the kind of context annotations would otherwise supply.

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 tool's role and the preferred argument, and every sentence carries actionable information (coordinate space, downscale, marks default, grid interplay, zoom fallback). It is a single dense block rather than a structured list, which slightly hurts scanability, but there is little waste.

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?

Despite having no output schema and no annotations, the description explains what is returned (image + dimension note), the coordinate space the image defines, the defaults for marks/grid, and the correct sibling tools for adjacent needs. An agent has everything required to call this correctly.

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

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

Schema description coverage is 100%, so the schema already documents grid, marks, and window in depth; the baseline is 3. The description adds the practical rationale behind the defaults (the 'AX-first rule' toggling grid/marks, and why window= beats full-display), which is value beyond the schema, though it largely restates the schema's own descriptions.

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+resource (capture the whole main display or a single window) and immediately positions the tool relative to siblings: 'Visual fallback after ax_read and, for missing rendered text, OCR.' An agent can distinguish it from ax_read, ocr, and click_mark 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?

Explicit routing guidance: use this as a visual fallback after ax_read/OCR, PREFER window=... when working inside one app (with the reason: full-display is downscaled to ~1280px), fall back to zoom_region if a target is still too small, and use marks for semantic controls via click_mark. Both when-to-use and when-not-to-use are covered.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the useful sign convention for lines (positive = up, negative = down), but says nothing about what x/y refer to (screen vs. window coordinates), whether the target must be focused, or what the background flag's 'native apps only' limitation means in practice.

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 core action front-loaded and the sign convention appended; nothing is wasted. It is arguably too terse given the undocumented parameters, but as a conciseness measure 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?

With no annotations, no output schema, and three of four parameters undocumented in the schema, the description should supply more context. It never clarifies the coordinate system, target window handling, or the return/effect of the call, leaving meaningful gaps for a mutation-style input tool.

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

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

Schema coverage is only 25% (background alone is documented), so the description must compensate and it partially does: it explains the sign semantics of lines and frames x/y as a position. It leaves the coordinate space and units for x/y, and their interaction with the target window, undefined.

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 (scroll) and the position at which it occurs, so the action is unambiguous. It does not, however, differentiate itself from the near-identical sibling chrome_scroll, which an agent must distinguish on its own.

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

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

There is no guidance on when to use this tool versus chrome_scroll, chrome_activate, or other input tools, nor any mention of prerequisites or context such as focusing/targeting a window first. Usage is only weakly implied by the description.

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?

No annotations are provided, so the description carries the full behavioral burden. It hints at a precondition ("currently focused element") but never says what happens if no element is focused, whether existing content is replaced or appended, or that accessibility/input permissions may be required. For an input-injection tool this is a substantial gap.

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

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

A single sentence, front-loaded with the verb and target, with no wasted phrasing. It is efficient, though its brevity is achieved by omission rather than precision.

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 annotations, no output schema, and a focus-dependent input action, the description should cover failure modes and preconditions. It covers only the happy path, so an agent cannot predict behavior when focus is absent or when `background` is used with a non-native window.

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 50%: the optional `background` parameter is documented in the schema, but `text` has no schema description and the description only vaguely says "a string of text." It adds essentially nothing beyond the field names, leaving the foreground/background tradeoff (native apps only) unexplained in 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?

It states a specific verb ("Type") and resource ("a string of text") plus the target ("currently focused element"), which is enough to understand the operation. It does not distinguish itself from near-siblings such as ax_set_value, write_clipboard, or key_combo, which an agent must disambiguate on its own.

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 and never mentions alternatives. It does not explain when to prefer typing over ax_set_value or clipboard-based insertion, nor what to do if nothing is focused. With ~30 sibling tools, this omission is significant.

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?

No annotations exist, so the description carries the full burden. It hints at blocking behavior via 'before returning,' which is useful, but does not state whether the call is synchronous, any maximum duration, or consequences of long waits.

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 wasted words. It delivers the essential behavior immediately.

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

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

For a one-parameter, no-output tool this is nearly adequate, but it omits the default value, bounds, and return behavior that an agent would want before invoking a blocking wait.

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 is the only source of meaning for the single 'duration' parameter, and it does supply the unit ('seconds') that the schema omits. However, it does not clarify the default of 1, allowed ranges, or whether fractional values are accepted.

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 (wait) and the resource/unit (seconds), so an agent immediately knows this is a blocking sleep. No sibling does anything similar, so sibling differentiation is unnecessary rather than missing.

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

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

There is no guidance on when to use this versus alternatives (e.g., batch_actions for sequencing, or polling loops). The agent is left to infer that this is a delay primitive with no context about typical use cases.

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 behavioral burden and falls short. It does not say whether the write overwrites or appends to existing clipboard content, what happens on failure or when the clipboard is unavailable, or whether it works in headless/non-native contexts.

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

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

A single short, front-loaded sentence with zero waste. It is efficient, though the brevity edges toward under-specification for a tool with a non-obvious background flag.

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-output-schema tool, the description is minimal but workable. It leaves key behaviors (clipboard replacement semantics, background flag impact from the caller's perspective, failure modes) to inference, which is a modest gap for an operation that mutates shared system state.

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 50%: the background parameter is documented in the schema (background flow / native apps only), but the required text parameter has no description. The description's 'write text' implicitly maps to it but adds no format, length, or encoding detail beyond what the schema already implies.

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

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

The description states a concrete verb+resource pair: write to the system clipboard. It is unambiguous about what the tool does. However, it offers no differentiation from the sibling read_clipboard, so an agent gets no explicit routing signal beyond the obvious naming.

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

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

There is no when-to-use guidance and no mention of alternatives or the sibling read_clipboard. Usage can be inferred from the name, but the description provides nothing explicit about context, prerequisites, or exclusions.

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

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

No annotations exist, so the description carries the full burden and does so richly: only the rectangle is captured (not the whole display), it is smaller/quicker, the returned image becomes the new coordinate space, and subsequent clicks automatically map into the zoomed region. It also discloses the non-obvious defaults (marks off, grid on) and the reason behind them.

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 action and scope constraint are front-loaded, and nearly every sentence earns its place (caveats, defaults, coordinate-space behavior, prerequisite). Minor padding such as 'a sharp, legible magnified view' keeps it from a 5.

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

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

With no output schema and no annotations, the description still explains what the returned image means (new coordinate space, automatic click remapping) and the prerequisite screenshot. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so baseline is 3; the description adds value by framing x/y/width/height as current-image pixel space with width,height > 0 and by explaining the intent behind the grid/marks defaults. It does not add new syntax or ranges beyond the schema, so it stays just above baseline.

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+scope: zoom into a rectangle of the CURRENT image and re-capture at native resolution, distinguishing it from a full-display screenshot in the same sentence. An agent can tell this apart from sibling 'screenshot' 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?

Explicit when-to-use: read exact positions on surfaces that expose no marks (canvas/games, custom-rendered views) before clicking, or to stay scoped within one area. It also names the prerequisite (take a screenshot first) and the trade-off versus a full-display capture.

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