Computer Use

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

Annotations declare non-readOnly, idempotent and non-destructive, but do not convey the user-visible focus steal. The description adds that context ('the window the user was working in loses focus'), which is exactly the behavioral trait annotations miss. It stops short of describing what happens if the app isn't running, but the key side effect is disclosed.

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

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

Two tight sentences, front-loaded with the action, followed by the usage condition and the side effect. No filler or repetition of the title.

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

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

Covers purpose, exclusions, and the main side effect for a small two-parameter tool whose schema is fully documented. Minor gaps: nothing about failure when the app is not running or how activation interacts with multiple displays, but the essentials for correct invocation are present.

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%, including the app identifier format and the Windows-only window_id semantics, so the schema carries the parameter burden. The description adds no parameter detail beyond that, 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 and resource ('Bring an app's windows to the foreground and give it keyboard focus') with the observable effect, and distinguishes itself from the element-id action siblings (click, set_value, type_text, press_key). An agent can tell exactly what this does versus the other input 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 says the tool is NOT needed for type_text, press_key and element-id actions, and gives the positive selection condition: 'use it only when the app itself must be in front.' That is a clear when/when-not with the competing tools named.

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

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

Annotations declare the destructive/non-idempotent/open-world profile, and the description adds genuinely new behavior beyond them: the click works on a background tab, and a click that opens a target=_blank link or popup spawns a new tab discoverable via browser_list_tabs. It does not restate the safety hints, and return_state/wait semantics are left to the schema, so this is strong but not exhaustive.

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 primary locator contract, then the tab/popup behavior, then the caution about side effects. Every sentence carries information, though the description is fairly dense for what is fundamentally a two-mode locator tool.

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

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

For an 8-parameter, no-output-schema action tool this covers the agent-relevant behavior: tab targeting, background-tab support, new-tab side effects, and the snapshot prerequisite. The return_state, wait_for_selector and wait_timeout_ms semantics are handled thoroughly in the schema, so leaving them out of the description is reasonable.

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 baseline is 3, and the description earns an increment by stating the mutual-exclusion rule ('Pass index or x and y, not both') and the preference for index over coordinates, which the property-level descriptions only hint at.

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 ('click') and resource (an element by index from browser_snapshot, or a page coordinate point), and explicitly separates itself from the sibling 'click' tool, which handles native app windows. An agent can distinguish it from right_click, hover, and drag 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 rules: use browser_snapshot first, pass index OR x/y but never both, use click for native windows, and find popups via browser_list_tabs. The 'snapshot first' warning also explains the precondition (clicks can submit forms or follow links), which is exactly the when-to-use context an agent needs.

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?

Goes well beyond the annotations (destructiveHint/idempotentHint): it discloses what is destroyed ('Unsaved state in the agent's tabs is lost'), that taken-over tabs are released rather than closed, and that the MCP process runs the same cleanup automatically at Computer Use session end. That last point materially affects whether the agent should call it at all.

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

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

Four short sentences, front-loaded with the action and each carrying distinct information: scope, the use_tab exception, the recommended call timing, the automatic behavior, and the data-loss warning. No filler.

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

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

With no output schema and a single schema-documented parameter, the description covers everything an agent needs: what is closed, what is not, when to call it, what is lost, and that cleanup may happen automatically. Nothing material is missing.

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

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

Schema description coverage is 100%, so session_id is fully documented in the schema; the description adds nothing about the parameter (e.g. how session scoping interacts with the auto-cleanup at session end). Baseline 3 applies when the schema carries the parameter burden alone.

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 ('Close every tab the agent opened') and precisely bounds scope: agent-opened tabs including those opened by clicks, plus removal of the tab group. This is clearly distinguishable from the single-tab sibling browser_close_tab and from browser_release_tab.

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 trigger ('Call this when finished with the browser') and explains the consequence of not calling it (leftover empty group in the user's tab strip). It also notes the agent does not need to close tabs it merely took over with browser_use_tab, but it never names browser_close_tab as the alternative for closing a single tab.

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

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

The description adds important behavioral context beyond the annotations: it discloses that closing a tab discards unsaved page state, and that tabs taken over with browser_use_tab are released rather than closed because they belong to the user. The annotations already declare destructiveHint=true and idempotentHint=true, and the description aligns with these. It doesn't contradict the annotations, and it adds meaningful context about the tool's side effects.

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

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

The description is three sentences with zero waste. It front-loads the core action and side effect, then provides the sibling distinction and the special case. Every sentence earns its place.

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

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

The description is complete for a destructive tab-closing tool. It covers the core behavior, the side effect (discarding unsaved state), the special case for user-owned tabs, and the alternative for bulk cleanup. The only minor gap is that it doesn't explicitly state what happens if both index and tab_id are provided, but the schema's 'fallback mode only' note covers this. With no output schema, the description doesn't need to explain return values.

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 schema description coverage is 100%, so the schema already documents all three parameters (index, tab_id, session_id). The description doesn't add much beyond what the schema provides, but it does clarify the fallback relationship between index and tab_id ('fallback mode only, when tab_id is unavailable'). This is a baseline 3 because the schema carries 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 clearly states the tool's function: closing one of the agent's tabs and discarding unsaved page state. It also distinguishes itself from the sibling tool browser_close_all_tabs, which is for cleaning up everything at the end of a task. The verb 'close' and resource 'tab' are specific and 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 description explicitly states when to use this tool versus alternatives: use browser_close_all_tabs to clean up everything at the end of a task. It also clarifies the special case of tabs taken over with browser_use_tab, which should be released rather than closed. This is clear, actionable guidance for an agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces 'Read-only'. It adds meaningful behavioral context beyond annotations: the agent's own tab group is the default scope, all=true expands to every tab, the active tab is marked, and the returned tab_id is needed by other browser tools.

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

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

Three sentences with no filler. The core behavior is front-loaded, the all=true variant is explained exactly where needed, and the safety note is appended last. Every sentence earns its place.

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

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

For a read-only listing tool with no output schema, the description adequately conveys the key returned data (tab list, active marker, tab_id) and the parameter behavior that matters for invocation. It could be slightly richer about the exact output shape, but nothing critical is missing for selecting and calling the 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 coverage is 100%, so the schema already documents both parameters. The description adds prose meaning for all ('Pass all=true to see every tab...') but does not discuss session_id beyond what the schema provides. This matches the baseline for fully documented 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 uses a specific verb and resource: 'List the tabs in the agent's own Chrome tab group', and clarifies the output includes active marking and tab_id. This clearly distinguishes it from sibling tools like browser_snapshot or browser_select_tab while positioning it as the listing companion to browser_use_tab.

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 concrete guidance on when to use all=true (to see the user's tabs and pick one to drive with browser_use_tab) and clarifies the default scope. It does not explicitly state when not to use the tool, but the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description still adds non-obvious behavior beyond the annotations: unsaved page state is lost, and element indices from prior snapshots are invalidated — a real trap that would otherwise cause stale-index clicks.

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, zero waste, front-loaded with the destructive semantics before the alternative and the follow-up advice. Every clause carries information an agent would otherwise have to discover by failure.

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 return_state parameter description already explains what comes back (snapshot plus readiness status) and the description routes the agent to browser_snapshot afterward, which covers the practical return-value question. Minor gap: nothing about authentication or credential prompts, which a sibling (browser_request_credentials) implies can occur.

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 tab_id, url, session_id, return_state, wait_timeout_ms and wait_for_selector are all documented in the schema itself. The description adds no syntax or format detail beyond implying that navigation invalidates snapshot indices, 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?

Names a specific verb (navigate/point) and resource (one of the agent's tabs) and states the scope constraint 'replacing the current page'. It distinguishes itself from the closest sibling by naming browser_open_tab as the non-replacing alternative, so an agent can choose 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-the-alternative guidance: 'Use browser_open_tab to keep the current page and open another.' It also prescribes the follow-up action ('Follow with browser_snapshot, since element indices reset after navigation'), which is exactly the sequencing an agent needs.

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

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

Beyond the annotations, the description discloses that the tab opens in the background, that it lives in the agent's own tab group, that it returns a tab_id for other browser tools, and that it requires the Computer Use Chrome extension with a limited fallback mode. These are material behavioral traits not present in the annotations.

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

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

Three sentences, each earning its place: the core action and return value, the background behavior, and the alternative tool with extension requirement. The most important operational detail is 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 two-parameter optional tool with no output schema, the description is complete enough: it states what the tool returns, how the tab behaves, when to use a sibling instead, and the extension prerequisite. The agent has what it needs 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 fully documents url and session_id. The description adds context about the returned tab_id and its downstream use, but does not add parameter-level semantics beyond the schema. This matches the baseline for high schema coverage.

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

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

The description states a specific verb and resource ('Open a URL in a new background tab'), clarifies the tool's distinguishing behavior (background tab, agent's own labelled tab group), and names the return value (tab_id). This clearly differentiates it from sibling tools like browser_navigate and browser_use_tab.

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 explicitly says when to use this tool: to open a URL in a new background tab without interrupting the user. It also names the alternative and the exact condition for choosing it: 'Use browser_use_tab instead when the user already has the page open and signed in.' This is direct usage guidance, not just implied.

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

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

Annotations already flag destructiveHint=true and non-idempotent, but the description explains the concrete consequences (Enter can submit forms, Backspace deletes) and discloses a non-obvious behavior not derivable from any structured field: Tab fails rather than silently leaving focus where it was. It also advises snapshotting first, which is real operational guidance.

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

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

Front-loaded with the verb, resource and key set, and every subsequent sentence carries distinct information (key limitation, Tab behavior, destructive consequences). It is four dense sentences rather than one, so it is efficient but not maximally tight.

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

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

With no output schema, the description still covers the destructive risk, the accepted inputs, and the recommended pre-flight check, while the schema handles wait/return-state mechanics. Nothing an agent needs to call this safely 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; the description still adds value by scoping the key enum to exactly four values and clarifying that any other character intent belongs to browser_type. It does not restate the meaning of return_state, wait_for_selector, or tab_id, which the schema already documents.

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 (press) and resource (one of four named keys in a tab), and immediately distinguishes itself from browser_type by routing character input there. An agent can tell exactly what this tool does and does not do without opening the 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 (Enter to submit a form after browser_type), an explicit limitation (only these four keys; use browser_type for characters), and a prerequisite (check page state with browser_snapshot first). Alternatives and conditions are named, not inferred.

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

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

Annotations already cover read-only/idempotent/open-world safety, but the description adds genuine behavioral context beyond them: it works on a background tab, includes scrolled-out content, and returns long pages in chunks with a stated stop point. The trailing 'Read-only' merely restates readOnlyHint, keeping this 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?

Front-loads what is read, then format, then usage/alternatives, then background-tab and chunking behavior. 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 full-coverage, fully-annotated read tool with no output schema, the description covers purpose, alternative routing, return shape (chunking + offset continuation) and safe concurrent use (background tab). Nothing needed to call 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% and all six parameters are documented in-schema, so the schema does the heavy lifting. The description only reinforces offset-based continuation, adding no syntax or semantics beyond what the schema already states, which is the baseline 3.

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) plus resource (the page text in one of the agent's tabs) and even the output format (headings with #, paragraphs, lists, table text in reading order). It explicitly distinguishes itself from browser_snapshot, so an agent can route 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 cases (read an article, results or documentation) and names the alternative with its own use case (browser_snapshot to find something to click). The selection condition between the two read-oriented siblings 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?

The description adds meaningful behavioral context beyond the annotations: the agent stops driving the tab and the page remains unchanged. This clarifies that the operation releases control rather than closing or modifying the page. It does not describe error/ownership edge cases, but the core behavioral contract is well disclosed.

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

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

The description is three concise sentences with no filler: the first defines the action, the second states when to call it, and the third points to the relevant alternative. Key information is front-loaded and every sentence earns its place.

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

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

For a simple two-parameter tool with full schema coverage and helpful annotations, the description is complete enough. It conveys purpose, timing, behavior, and the key alternative without requiring an output schema or further elaboration.

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 both parameters are well documented in the schema. The description reinforces that tab_id must refer to a previously adopted tab but does not add new semantic details beyond that. This meets the baseline for well-covered 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 uses a specific verb and resource: it hands an adopted tab back to the user and stops agent control. It also clearly distinguishes from browser_close_tab by stating the page is left exactly as it is, so the agent can tell this tool apart from its sibling.

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

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

The description gives an explicit timing rule: 'Call it as soon as you are done with an adopted tab.' It also names the alternative, browser_close_tab, for tabs the agent opened itself, making when-to-use and when-not-to-use clear.

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

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

Adds substantial behavior beyond the annotations: the values never return to the agent, Chrome names the site's real origin in its own window, one field is shown per listed input, and the call blocks until the user answers, cancels, or times out. None of that is derivable from readOnlyHint/openWorldHint/idempotentHint.

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 with purpose and the safety rule; every sentence carries an instruction the agent needs. It runs a bit long for the number of concepts, but there is little pure filler.

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

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

Covers the privacy model, the input-source workflow, the blocking behavior, and the tool's relationship to browser_type. It stops short of saying what the call yields on cancel or timeout, which matters since there is no output schema, but the coverage is otherwise strong.

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 would be 3, but the description adds real semantics: fields are shown in the order given, indices come from the latest browser_snapshot, and password inputs surface as input[password]. It does not explain the session_id or timeout_seconds behavior beyond the schema, which is fine.

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 ('Ask the user to sign in on the page in one of the agent's tabs') and explicitly distinguishes itself from the closest sibling: use this 'instead of browser_type' for secrets. An agent can route between the two 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 (passwords, verification codes, any secret), explicit when-not (never ask the user to paste a secret into the conversation), and names the alternative (browser_type). It also supplies the surrounding workflow: pull indices from browser_snapshot, then click the sign-in button yourself.

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

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

Beyond the annotations, the description discloses the real-world side effect: the agent's tab group lives in the user's Chrome window, so selecting a tab changes what the user sees. It also clarifies that the user's own tabs are never selectedholistically and that the action is idempotent, matching idempotentHint=true.

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 three sentences with no filler. It front-loads the core purpose, then adds usage guidance and side-effect warnings, with every sentence earning 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 simple tab-selection tool, the description covers purpose, when to use it, when not to use it, side effects, and scope boundaries. The input schema fully documents all parametersable, and there is no output schema, so no return-value explanation 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides, but it does reinforce the fallback relationship for index and the source of tab_id indirectly through the tool 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?

The description states a specific verb and resource: 'Make one of the agent's tabs the visible one in its window.' It also differentiates from related browser tools by noting that browser_snapshot, browser_click, and browser_type work on background tabs, clarifying why this tool is rarely needed.

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 explicitly gives a usage example ('before capturing it with screenshot'), explains that most tasks never need it because other browser actions work on background tabs, and warns to use it sparingly because it changes the user's Chrome window. This is strong when-to-use 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?

Beyond the readOnly/idempotent annotations, the description discloses that it works on a background tab, auto-scopes to the topmost visible dialog, excludes hidden/inert controls while retaining reachable offscreen ones, and reports scope, total and truncation. These are non-obvious behavioral traits an agent needs and that annotations cannot convey.

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-loads the core purpose and the browser_click relationship in the first sentence, then layers scope/pagination details. Dense but every sentence carries distinct information; the only cost is a slightly long single block without visual separation.

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

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

For a 6-parameter tool with no output schema, the description covers what is returned (elements, indices, title, URL, scope/total/truncation), pagination continuation, dialog scoping, and staleness. Nothing an agent needs 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 description coverage is 100%, so the baseline would be 3, but the description adds real meaning: offset/limit continue pagination on the same tab/session and 'indices stay global across pages of an unchanged UI', which clarifies how the paging parameters interoperate. It adds value on top of a complete schema without fully re-documenting every parameter.

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

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

States a specific verb and resource ('List the interactive elements ... on the page'), names the artifact it produces (indices for browser_click, page title and URL), and explicitly differentiates from the sibling browser_read ('use browser_read for the page's text'). An agent can distinguish it from all nearby tools without opening a 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 ('Use it before every browser_click, because indices change when the page changes'), names the alternative for a different need (browser_read for text), and restates the trigger ('Snapshot again after UI changes'). This is exactly the when/when-not/alternative guidance at the top of the rubric.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so safety is covered externally. The description adds real behavioral context the annotations don't: text is inserted at the caret and does not clear existing content, which is exactly what an agent needs to predict the effect. It doesn't cover return_state/snapshot side effects, but those are documented in the 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?

Three sentences, front-loaded with the action and precondition, then the no-clearing behavior, then the alternatives. Every clause carries information; 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 mutation tool annotated for safety and 100% schema coverage, the description covers the precondition, the insertion semantics, and sibling routing. Minor gap: it doesn't warn about the potential destructive nature that destructiveHint implies, but the schema's return_state text handles re-observation guidance.

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 reinforces tab_id context ('one of the agent's tabs') and focus behavior but adds no syntax, formatting, or edge-case detail beyond what the schema already provides per parameter.

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

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

States a specific verb+resource: type text into the currently focused field in one of the agent's tabs. It explicitly distinguishes itself from browser_press_key (keys) and type_text (native apps), so an agent can route correctly without opening schemas.

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 precondition ('browser_click the field first') and names the alternatives with the conditions that select them: browser_press_key for Enter/Tab/Escape/Backspace and type_text for native apps. Nothing is left to inference.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false. The description adds substantial behavioral context: the tab stays in the user's window, is not moved, activated, or reloaded, is never closed by cleanup, and requires browser_release_tab to hand it back. This goes well beyond what annotations convey and is consistent with 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?

Well-structured: purpose, usage, behavior, and handoff are presented in a logical order. The description is slightly verbose but each sentence adds essential information—no redundancy. Could be trimmed slightly, but it's highly 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 tool that adopts a user's tab, the description covers the crucial context: when to use it, how to obtain the tab ID, the exact behavioral guarantees (no movement/reload), and the required release step. It also covers the safety aspect of asking the user. No missing information for an agent 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% for both parameters. The description repeats the tab_id source (from browser_list_tabs) but does not add new semantic meaning beyond what the schema already states. Baseline 3 is appropriate since the schema fully documents 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?

Clearly states the action: 'take over a tab the user already has open' rather than opening a new one. Distinguishes from siblings like browser_open_tab and browser_select_tab by specifying the unique behavior of adopting an existing tab.

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 says when to use: when page is signed in or mid-flow and re-opening would lose state. Provides the concrete step to find the tab_id via browser_list_tabs all=true. Also instructs to ask the user before taking over an active tab, which is a key usage constraint.

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

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

Annotations declare a destructive, non-idempotent, non-read-only write, and the description adds context annotations cannot carry: the click reaches the app for real and may trigger any user-level action, the accessibility press fallback behavior, the agent pointer overlay, and the macOS vs Windows/Linux distinction where a target ignoring background input receives real mouse input that moves the user's pointer (surfaced via 'cursor' in the result). This is materially deeper than the hint flags.

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 primary input mode and the exclusivity rule, then alternatives, then caveats — no filler sentences. However, the final sentence stacks multiple platform conditions into one long run-on clause, which costs a little readability.

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

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

For a 6-parameter, all-optional mutation tool with no output schema, the description covers everything an agent needs: input-mode selection, alternatives, prerequisite state read, real-input caveat, platform pointer side effects, and the inline state-refresh option. Nothing critical is left 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 the baseline is 3, but the description adds genuine semantics: an explicit mutual-exclusion rule between element_id and x/y, the reason element_id is preferred, and the id-invalidation behavior of return_state ('Its ids replace every earlier id'), which is not derivable from the schema alone. click_count and state_query semantics remain schema-only.

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 (click) and two concrete target mechanisms (element_id, screen coordinates), and explicitly names the siblings it is not: browser_click for Chrome tabs, right_click for context menus, drag for press-move-release. An agent can pick the right tool 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?

Gives the selection rule between the two input modes ('Pass element_id or x and y, not both'), states the preference (element_id is preferred and works when scrolled out of view), and routes to three named alternatives with the condition that selects them. It also adds a prerequisite ('read the target with get_app_state first').

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

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

Annotations already cover read-only and idempotent behavior, so the description's safety profile is reinforced rather than duplicated. It adds useful behavioral context beyond annotations: images/files yield no text, and clipboard contents may contain private data like passwords, so output should not be repeated beyond task needs.

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

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

The description is front-loaded with the core action and then provides essential usage guidance, exclusions, edge cases, and a privacy caveat. Every sentence earns its place; there is no filler or repetition of schema details.

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 read tool with one optional parameter and no output schema, the description covers the key conditions, alternatives, non-text edge cases, and privacy implications. Nothing critical is missing for an agent to decide when and how to invoke it.

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

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

Schema description coverage is 100%, so the sole parameter max_chars is already fully documented, including default, maximum, and truncation note. The description adds no additional parameter-specific semantics, matching the baseline for high schema coverage.

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 and resource: 'Read the plain text on the system clipboard.' It also differentiates itself from siblings by explicitly saying to prefer get_app_state, browser_snapshot, or screenshot for on-screen content and to use this tool for text that was deliberately copied.

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 concrete when-to-use examples: after press_key cmd+c / ctrl+c copies a selection, or when the user says they copied something. It also names alternatives and explicitly distinguishes on-screen reading from clipboard reading, and notes that images/files are reported as no text.

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

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

Annotations already signal destructiveness, but the description adds crucial behavior beyond them: it overwrites the user's clipboard and does not restore it, and it tells the agent to inform the user. It also clarifies that the tool only writes the clipboard and does not perform the paste, preventing a common misuse.

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

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

Three sentences, all necessary: the action, the use case, and the critical side-effect warning. The most decision-relevant facts are front-loaded, and there is no filler or repetition of schema 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 single-parameter tool with no output schema, the description covers all an agent needs: what it does, when to use it, what it does not do, its side effects, and how it relates to sibling tools. Nothing essential 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% and the single parameter is already well described. The description adds a little extra meaning by specifying plain text and mentioning the typical use case of long or multi-line values, which helps the agent understand the character of the input beyond the schema's 'Exact text.'

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

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

The description states a specific verb and resource: 'Replace the system clipboard with plain text.' It also explains the intended role in a larger workflow (enabling cmd+v paste) and explicitly differentiates itself from set_value and type_text, so an agent can distinguish it from siblings without inspecting schemas.

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 concrete when-to-use context: when a long or multi-line value must be pasted via press_key and set_value is rejected or type_text would be slow. It also states a clear exclusion: 'This tool does not paste anything itself' and explicitly recommends set_value or type_text when they work.

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

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

Annotations only declare destructive/not-read-only/not-idempotent; the description adds genuinely new behavioral facts: macOS drags are confined to one app window and never move the user's pointer, while Windows/Linux use real mouse input that does move the pointer and reports 'via cursor'. That platform-level side-effect disclosure is exactly what annotations cannot convey.

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

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

Three sentences, front-loaded with the core action and outcomes, then the parameter-form rule, then the platform caveats. No filler, and the highest-value constraint (verify with get_app_state) is placed before the platform detail.

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

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

For a destructive, non-idempotent interaction tool with no output schema, the description covers the action, both coordinate/element input forms, the verification path, and the platform-dependent side effects. Nothing an agent needs in order to invoke it safely 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 a rule the schema does not state: each end may be given as an element id or screen coordinates, and the two ends may use different forms. That mixed-form semantics is real added value over the per-parameter 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 gives a concrete verb sequence (press, move, release) and enumerates the three outcomes it covers: drag-and-drop, slider movement, and range selection. This cleanly separates it from siblings like click, scroll, and select_text, which an agent can rule out without opening any schema.

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

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

It tells the agent to follow up with get_app_state because a drop may move or reorder items, which is real routing guidance. It also frames the valid use cases (drop, slider, range). It stops short of explicit when-not-to-use or a named alternative for plain movement, so it is strong but not exhaustive.

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

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

Goes well past the readOnly/idempotent annotations: ids are per-snapshot, stale ids fail rather than mis-clicking, offscreen rows are skipped, only blocking-dialog controls appear when a modal is up, and OCR substitutes for apps with weak accessibility exposure. It also discloses the non-effect on focus, which annotations cannot express.

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

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

Six tight sentences, each carrying distinct load: what it returns, why over screenshot, when to re-call, what ids guarantee, what is excluded, and the OCR fallback. The most decision-critical point (use this before acting) lands in sentence two.

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 compensates by describing the return format, the id scheme, truncation behavior, and the modal/offscreen omissions an agent must anticipate. Nothing needed to call it correctly on a six-parameter, read-only tool is left 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 coverage is already 100%, so the baseline is 3; the description adds real guidance by recommending `query` over `max_elements` and over `offscreen`, and explaining that query searches the whole outline and preserves id validity. It does not restate enum mechanics, which is fine since the schema does.

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 — reading an app's accessibility tree — and immediately characterizes the output shape (indented outline with [e12] ids) and who consumes those ids. It distinguishes itself from `screenshot` and implicitly from `browser_snapshot` by framing itself as the app-level, act-before-you-click reader.

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: 'Use it instead of screenshot whenever you intend to act', 'Call it before interacting and again after the UI changes'. It also names in-parameter alternatives (scroll or pass `offscreen`, use `query` instead of raising `max_elements`) and states preconditions for the OCR path (Screen Recording permission).

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is partly covered. The description adds genuinely non-obvious behavioral context beyond the annotations: on macOS the user's pointer is not moved, on Windows/Linux it may be, and the result reports 'via cursor'. It does not discuss any notion of limits or failure modes, so not a full 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?

It is a short, front-loaded block of sentences with no filler. The primary action and its purpose come first, followed by follow-up guidance, the targeting constraint, and the platform caveat, each earning 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?

There is no output schema, and the description compensates by telling the agent how to observe the result ('Follow with get_app_state or screenshot to see what appeared'). Combined with the mutual-exclusion rule and platform behavior, the description is complete enough for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents all five parameters, which sets a baseline of 3. The description adds a real semantic constraint not in the schema: element_id and x/y are mutually exclusive ('not both'), which clarifies how the targeting parameters interact.

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

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

The description gives a specific verb (move the agent pointer over) plus the resource (an element or screen position) and the reason (reveal hover menus, toolbars, tooltips, drag handles). It also explicitly contrasts with the sibling action by saying 'Use click to activate', so the agent can distinguish hover from click 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?

It states when to use it (to reveal hover content), what to do afterward ('Follow with get_app_state or screenshot'), and how to escalate ('Use click to activate'). It also gives the exclusivity rule for the two targeting modes ('Pass element_id or x and y, not both'), leaving nothing to inference.

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

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

Annotations already declare read-only/idempotent, but the description adds real context beyond them: multiple instances per app, instances that own no windows, a closing note listing pids, and that no window or input is touched. This is the exact guidance needed to interpret the output correctly.

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

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

Four sentences, each carrying distinct information: purpose, call-order guidance, instance-selection advice, and a safety note. The controlling guidance is front-loaded 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?

No output schema exists, so the description must characterize the return shape — and it does thoroughly (bundle id, pid, window count, frontmost flag, main window title, closing pid note). Nothing an agent needs to call or interpret it 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?

Zero parameters, so baseline is 4. The description still adds useful semantics by explaining how returned identifiers (app name, pid) should be supplied to downstream tools, exceeding the schema's empty object.

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?

Opens with a specific verb+resource ("List running applications") and immediately enumerates the returned fields (bundle id, pid, window count, frontmost), which distinguishes it from siblings like get_app_state and list_displays.

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 says "Call it first to learn the exact `app` value that get_app_state, screenshot and activate_app accept" — naming three consuming siblings and the condition that selects this tool. It also advises preferring the instance that has windows and passing a pid.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond annotations by detailing the returned data (index, resolution, position) and its intended use. The 'Read-only' remark is redundant with annotations but not contradictory.

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, front-loads the core action and result, and immediately states the use cases. Every clause adds value without redundancy or fluff.

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 stateless, parameterless read-only tool, the description is nearly complete. It states what is returned and why. A minor gap is not explicitly noting the zero-based nature of display indices or the exact output format, but these are inferable from the list of nouns and the reference to screenshot(display: N).

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 zero parameters and the schema coverage is 100% (empty schema fully describes the input). With no parameters to document, the baseline of 4 applies; the description correctly focuses on output and purpose rather than parameter 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 uses a specific verb ('List') and resource ('attached display'), and specifies what is returned: index, resolution, and position. It also explicitly ties the tool's purpose to downstream use with screenshot(display: N) and multi-monitor coordinate interpretation, making it clearly distinguishable from all sibling 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?

The description gives explicit usage context: this is the tool to call before taking screenshots on a specific display or when working with screen coordinates on multi-monitor setups. It effectively tells an agent when to select this tool among the many siblings.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds context annotations cannot: the keystroke goes to the last-clicked/focused app, on macOS/Windows the user may be typing elsewhere concurrently, and shortcuts 'can close windows or delete content, so confirm the target before pressing.' That is genuine disclosure of risk surface and target routing, not restatement of the annotation flags.

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

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

Four tightly packed sentences, front-loaded with purpose then routing then caveat, and each sentence carries distinct information. It is dense rather than padded, though the focus/multi-user sentence is long enough to slow the read slightly.

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, non-idempotent, destructive input tool with a rich schema and no output schema, the description covers purpose, routing, target resolution, and the destructive caveat. The only notable gap is that it does not mention the state-returning behavior enabled by return_state beyond a brief schema-level note, which is largely handled by the parameter documentation.

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%, with each parameter (key, modifiers, state_query, return_state) fully documented in the schema, so the baseline is 3. The description's example pairing key with modifiers adds a small amount of practical framing, but it does not explain return_state or state_query semantics beyond what the schema already says.

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 ('Press one named key, optionally with modifiers held') and immediately grounds it with two concrete examples ('cmd'+'s' to save, 'return' to submit). It also explicitly separates itself from the two closest siblings, type_text and browser_press_key, so an agent can route correctly without opening a 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 ('shortcuts and navigation keys') and when-not with named alternatives ('use type_text for literal text and browser_press_key inside the agent's Chrome tabs'). It further adds the precondition that governs a sibling call: 'call activate_app only when nothing has targeted the app yet.'

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds the useful note that the pointer is 'treated as for click' and that ids may be replaced after return_state, but it never says the opened context menu can expose destructive actions or that nothing is committed until a menu item is clicked.

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

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

Four compact sentences, front-loaded with purpose followed by usage and then parameter rules; nothing is padded. The trailing sentence about the user's pointer is the vaguest and earns the least of 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?

There is no output schema, and the description compensates by telling the agent the context menu contents must be read via get_app_state and that return_state can append fresh state in the same call, including the id-invalidation caveat. Nothing needed to invoke and interpret the call 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 the mutual-exclusion rule that the schema does not state ('Pass element_id or x and y, not both'), which genuinely changes how an agent constructs the call.

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

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

States a specific verb (right-click / secondary click) plus the resource (an element or screen position) and the effect (opens its context menu). It also distinguishes itself from the sibling 'click' by naming it and assigning it the normal-activation case.

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

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

Explicitly gives the when-to-use alternative ('Use click for normal activation') and the follow-on workflow ('Follow with get_app_state to read the menu items, then click one'). An agent knows exactly which tool to pick and what to do next.

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

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds traits they do not cover: the captured window is not raised or focused, and the result text carries screen origin plus pixels-per-point so image pixels convert to click/hover coordinates. That is genuine extra behavioral context beyond the structured hints.

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 densely-packed sentences with the primary action, the alternative tool, and the side-effect disclosure front-loaded in that order. No filler and every clause carries 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?

With no output schema, the description correctly compensates by explaining the result text's coordinate-conversion data. Combined with the full schema for parameters and annotations for the safety profile, an agent has everything needed to call and interpret this 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 description coverage is 100%, so the schema already documents app/display/format/quality/max_width including defaults and valid values; that establishes the baseline of 3. The description adds only the loose hint that zoom helps read small text (related to quality/max_width) and otherwise does not extend parameter meaning.

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: capture an app's largest window or a whole display as an image. It also names the output semantics (screen origin, pixels-per-point) and explicitly distinguishes itself from sibling get_app_state and zoom, so an agent can pick it without opening a 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?

Explicitly says to prefer get_app_state for interaction because it is cheaper and returns clickable element ids, and defines exactly when screenshot is the right choice: verifying an outcome or seeing content the accessibility tree cannot describe, using zoom for small text. This is a full when/when-not/alternatives routing.

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

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

Goes well beyond the annotations by disclosing platform-specific side effects: macOS scrolls the target app in the background without moving the pointer, while Windows/Linux scroll under the pointer and may move the real cursor onto an element with no background route (with a 'via cursor' marker in the result). It also discloses that nothing is clicked or selected, which the readOnlyHint=false / destructiveHint=false annotations alone do not convey.

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 core action and direction, then layered with usage and platform caveats in a compact sequence. It is dense but every clause carries real information; the platform-specific sentences are long but necessary for a cross-platform tool.

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

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

With no output schema and 7 optional parameters, the description supplies the behavioral context an agent needs: what triggers scrolling, what happens on each platform, and what the 'via cursor' result marker means. Combined with the fully-covered schema, nothing essential for correct invocation 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 x, y, amount, direction, element_id, state_query, and return_state are already fully documented. The description adds only marginal meaning, mostly restating element_id's conditional behavior ('over element_id when given') that the schema already spells out for the omit case.

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) plus direction and line count, and scopes the resource to element_id or the app under the pointer. It is immediately distinguishable from siblings like click, drag, and get_app_state, and it explicitly says 'It only scrolls; nothing is clicked or selected.'

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 when-to-use ('bring off-screen content into view before get_app_state or screenshot') and names the follow-up tools that consume the result. The boundary statement ('only scrolls; nothing is clicked or selected') tells the agent when a different sibling (click/select) is 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?

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false. The description earns credit by resolving the tension that readOnlyHint=false creates: it clarifies that only the selection changes and the underlying text is not modified, which is the key behavioral fact an agent needs. It does not discuss permissions or error cases, so it stops short of 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 short sentences, front-loaded with the action and scope, then the sibling alternative, then the side-effect disclaimer. No filler and nothing redundant between sentences.

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

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

For a 5-parameter tool with full schema coverage and no output schema, the description covers purpose, default range, side effect, and sibling routing. It does not explain what the return_state snapshot will look like, but the schema already describes that, leaving only 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?

Schema description coverage is 100%, so every parameter (including start/length defaults and the return_state mechanics) is already documented in the schema. The description only restates the start-to-end default, adding no syntax or semantics beyond that. 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?

The description states a specific verb (select) and resource (a character range inside a text element), plus the mechanism (accessibility API). It explicitly separates itself from the adjacent siblings type_text and set_value, so an agent can route 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?

Gives both a positive use case (copy part of a value, or set up a partial replacement via type_text) and the explicit alternative plus its selection condition ('Use set_value to replace the whole value instead'). Default behavior (start -> end) is stated so the agent knows how to call it minimally.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower. The description reinforces this by stating the previous value is discarded and that failures surface in the result, adding useful context beyond the annotation flags.

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 zero waste: purpose, routing rule, and the destructive caveat. Front-loaded and well ordered.

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 full schema coverage and no output schema, the description covers purpose, alternatives, fallback behavior, and the destructive consequence. Nothing an agent needs 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 all four parameters are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides; 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?

States a specific verb+resource ('Replace a text field's entire contents') plus the mechanism ('through the accessibility API, without keystrokes'), which cleanly distinguishes it from the sibling type_text.

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: prefer over type_text for long values or pre-filled fields; fall back to click plus type_text if rejected, and it names where the rejection is reported ('which the result reports').

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

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

Annotations declare destructiveHint=true, readOnlyHint=false and idempotentHint=false; the description goes well beyond them by disclosing caret-insertion semantics (no clearing), keyboard non-hijack behavior on macOS/Windows, the activate_app exclusion, and the password-field refusal with its env-var escape hatch. This is exactly the extra behavioral context annotations cannot carry.

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 core action, then alternatives, then behavioral caveats — a logical order with no filler sentences. It runs somewhat long across five sentences, but each earns its place by adding distinct constraints.

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, yet the description explains what return_state returns and that ids are replaced, covering the result-inspection path. Combined with safety-relevant annotations and the accessibility/password caveats, an agent has everything needed 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 baseline is 3, but the description reinforces element_id behavior ('optionally focusing element_id first') and return_state/state_query semantics ('a fresh get_app_state... its ids replace every earlier id'). It adds some operational meaning beyond the schema text, though most param detail lives in 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+resource ('type literal text as keystrokes into the field that currently has focus') and immediately differentiates from siblings set_value and press_key by naming what each is for. An agent can tell exactly what this does versus click/select_text/set_value without opening a 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 ('short entries', 'fields that reject set_value') and named alternatives with their conditions ('use set_value to replace a long value in one step, and press_key for shortcuts or keys such as return and tab'). Also gives a when-not hint: 'do not call activate_app first'.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: the wait exists to let UI transitions settle, and it sends no input. This enriches the annotation profile without contradicting it.

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 purposeful sentences front-load the core purpose and usage context, then add the verification follow-up and the behavioral constraint. Every sentence 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 simple no-input pausing tool with strong annotations and a fully described schema, the description covers why, when, and how to confirm the result. Nothing an agent needs to correctly invoke this tool 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%, and the only parameter (seconds) is already fully documented with default and maximum. The description does not need to repeat this, but it also adds no additional nuance about how the parameter interacts with wait behavior. 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 uses a specific verb ('Pause') and gives concrete use cases (page loads, animations, dialogs opening, apps launching), so an agent can tell exactly what the tool does. It also separates this action-oriented tool from siblings like get_app_state or screenshot by noting it 'sends no input.'

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 clearly states when to use the tool: before the next action when the UI needs to catch up. It also advises following up with get_app_state or screenshot to confirm the new state instead of guessing, giving actionable post-wait guidance. It does not explicitly discuss when not to use it, but the context is clear.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds useful behavioral context: the coordinate space is the same as click, and the result text explains how to map pixels back to screen coordinates. This goes beyond the annotations without contradicting 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?

Three tight sentences: purpose/use cases, input format plus result behavior, and alternative routing. There is no filler or repetition; every sentence earns its place.

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

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

For a read-only capture tool with fully documented parameters, the description covers why to use it, when to avoid it, how to specify input, and what the result will indicate. No output schema exists, but the description does disclose the essential result behavior, so the agent has what it needs to call the 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 coverage is 100%, so the baseline is 3; the description adds meaningful extra context by clarifying that the region is defined by two corners in the same coordinate space that click uses. It also explains why that matters by mentioning pixel-to-screen mapping in the result.

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

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

The description states a specific verb and resource: 'Capture one region of the screen at full resolution.' It also names concrete use cases (small text, dense tables, file names, tiny controls) and is clearly differentiated from the sibling screenshot tool by emphasizing regions at full resolution.

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 tells the agent when to use this tool versus alternatives: 'Use screenshot for a whole window and get_app_state when the text is exposed by accessibility.' This gives direct routing guidance beyond mere inference.

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