Computer Use

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

Annotations declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the concrete side effect that the user's current window loses focus, and clarifies that it gives keyboard focus. It doesn't contradict annotations and provides useful behavioral context beyond the structured 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?

Two sentences, zero filler. The primary purpose is in the first sentence, and the second sentence packs usage guidance and side effect efficiently. All content 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 single-parameter, side-effectful operation with no output schema, the description covers the action, the trigger conditions, the side effect, and the parameter format (via schema). 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 parameter 'app' is fully documented with format ('App name, bundle id, or pid exactly as reported by list_apps'). The description adds no additional parameter-specific details, which is acceptable given the high 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 ('bring') and resource ('an app's windows'), and clearly defines the outcome: foreground and keyboard focus. It also distinguishes from siblings by noting that element-id actions like click and set_value do not need it, which helps an agent pick the right tool.

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 says when to call it: before press_key or type_text when the target app is not frontmost, and explicitly says when not needed. It also mentions the side effect of losing focus in the previous window, giving clear situational 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?

Annotations already cover the risk profile (destructiveHint=true, openWorldHint=true, non-idempotent, not read-only), so the bar is lower. The description still adds real context beyond them: it works on background tabs, clicks can cause navigation/form submission, and the snapshot indices get replaced after a state refresh.

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 tight sentences, front-loaded with the primary addressing mode (index) before the fallback (coordinates), then the exclusivity rule, then the side-effect warning. No sentence is filler.

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

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

For a mutating, open-world click tool with no output schema, the description covers targeting, exclusivity, background-tab behavior, the sibling alternative, and the side-effect hazard. It could say slightly more about what return_state yields, though the schema already explains that.

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 every parameter is already documented in the schema, giving a baseline of 3. The description adds one genuinely new constraint the schema lacks — 'Pass index or x and y, not both' — but otherwise restates what the schema already says about index vs. coordinates.

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 precise verb (click) and resource (agent's browser tab), and explicitly delimits itself from the sibling `click` tool ('Use click for native app windows'). An agent can distinguish it from right_click/hover and from the native-app click 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 routing: prefer the `index` from browser_snapshot over raw coordinates, use the sibling `click` for native app windows, and 'snapshot first' because a click can submit forms or follow links. It also notes it works on a background tab, which is a non-obvious usability fact.

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 substantial behavioral detail beyond the annotations: it clarifies that user-taken-over tabs are released rather than closed, warns that unsaved state is lost, and discloses automatic execution when the Computer Use session ends. These are meaningful side effects not captured by the structured metadata.

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?

Each sentence serves a distinct purpose: core action, exception handling, when to call, automatic behavior, and data-loss warning. The description is front-loaded with the main operation and remains appropriately sized for a destructive cleanup 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?

The description covers the action, side effects, user-impact, automatic invocation, and unsaved-state warning. For a destructive tool with a single documented parameter and no output schema, this provides everything an agent needs to call it correctly and understand consequences.

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 session_id parameter is fully documented in the schema. The description does not add parameter-level detail, but the baseline of 3 applies because the schema handles the parameter semantics.

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

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

The description clearly states the action ('Close every tab the agent opened and remove its tab group') and distinguishes it from sibling tools like browser_close_tab by specifying scope (all agent tabs) and the special handling of tabs taken over via browser_use_tab. This makes the tool's purpose 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 gives explicit usage context: 'Call this when finished with the browser' and notes the automatic execution at session end. It does not explicitly name an alternative for closing a single tab, but the overall context and sibling list make the intended condition 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?

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 and idempotentHint=false; the description adds the concrete consequence ('unsaved page state is lost') and a non-obvious post-condition ('element indices reset after navigation') that the structured fields cannot express. This materially affects how an agent sequences its next call.

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, each earning its place: the destructive action, the alternative, and the required follow-up. The consequence is front-loaded before the routing advice.

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

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

No output schema exists, yet the description tells the agent what happens to prior state and what call to make next, covering the gaps a navigation tool would otherwise leave. Annotations plus the 100%-documented schema leave nothing important 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% for all four parameters, so the schema already documents tab_id, url, session_id and return_state semantics. The description adds no parameter-level syntax or format detail, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Point one of the agent's tabs at a different URL, replacing the current page') and immediately frames it against the sibling browser_open_tab. An agent can distinguish it from every other tab tool 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 gives the alternative and its selecting condition ('Use browser_open_tab to keep the current page and open another'), plus prescribes the follow-up call ('Follow with browser_snapshot'). Both when-to-use and what-to-do-next are covered.

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

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

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 declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the mutation risk is covered structurally. The description goes beyond that by naming the concrete side effects ('Enter can submit forms and Backspace deletes') and the key limitation, though it says nothing about failure modes or what happens on an invalid tab_id.

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, all earning their place: capability first, then the exclusivity constraint, then the caution and precondition. No filler or repetition of name/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?

For a 4-parameter tool with full schema coverage and annotations, the description supplies the essentials: supported keys, side effects, the sibling route for typing, and the snapshot precondition. It does not mention session_id isolation or the return_state snapshot behavior, but the schema covers both, so the gaps are minor.

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 tab_id, session_id, and return_state in detail, and the enum defines the allowed keys. The description only restates the key restriction already encoded in the enum, adding no new per-parameter meaning; 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 ('Press Enter, Tab, Escape or Backspace in one of the agent's tabs') and enumerates the exact supported key set. It explicitly distinguishes itself from browser_type, so an agent can pick the right sibling 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 when-to-use with a concrete example ('Enter to submit a form after browser_type'), names the alternative and its exclusion condition ('use browser_type for characters'), and prescribes a precondition ('check the page state with browser_snapshot 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/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?

Annotations already cover readOnly/idempotent/non-destructive, but the description adds genuine context beyond them: it works on a background tab while the user views something else, indices become stale when the page changes, and inputs disclose their type (e.g. input[password]). It does not discuss pagination or element-count limits, so it falls 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 the tool returns, then usage rules and the read-only flag. Every sentence carries distinct information (output contents, background-tab behavior, click prerequisite, sibling routing) 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?

Even without an output schema, the description enumerates the return shape (elements + index + title + URL) and the background-tab and index-volatility behaviors. An agent has everything needed to call it correctly and interpret the result.

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 tab_id and session_id are already fully documented in the schema. The description only implies tab context ('one of the agent's tabs') without adding syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('List the interactive elements (links, buttons, inputs)') and adds the key output detail that each element carries the index needed for browser_click, plus page title and URL. It explicitly distinguishes itself from browser_read by routing text extraction elsewhere.

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 hard rule ('Use it before every browser_click, because indices change when the page changes') and names the alternative ('use browser_read for the page's text'). The when-to-use condition and the sibling routing are both explicit, 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 readOnlyHint=false, idempotentHint=false and destructiveHint=true, so the safety profile is conveyed. The description adds genuinely new behavioral detail: text is inserted at the caret and does NOT clear existing content, which materially qualifies the destructiveHint and tells the agent the call is conditional on prior focus state.

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

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

Two dense sentences, zero filler. The core action and its focus precondition come first, alternatives second — correctly front-loaded for scanning.

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, but for a mutation tool the agent needs the focus prerequisite, the non-clearing behavior, and the routing to sibling tools — all present. Only minor gaps remain (e.g. whether typed text fires input/keyboard events or how focus loss surfaces as an error).

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 all four parameters (including tab_id provenance and return_state semantics) are already documented in the schema. The description adds no syntax for text or tab_id beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (type) and resource (focused field in one of the agent's tabs), and explicitly names the sibling tools it is not (type_text for native apps, browser_press_key for control keys). An agent can distinguish it from the other ~30 siblings immediately.

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 routes two adjacent use cases to their correct alternatives: browser_press_key for Enter/Tab/Escape/Backspace and type_text for native apps. When and when-not are both covered.

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

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

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?

Goes well beyond the annotations: it explains that the click reaches the real app and can trigger any user-level action, that element_id uses the accessibility press action and works off-screen, that the agent's overlay moves to the target, and the platform-specific pointer side effects (macOS never moves the user's pointer; Windows/Linux may, signalled by 'via cursor' in the result). This is exactly the extra context annotations like destructiveHint 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 action and targeting modes, then folds routing, prerequisites, and platform caveats into a few dense sentences. Slightly long, but nearly every clause carries operational information; a minor tightening could help.

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

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

For a 6-param, zero-required, destructive, annotation-covered tool with no output schema, the description covers targeting, prerequisites, exclusions, side effects, and even the shape of the result ('the result then says via cursor'). Nothing an agent needs 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 already 100%, but the description still adds value: it states element_id is preferred and that element_id and x/y are mutually exclusive (0 required params means the schema does not enforce this). It does not explain click_count or state_query/return_state beyond what the schema says, so it stops short of a 5.

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 ('Click an element') and immediately names the two accepted targeting modes (element_id vs x/y). It also explicitly differentiates itself from siblings (browser_click, right_click, drag), so an agent can route correctly without reading other 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 explicit when-to-use routing ('Use browser_click for pages in the agent's Chrome tabs, right_click for context menus, drag for press-move-release'), a prerequisite ('read the target with get_app_state first'), and a parameter-level rule ('Pass element_id or x and y, not both').

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?

Goes well beyond the annotations (destructiveHint/readOnlyHint) by disclosing consequences ('a drop can move or reorder items'), platform-specific input mechanics (macOS stays inside one window and never moves the pointer; Windows/Linux use real mouse input and report 'via cursor'), and that ids are invalidated by return_state. This is exactly the behavioral context annotations cannot express.

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

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

Three sentences, front-loaded with the physical action and use cases, then the parameter-form rule, then verification and platform behavior. No filler sentences; each one changes how an agent would call the 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-param, no-output-schema mutation tool, the description covers the interaction model, verification path (get_app_state / return_state), and platform caveats. Only the non-return_state response shape is left implicit, a minor gap given return_state is documented.

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 per-parameter docs carry the load and the baseline is 3. The description still adds non-obvious semantics: the two ends may use different forms (mixing element id and coordinates), exceeds what the schema descriptions alone convey.

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 concrete verb and physical action ('press at one point, move, release at another') and enumerates the three distinct outcomes: drag-and-drop, slider movement, range selection. This is enough for an agent to separate 'drag' from click, hover, select_text, and press_key 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 clear operating conditions: each end may be an element id or coordinates and the two forms can be mixed, and the result should be verified with get_app_state. It also flags the platform constraint on macOS versus Windows/Linux. It stops short of explicit when-not-to-use guidance against siblings like click or select_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 cover readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses the id format ([e12]), that ids are per-snapshot and stale ids fail, that the output is a token-cheap outline, and that it does not change focus. 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?

Four tightly packed sentences, front-loaded with what the tool returns, then the screenshot comparison, then the staleness/sequencing rule, then the read-only guarantee. No sentence is 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, the description carries the burden of explaining the return format (indented outline with [e12] ids) and it does so, plus it covers lifecycle (re-call after UI changes), safety (read-only, no focus change), and cost (token-cheap). Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the [e12] id convention and which sibling tools accept those ids. It does not add much to the query/max_depth/max_elements tradeoff that the schema descriptions already state, so it lands just above baseline.

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

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

States a specific verb and resource ('Read an app's accessibility tree as an indented outline') and immediately distinguishes itself from the screenshot sibling by naming the alternative and the condition that selects this tool. An agent can tell exactly what it gets back and how it differs from the other read 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?

Explicit when-to-use ('Use it instead of screenshot whenever you intend to act'), explicit when-not/alternative, and a sequencing rule ('Call it before interacting and again after the UI changes'). It also names the tools whose parameters consume the returned ids, so the workflow is fully specified.

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 beyond the annotations by disclosing platform-specific side effects: on macOS the user's mouse pointer is not moved, while on Windows/Linux it may be and the result reports 'via cursor'. That is exactly the kind of environmental behavior an agent needs and that the schema cannot express. It does not, however, explain timing/settle semantics in any depth beyond the parameter descriptions.

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 tight sentences, front-loaded with purpose and followed by the workflow and the platform caveat. No filler; each sentence carries a distinct piece of 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 100% schema coverage, no output schema, and annotations covering the safety profile, the description supplies the remaining gaps: expected follow-up tools, activation alternative, argument exclusivity, and platform pointer behavior. Nothing essential for a correct 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 already 100%, so the baseline is 3, but the description adds a real constraint the schema only implies: element_id versus x/y are mutually exclusive, not to be combined. That extra coordination rule is meaningful beyond the per-parameter 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?

States a specific verb (move/hover) and resource (agent pointer over an element or screen position) and immediately scopes it against the sibling click with 'without clicking'. An agent can tell what this does and how it differs from click/right_click 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?

Explicitly says when to use it (to reveal hover menus, toolbars, tooltips, drag handles), what to do next (get_app_state or screenshot), and what to use instead to activate (click). It also states the mutual-exclusivity rule: element_id or x and y, not both.

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

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

Annotations already declare the operation is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond annotations: it states no window or input is touched, and explains the multi-instance/window-ownership nuance that affects how an agent should use the results.

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 first states purpose and output fields, the second gives operational guidance with a concrete use-before pattern, and the third reassures about read-only safety. No filler or repeated annotation material.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description is complete: it enumerates the return fields, explains why the tool should be called first, and covers the instance-selection caveat. An agent has everything needed to call it correctly and interpret the result.

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 schema coverage is trivially 100%, so there are no parameter details to explain. The description correctly focuses on the value of the tool's output rather than 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?

States a specific verb ('List') and resource ('running applications') and enumerates the exact fields returned (bundle id, pid, window count, frontmost). It also explains the tool's role as the discovery entry point for sibling tools, distinguishing it from the rest.

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 instructs to call this tool first to learn the exact 'app' value accepted by get_app_state, screenshot, and activate_app. It also provides concrete guidance on choosing the right instance when multiple exist and only some own windows.

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, readOnlyHint=false and idempotentHint=false, so the safety profile is known; the description adds value on top by explaining that keystrokes are delivered to the focused app and that shortcuts can close windows or delete content, warranting confirmation of the target. It does not describe latency, error behavior, or what happens if the named key is unsupported, so it stops short of a 5.

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

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

Four short sentences, each load-bearing: purpose+example, sibling routing, focus prerequisite, destructive warning. The primary action is front-loaded and nothing is repeated from the schema.

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

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

With no output schema, the description does cover the feedback loop by referencing return_state and the fresh app state it appends. Combined with the focus and destructiveness guidance, an agent has enough to call this correctly, though a note on failure/unsupported-key behavior would close the remaining gap.

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 key names, modifier names and return_state/state_query semantics are fully documented in the schema (baseline 3). The description adds marginal value by demonstrating a real invocation shape ('key=s', modifiers=['cmd']) and tying return_state to checking results and picking the next target, but does not add syntax beyond the schema.

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

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

States a precise verb+resource ('Press one named key, optionally with modifiers held') and immediately grounds it with concrete examples ('s' with 'cmd' to save, 'return' to submit). It explicitly distinguishes itself from the two closest siblings, type_text and browser_press_key, so an agent can route correctly 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 explicit when-to-use and when-not-to-use: shortcuts/navigation keys for this tool, literal text for type_text, and browser_press_key inside Chrome tabs. It also states the prerequisite for focus ('call activate_app or click first when focus is uncertain'), which is exactly the kind of routing condition 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds the pointer-treatment behavior and the follow-up workflow, but never explains why a context-menu action is flagged destructive, which is the one non-obvious trait worth clarifying.

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, then the follow-up workflow, the alternative tool, and the parameter constraint. Four tight sentences 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?

With annotations covering safety, a 100%-covered schema, and no output schema, the description supplies the essential workflow context an agent needs. It stops just short of explaining the destructive flag, but is otherwise complete.

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 genuinely useful constraint not stated in the schema: 'Pass element_id or x and y, not both.' It also implies the two targeting modes, giving the agent more than the raw property descriptions.

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

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

States a specific verb and resource ('Right-click (secondary click) an element or screen position to open its context menu') and names the distinguishing effect (opening a context menu) that separates it from the sibling click tool. An agent can identify this 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 an explicit workflow ('Follow with get_app_state to read the menu items, then click one') and names the alternative with its selection condition ('Use click for normal activation'), 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 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?

With annotations only covering safety flags, the description carries the real behavioral burden and does so: platform-specific side effects (macOS scrolls the target app in the background without moving the pointer; Windows/Linux scroll under the pointer or move the real pointer onto elementless targets), plus the 'via cursor' result marker. This is exactly the side-effect disclosure an agent needs for a non-read-only tool.

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

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

Three sentences, front-loaded with the action and then usage and side effects; no filler. The final platform sentence is dense but every clause is load-bearing for correct invocation.

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

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

For a 7-parameter, no-output-schema tool with platform-dependent behavior, the description covers the action, usage, and cross-platform side effects well. It leaves return_state/state_query semantics entirely to the schema, which is acceptable, but a note on what the scroll call returns by default would close the remaining gap.

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 every parameter, including element_id fallback behavior and the x/y remote-control caveat. The description's parameter mentions (element_id 'so the right pane scrolls', x/y platform behavior) largely restate the schema rather than adding new syntax or constraints, 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 (scroll) plus resource/axis and line count, and names the targeting parameter (element_id) that selects which pane moves. An agent can tell this apart from click, drag, and hover siblings immediately.

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

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

Explicitly states when to use it (bring off-screen content into view before get_app_state or screenshot) and draws a hard boundary against alternatives ('It only scrolls; nothing is clicked or selected'). This is direct routing guidance rather than implied usage.

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 idempotentHint=true and destructiveHint=false, so safety is partly covered, but readOnlyHint=false is potentially confusing; the description resolves this well by clarifying 'Only the selection changes; the text is not modified.' It also documents the default selection range. It does not mention focus/in-view requirements or whether the target must already be focused, which is a real behavioral gap for a UI selection tool.

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

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

Three tight sentences: purpose first, then usage/alternative, then the non-mutation guarantee. No filler or repetition, and the most decision-relevant information 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 5-parameter mutation-adjacent UI tool with no output schema, the description covers what the action does, its non-destructive effect, and its alternative. The main omission is focus/visibility prerequisites and what happens if element_id is stale, but nothing critical to invoking 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 start, length, element_id, state_query and return_state are already fully documented. The description's default note ('from start to the end of the value') merely restates what the schema says for those params. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

States a specific verb+resource+scope: 'Select a character range inside a text element through the accessibility API.' It also explicitly distinguishes itself from set_value and type_text, so an agent can route correctly without opening sibling 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 concrete use cases ('to copy part of a value or to replace just that part with type_text') and names the alternative with its selection condition ('Use set_value to replace the whole value instead'). When-to-use and when-to-use-something-else are both explicit.

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 safety profile is partly covered. The description adds meaningful context beyond them: the previous value is discarded, rejection is reported in the result, and no keystrokes are synthesized. A small gap remains on whether this requires focus or specific element state.

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

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

Three dense sentences with zero waste: mechanism first, then preference/alternative routing, then the destructive consequence. Each sentence earns its place and the most decision-relevant information 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?

No output schema, but the description notes that rejection is reported in the result and that return_state appends fresh state, which is enough for an agent to interpret outcomes. Minor gaps remain on prerequisites such as whether the field must be focused first.

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 all four parameters, including the return_state behavior. The description adds nothing about parameter formats beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (replace/Set) and resource (a text field's entire contents) plus the mechanism (accessibility API, no keystrokes). It explicitly distinguishes itself from the type_text sibling, 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 explicit when-to-use ('prefer over type_text for long values or when the field already holds text') and a when-not/fallback path ('fall back to click plus type_text if the field rejects it'). Both the preferred case and the failure case are named with alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real context beyond them: text is inserted at the caret without clearing existing content, and password fields are refused by default with a named env override. This is meaningful behavioral disclosure, though response/error behavior is not covered.

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 when-to-use, then behavioral caveats. Every sentence earns its place with no redundancy.

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

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

Covers purpose, routing, and key behavioral caveats for a 4-param mutation tool with no output schema. Sufficient to invoke correctly, though error/return behavior is left implicit.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including element_id focus and return_state. The description reinforces element_id focusing but adds little syntax beyond what the schema provides.

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 ('Type literal text as keystrokes into the field that currently has focus') and explicitly distinguishes itself from set_value and press_key.

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 ('short entries', 'fields that reject set_value') plus named alternatives for the other two cases (set_value for long replacements, press_key for shortcuts/return/tab). Routing is fully specified.

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.