VisionCLI

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

No annotations are provided, so the description carries the burden and does well: it discloses the output modality (visual bubble plus spoken audio) and hard content constraints (one or two short sentences, plain text, no markdown). It does not cover failure behavior or whether the call blocks/interrupts ongoing speech, keeping it out of 5 territory.

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

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

A single well-formed sentence with an embedded example and format constraints, front-loaded with the action. Every clause earns its place; nothing is padded.

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

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

For a one-parameter, side-effecting announcement tool with no output schema and no annotations, the description covers purpose, timing, and content format adequately. Minor gaps remain around error/failure behavior, but the tool is simple enough that this is nearly 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 baseline is 3, but the description adds real meaning to the single 'text' parameter: it constrains length (one or two sentences), content type (plain text), and format (no markdown), which the schema's generic 'as it should be spoken' does not 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 specific dual action: display a short update in VisionCLI's bubble AND speak it aloud. The medium and modality are unambiguous, and it is clearly distinct from voice/screenshot siblings like start_voice or device_screenshot.

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

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

Gives a concrete when-to-use trigger ('when background work you promised to report on has finished') with an example. It offers clear context but names no exclusions or alternative tools (e.g., start_voice), so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It says nothing about what happens after the click (navigation, new tab, page mutation), whether it waits for load, scroll-into-view, or failure behavior on missing elements.

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

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

A single front-loaded sentence with the essential action first and zero filler. Nothing is wasted.

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 one-param tool this is close to adequate, but with no annotations and no output schema the description omits any post-click consequence, leaving the agent unsure whether to re-read the page or expect a return value.

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 param is fully documented in the schema ('Element id like e12, or visible text'). The description merely restates the same id-or-text duality, adding no syntax or format detail beyond the schema. 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 (click) and resource (element), and names the sibling browser_elements as the source of the id. However, it does not contrast with other interaction siblings like browser_type, so differentiation is only partial.

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

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

The parenthetical '(or by its visible text)' implies a usage style, and referencing browser_elements hints at a prerequisite workflow. But there is no explicit when-to-use/when-not guidance and no alternatives named.

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

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

With no annotations, the description carries the full burden, and it does disclose one behavioral fact the schema cannot: the return value is the target's text afterwards. It still omits mutation/reversibility implications, how the drag is performed (HTML5 vs synthesized mouse events), and what happens when the drop fails — all meaningful for a notoriously flaky interaction.

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

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

A single dense sentence with the core action front-loaded, followed by applicability examples and the return value. No filler, no restating of the name or 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 2-parameter tool with no annotations and no output schema, the description covers both parameter sourcing and the return value, which is most of what an agent needs. It stops short of covering failure modes or drag-mechanism caveats, which would be valuable for such a brittle operation.

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, and the description adds a bit more: it clarifies that ids come from browser_elements, 'which lists draggables', and that visible text is also accepted for both endpoints. This helps the agent source valid values rather than guessing.

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+resource ('Drag an element onto another') and enumerates the scenarios it targets (sorting lists, boards, upload drop zones, div-based sliders). It does not, however, distinguish itself from the near-identical sibling tool `drag`, which an agent could easily confuse it with.

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

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

The use cases listed imply when this tool is appropriate, and pointing to browser_elements for ids gives practical setup context. There is no explicit when-not guidance, no statement of failure/fallback conditions, and no routing away from the `drag` sibling.

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, so safety is covered. The description adds real context beyond that: only visible elements are returned, and the payload includes dropdown options and toggle on/off state, which tells the agent what fidelity to expect. It omits viewport/iframe scope and any listing caps.

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?

One dense sentence that front-loads the element inventory and ends with the actionable id mapping. No filler, and the most decision-relevant information (what is listed, what the ids are for) comes first.

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

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

With no output schema, the description does the work of describing the return shape by enumerating element kinds, options, toggle state, and id format — sufficient for an agent to consume the result. Minor gaps remain around scope (viewport only? iframes?) and result size limits.

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

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

The tool takes zero parameters, so there is nothing for the description to compensate for; baseline 4 applies. The schema is empty and fully self-consistent with the no-argument design.

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

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

The description names a specific verb+resource: it lists visible interactive elements (links, buttons, fields, dropdowns, toggles) on the active page, and explains the id scheme (e1, e2, …). An agent can tell exactly what comes back. It does not differentiate itself from the sibling ui_elements, which is the one ambiguity left.

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

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

Usage is implied rather than stated: the ids exist 'for browser_click / browser_type / browser_select', which sketches the intended workflow of enumerate-then-act. There is no explicit when-to-use / when-not guidance, and no mention of how this differs from ui_elements or look.

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

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

With no annotations, the description carries the full burden. It discloses per-field result reporting and the follow-up submit step, but says nothing about failure behavior (abort vs. continue), whether existing text is cleared, or whether it waits for elements to be ready.

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 and dense, with each clause carrying information. The opening sentence is long and stacks several type-mapping clauses, but nothing is wasted.

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 batch mutation tool with no annotations and no output schema, the description covers value semantics, id sourcing, per-field reporting, and the next step. The main gaps are error/partial-fill behavior and pre-existing value handling, which an agent would reasonably want to know.

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 effectively 0% for the value field and the array structure, so the description must compensate — and it does, explaining that text fields take the text string, dropdowns take the option text, and checkboxes/radios/switches take true/false. The target format is only loosely covered via 'ids from browser_elements'.

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 (fill) on a specific resource (several fields of a form) and defines behavior per field type, which distinguishes it from the single-field siblings browser_type and browser_select. The batch scope is front-loaded ('in one call').

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?

Points to browser_elements for the element ids and to browser_click for submitting afterwards, and implies the alternative of one-call-per-field. It never names browser_type/browser_select explicitly, so the routing is implied rather than spelled out.

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

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

With no annotations, the description carries the full burden. It usefully discloses the observable effect of hovering and the necessary follow-up re-inspection step, which is genuinely behavioral context. It omits timing concerns (hover menus may need a wait before they render), whether hover state persists, and failure behavior when hover reveals nothing.

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

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

Two tight sentences, front-loaded with the action and its purpose, followed by the required next step. Every clause earns its place, though naming browser_elements twice is slightly repetitive for such a short description.

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

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

For a one-parameter interaction tool with no output schema and no annotations, the description covers what it does, why, and the follow-through workflow. Only the timing/robustness caveats are missing, which is a minor gap at this complexity level.

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 the single target parameter, so the schema already documents both the id format (e12) and the text/image-description fallback. The description only adds the provenance of the id ('from browser_elements'), which is marginal beyond the schema.

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

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

States a specific verb (hover) and resource (element) and immediately distinguishes itself from click-style siblings by declaring what hovering reveals: menus, captions, tooltips. An agent can tell it apart from browser_click or browser_elements 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?

Provides a clear workflow context - hover to expose hidden UI, then call browser_elements to see and click what appeared. It implies the 'when' (revealing hover-gated menus) without explicitly stating when not to use it or naming a competing sibling as an alternative.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. Critically, 'close' is a destructive action that is never flagged as such, and there is no mention of what happens when back/forward has no history, whether reload discards form state, or whether 'new' opens a tab or a window.

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?

One short, front-loaded sentence with no filler, so it is not bloated. However, for a five-action tool this brevity reflects under-specification rather than efficiency; the title is doing work the description should be doing.

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

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

With no annotations, no output schema, and no parameter documentation, the description is the only prose an agent gets, and it omits the action set, the target of each action, and the result of destructive ones. It is not adequate for a multi-mode browser control 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?

The single parameter has 0% schema description coverage — only bare enum values — and the description adds no meaning to any of them. It never clarifies that 'new' creates a tab, that 'close' targets the active tab, or what state changes each action produces.

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 verb+resource pair 'Navigate the active tab' is present, but it is generic and does not enumerate the five actions the enum supports. It also under-describes two of them: 'close' and 'new' are tab lifecycle operations, not navigation, so the stated purpose is partly inaccurate. It gives no differentiation from siblings like browser_open, browser_tabs, or browser_switch_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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as browser_switch_tab or browser_open, which are the natural siblings for tab-related tasks. The agent must infer everything from the enum.

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

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

With no annotations, the description carries the full burden and usefully discloses tab behavior: it switches to an existing tab, reuses the current working tab, and only opens a new tab the first time. It does not cover failure behavior or permissions, but for an open-URL tool the key behavioral traits are present.

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 adds the critical navigation behavior without unnecessary filler. Both sentences earn their 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 no output schema, the description provides enough behavioral context to call it correctly. The main remaining gap is lack of sibling-tool differentiation.

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

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

Schema description coverage is 0%, so the description needs to compensate for parameter meaning. It explains new_tab:false clearly, but it does not explain URL format or fully document the default true behavior of new_tab.

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: opening a URL in Chrome/Brave. It clearly distinguishes itself from manual keyboard navigation, but it does not differentiate itself from sibling tools such as browser_navigate or open_url.

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 explicit usage guidance: always use this instead of Cmd+L/Cmd+T plus typing. It also explains the new_tab:false case, but it does not state when to use sibling browser navigation tools instead.

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, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape and that content is capped, which warns the agent output may be truncated. No auth, rate-limit, or pagination detail is given, but the cap disclosure is the important behavioral trait here.

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

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

Two short clauses, front-loaded with the return contents and then the differentiator. No filler sentences; every word carries information.

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

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

For a single-parameter, read-only tool with no output schema, the description enumerates the return fields and notes truncation, and the annotation covers safety. 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 description coverage is 100% and the max_chars description ('Raise it (up to 50000) only if the text you need was cut off') already explains usage, bounds and default. The description's '(capped)' merely echoes the schema, so baseline 3 is appropriate.

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

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

States a specific verb (read) and resource (the active tab), then enumerates exactly what is returned: title, URL, selected text and readable text. The comparison to a screenshot implicitly distinguishes it from device_screenshot/look, so an agent can tell it apart from siblings.

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

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

The clause 'faster and more exact than a screenshot' gives a clear selection signal against the screenshot siblings. It stops short of explicit when-not guidance or naming alternatives such as browser_elements for structured/DOM data, so it is clear context without exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose how far a single scroll moves (viewport, page, pixel amount), whether it waits for lazy content, or whether it ever fails or returns anything. For a browser-interaction tool with zero structured behavioral hints, this is a substantial gap.

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

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

One short, front-loaded sentence with no wasted words, but it is terse to the point of under-specification rather than genuinely concise. Brevity here costs information rather than saving it.

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

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

With no annotations, no output schema, and 0% parameter coverage, the description should compensate but does not. It omits scroll magnitude, return behavior, and any interaction with dynamic content, so an agent cannot predict the effect of invoking it.

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

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

The single 'where' parameter has 0% schema description coverage, and the description adds nothing about it. The enum values (down/up/top/bottom) are largely self-explanatory, but the description does not clarify semantics such as whether 'down' scrolls by a viewport or a small increment.

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

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

States a specific verb (scroll) and resource (the active page), which is clear enough to separate it from siblings like browser_click or browser_read. It does not, however, differentiate itself from other navigation-type siblings or explain the scope of 'active page' vs. tabs/windows.

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

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

No guidance on when to scroll versus using browser_navigate, browser_read, or select_region. There are no prerequisites or exclusions given, leaving the agent to infer usage entirely.

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

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

No annotations, so the description carries the burden. It adds real context (matches by visible text, works on native and custom widgets, sibling routing for checkboxes), but omits failure behavior, whether a custom combobox must be opened/expanded first, viewport auto-scroll, and what happens when option text is ambiguous or absent.

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, zero filler, with the core action front-loaded before the disambiguation rules. 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 no output schema, the description covers purpose, routing, and widget scope adequately. Only edge-case behavior (not-found option, collapsed custom menu) is absent, which is a minor gap at this complexity.

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

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

Schema coverage is 100%, so both params are already documented ('Option text', 'Dropdown id from browser_elements'). The description's 'by its visible text' and 'dropdown' wording only lightly reinforces what the schema states; no added semantics such as matching rules or format expectations.

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 (pick) and resource (option in a dropdown) and explicitly covers both native <select> and custom combobox/menu variants. An agent can distinguish it from browser_click and browser_fill 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?

Explicitly routes: use this instead of browser_click for dropdowns, and use browser_click for toggles/switches/checkboxes, with a pointer to browser_elements for their state. Both the when-to-use and the alternatives are named.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it says almost nothing: no mention of what happens on an invalid tab_id, whether the OS window is focused, whether the tab is restored or only made active, or whether it errors. Only the bare effect ('to the front') is stated.

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

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

A single front-loaded sentence with no filler; the action and the parameter provenance are both packed in without waste.

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

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

The tool is simple (one required param, no output schema, no annotations), so a short description is defensible. Still, for a state-changing view operation it should at least say what a success looks like and what occurs when the id no longer exists.

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

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

Schema coverage is 0% and the schema gives only a bare string with no format, so the description nominally does add value by naming browser_tabs as the source of the tab_id. But it does not describe the expected id format or whether ids are stable across sessions, leaving a real gap.

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

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

The description states a specific verb+resource ('Bring a tab ... to the front') and clarifies the identifier provenance ('id from browser_tabs'), which separates it from the sibling browser_tabs that lists tabs. It does not, however, contrast itself with other navigation siblings like browser_navigate or browser_open.

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

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

Usage is only implied: the agent must infer it should call this after identifying a tab via browser_tabs. There is no explicit when-to-use, no conditions under which switching is needed, and no note about behavior when the tab is already active or the id is stale.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds real value beyond the annotation by disclosing the id format ('t1.3 = window 1, tab 3') and that the active tab is marked, which shapes how the agent parses 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?

One sentence, front-loaded with the resource and scope, with the id-format detail packed into a parenthetical rather than a separate sentence. Slightly dense but nothing wasted.

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

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

For a no-param, non-mutating tool with no output schema, the description covers what is returned (tab list with ids) and the active-tab marker. It stops short of describing ordering or how many windows are covered, but that is a minor 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?

Zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description correctly avoids restating a nonexistent parameter list.

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: it lists open tabs in the front-most Brave/Chrome window. The scope qualifier 'front-most' implicitly separates it from list_windows and other browser_* siblings, though no sibling is named explicitly.

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

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

No when-to-use guidance, no mention of browser_switch_tab as the natural follow-up, and no prerequisite stated. The agent must infer that this is the discovery step before acting on a tab.

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

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

With no annotations, the description carries the burden well: it discloses that the agent clicks, types, and selects, runs at about 0.4 s per step, only types text present in the goal, and returns each step plus where it ended. It does not discuss failure modes, permissions, or side-effect reversibility, but the operational behavior is unusually well explained.

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

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

Front-loads the core action, then supplies examples, timing, input constraint, return behavior, and prerequisite in a compact sequence. Every sentence adds actionable information without padding.

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

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

Covers the essential context for a no-annotation, single-parameter automation tool: what it does, how to prepare the page, how to supply values, and what it returns. It could mention failure handling or confirmation behavior more explicitly, but the definition is complete enough to invoke 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?

The single goal parameter is fully covered by the schema, and the description adds a crucial constraint beyond the schema: every value to type must be included in the goal because it only types text that is in the goal. That materially changes how an agent should construct the parameter.

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

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

States a specific verb and resource: hand a multi-step task on the current web page to VisionCLI's Jev agent. The examples (fill a form, search and open, set filters, add to cart) make the scope concrete and distinguish it from atomic siblings like browser_click or browser_fill.

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?

Clearly indicates multi-step tasks and gives prerequisites: open the right page first with browser_open, and check the result with browser_read if needed. It does not explicitly say when to prefer atomic browser_* tools over this one, so the alternative boundary is implied rather than fully stated.

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

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

With no annotations, the description carries the full burden. It discloses one side effect ('optionally submitting the form'), but not whether typing clears the existing value, fires input/change events, waits for navigation, or what happens on a failed submit. Critical mutation behavior is undisclosed.

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

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

A single sentence with the core action front-loaded and the sibling reference and optional behavior tucked into a parenthesis. No filler, nothing to trim.

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

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

For a mutation tool with zero annotation coverage, no output schema, and 0% parameter documentation, the description leaves significant gaps: field-clearing behavior, event firing, submit side effects, and failure handling are all unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'target' (an id sourced from browser_elements) and 'submit' (submitting the form), covering two of three params, but says nothing about whether 'text' appends to or replaces existing content, or any format expectations.

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 ('Set the value') and resource ('form field') and links the target to browser_elements, which distinguishes it from browser_click and browser_read. It stops short of explicitly contrasting itself with sibling tools, but the purpose is unambiguous.

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

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

The parenthetical '(id from browser_elements)' implies a workflow prerequisite — call browser_elements first to obtain the target id — but no when-to-use/when-not guidance or alternatives are given. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing beyond the schema: no focus/activation prerequisites, no failure behavior when an element id does not resolve, no statement of what state the click mutates, and no mention of the look_after screenshot behavior. 'Supports right-click and double-click' largely restates the button enum and the count parameter description already in the schema.

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

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

A single dense sentence that front-loads the preferred targeting method before the fallback, so the most important selection rule is read first. Nothing is padded, though the parenthetical nesting (ui_elements / look / image N) makes it slightly harder to parse.

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

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

For an 8-parameter, zero-required tool with no annotations and no output schema, the description covers the core targeting semantics but leaves out failure handling, whether it focuses the target window first, and any mention of the look_after return behavior. Adequate to invoke the tool on the happy path, incomplete for the edge cases an agent will hit.

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

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

With only 50% schema description coverage, the description does meaningful work: it explains that element is an id sourced from ui_elements, that x/y are pixels in the last screenshot by default, and how the `image` index reinterprets those coordinates. It omits the `screen` boolean's distinction between screen points and screenshot pixels, which the schema covers but the description does not reinforce.

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 ('Click on the screen') and distinguishes its two targeting modes by naming the sibling tools that supply each input (ui_elements for element ids, look/image for pixels). It stops short of clarifying how this desktop-level click differs from the sibling browser_click, leaving one purpose boundary implicit.

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 marks the element-id path as 'preferred' over raw x/y coordinates and tells the agent where each targeting value originates, which is real selection guidance. It gives no when/when-not guidance against alternatives such as browser_click or drag, so it is clear but not complete.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description isn't carrying the safety burden. It adds the useful context that the source is typically a screenshot, but says nothing about what happens when the clipboard is empty or non-image, which is the main behavioral risk for a zero-param read.

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

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

A single front-loaded sentence that states the action, the resource, and a concrete example with zero filler. Nothing could be trimmed without losing 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 and no annotations about return format, the description leaves the agent unaware of how the image is delivered and how failure (no image on clipboard) is signalled. Adequate for a trivial zero-param tool, but the primary edge case an agent will hit is unaddressed.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No additional parameter meaning could be added.

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 (return) and resource (image on the user's clipboard), so the agent knows exactly what the tool fetches. However, it gives no signal distinguishing it from sibling image-capture tools such as device_screenshot or select_region.

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 parenthetical example (a Cmd+Ctrl+Shift+4 screenshot) implies the context where the clipboard holds an image, but there is no explicit when-to-use guidance and no mention of alternatives like device_screenshot for capturing an image directly.

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=true; the description adds substantial behavior the annotation grid cannot express: execution inside a read-only transaction, exactly one statement, an enumerated allowlist of statement types, and a hard 50-row result cap with the LIMIT workaround. The row cap is the kind of silent-truncation trait an agent must know before calling.

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

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

Two tight sentences: the first front-loads the operation and its constraints, the second front-loads the operational gotcha (row cap) with the remedy. No filler or restatement of the title.

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

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

With one parameter and no output schema, the description covers the essentials: allowed statements, single-statement limit, read-only scope, and result cap. It omits error/timeout behavior and the result's column shape, which are minor gaps for a tool this simple.

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 documented as a read-only SQL statement, so the baseline is 3. The description adds genuine meaning by enumerating the accepted statement prefixes (SELECT/SHOW/DESCRIBE/EXPLAIN/WITH) and the one-statement constraint, going beyond the schema's generic phrasing.

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

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

States a specific verb (run) and resource (SQL query against the project's database) and enumerates exactly which statement classes are accepted. An agent can immediately distinguish this data-query tool from the sibling db_schema introspection 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?

Gives clear operating context: one statement per call, read-only only, and 'use LIMIT' because output is capped. It does not, however, explicitly route the agent to db_schema when it needs to discover tables/columns rather than query data, so the when-not guidance is incomplete.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered (and 'Read-only' largely repeats it). The description adds real value beyond the annotations by disclosing that the connection is read from the project's .env (Laravel DB_* or DATABASE_URL) and which engines are supported (MySQL, Postgres, SQLite), which tells the agent where the data comes from.

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 clauses, front-loaded with the resource, then the connection detail, then the narrowing option and the read-only guarantee. No filler, and a reader can stop after the first clause and still know what the tool does.

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

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

No output schema exists, so the description must describe the return shape, and it does name the returned elements (tables, columns, foreign keys). It could go slightly further on how results are structured or whether foreign keys are nested, but for a single-parameter introspection tool with annotations already covering safety this is nearly 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% and the lone parameter is documented as 'Only this table', so the baseline is 3. The description improves on that by clarifying the omitted-parameter default ('Pass a table to narrow it' implies all tables are returned otherwise), which the schema does not state.

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 resource (tables, columns, foreign keys of the project's database) with the verb implied as introspection, so an agent knows exactly what it retrieves. It does not distinguish itself from the sibling db_query tool, which is the most likely source of confusion, so it stops short of a 5.

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

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

'Pass a table to narrow it' implies the exploratory/overview use case, and 'Read-only' signals it is for inspection rather than mutation. However, it never says when to choose this over db_query or when not to use it, so usage is only implied.

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

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

With readOnlyHint=true already telling the agent this is a safe read, the description adds real behavioural context: full resolution, no window chrome, and the implicit prerequisite that a simulator must be booted or a device connected. It stops short of saying how the image is returned (inline vs file path), which would be the remaining useful disclosure.

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

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

Two tight sentences, front-loaded with the core action and scope, then the usage hint. Every clause 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?

For a single-parameter read tool with no output schema, the description covers target, resolution, chrome behaviour and usage intent. The only real gap is how the capture is delivered back (inline image vs saved path), which the absent output schema leaves to the description.

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

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

Schema coverage is 0% and the schema only lists the enum values, but the description meaningfully maps them: platform ios = booted iOS Simulator, platform android = connected Android device/emulator. That is genuine semantic value beyond the bare enum, though it omits the default ('ios').

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

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

States a specific action (full-resolution screenshot) and its exact resource (booted iOS Simulator or connected Android device/emulator), plus the 'without window chrome' scope qualifier. An agent can distinguish this from browser/window capture siblings such as look or list_windows 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?

'Use it to explain or debug app UI, then find the view in code' gives clear positive context for when to reach for this tool. It does not name alternatives or state exclusions (e.g., when to prefer browser_* or look instead), so it stops short of full when/when-not 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?

No annotations are provided, so the description must carry the behavioral burden. It discloses that the drag uses the left mouse button and implies a press-move-release gesture, but it does not describe timing, button-release behavior, side effects, permissions, or what happens on failure.

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

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

The definition is a single front-loaded sentence with no wasted words. The core action and coordinate endpoints appear immediately.

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

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

For a 7-parameter interaction tool with no annotations and no output schema, the description is too sparse. It omits the optional image/screen/look_after parameters and does not explain the drag lifecycle or result behavior.

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

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

The description gives meaning to the four required coordinate parameters by identifying them as start and end points. However, with only 43% schema description coverage, the optional parameters image, screen, and look_after are not explained in the description, and the coordinate system/units are left ambiguous.

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 action and resource: a left-button drag from (x1,y1) to (x2,y2). It also lists representative outcomes such as moving files and selecting text. However, it does not explicitly distinguish itself from the sibling browser_drag or click 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 examples 'move files, select text, resize, reorder' imply when the tool is useful, but there is no explicit guidance on when to choose drag over click, browser_drag, or other pointer tools. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the result ordering (front-most first) and the fields returned. It does not mention staleness or whether minimized/off-screen windows are excluded, so it falls just 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?

Two sentences with no waste: the first defines output and ordering, the second routes to the correct usage. The key scoping/ordering 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?

With no output schema present, the description compensates by naming the returned fields and their order. For a zero-parameter read-only listing, nothing an agent needs in order to invoke or interpret it is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there is no argument semantics to explain and the schema is trivially complete. The description correctly implies a no-argument listing rather than suggesting any filtering options.

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 (on-screen app windows) and names the returned fields (ids, app names, titles) plus ordering (front-most first). It also differentiates from the sibling `look`, so an agent can distinguish it 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 prescribes when to call it: 'Use before `look` when unsure which window the user means.' This names the alternative tool and the exact condition that selects this one, 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 only declare readOnlyHint=true, so the description carries the behavioral load and does it well: it discloses the default capture target, the terminal fallback, and the screen-vs-window mode. It does not describe failure modes (e.g., missing permission, no matching window) or image format/size, leaving a modest gap.

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

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

Three sentences, front-loaded with the core action and return type, followed by default behavior and the optional targeting modes. No filler or restatement of the tool name.

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?

All five parameters are optional and fully schema-documented, and there is no output schema — the description correctly states the return is an image. Defaults and targeting modes are covered; only cross-tool routing and error behavior are absent, which is minor given the schema richness.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning on top: it explains the interaction between target and display, and the fallback semantics of under_cursor that the schema only hints at. That is genuine value beyond the structured fields.

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 — 'Take a screenshot of what the user is looking at and return it as an image' — which is concrete and unambiguous. It does not, however, distinguish itself from nearby siblings like device_screenshot or select_region, so it loses the top mark.

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

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

Gives clear operational context: default captures the window under the mouse, terminal falls back, target 'screen' captures the whole display, and a window can be picked by app/title or id. It never says when to prefer this over device_screenshot or select_region, so it stops short of explicit 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?

No annotations are provided, so the description carries the burden. It usefully discloses that a running app is brought to the front rather than duplicated, which is real behavioral value. However, it omits what happens if the app is not installed, whether a screenshot/return value is produced, and any permission requirements.

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

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

A single front-loaded sentence with the core behavior first and examples last. Every clause earns its place; nothing is padded.

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 no output schema and no annotations, the description covers the essential launch-or-focus semantics. The main missing piece is failure behavior when the named app is absent, which is a modest gap rather than a blocking one.

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

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

Schema coverage is 50%: 'look_after' is documented in the schema, while 'name' has no schema description. The examples ('Xcode', 'Slack') do clarify that 'name' expects an app name string, partially compensating. This lands at the baseline for a half-documented schema.

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

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

States a specific verb+resource ('Open an app') and clarifies the dual behavior (launch vs. bring to front), which is genuinely distinguishing. Concrete examples ('Xcode', 'Slack', 'Simulator') remove ambiguity about what counts as an app. It does not explicitly contrast with the sibling open_url or browser_open, so it falls short of a 5.

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

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

The description implies usage through its phrasing but never states when to use this over alternatives like open_url, browser_open, or browser_navigate. An agent must infer the app-vs-URL split from the tool name alone. Adequate but with a clear routing gap.

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

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

With no annotations the description carries the full burden, and it does disclose the key behavioral trait: the URL is handed to the OS default app (browser, Figma, Slack, vscode://), so this escapes any built-in browser context. It says nothing about return values, whether it blocks/waits, or failure on unsupported schemes.

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?

One front-loaded sentence with zero filler; the verb+resource lead and the parenthetical examples earn their place by clarifying supported schemes.

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 action tool with no output schema and no annotations, the description covers the core action but omits what the call returns, whether it waits for the app, and how failures surface — gaps the agent cannot fill from structured data.

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

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

Schema coverage is 50%: look_after is documented inline, but the required url parameter is not. The description partially compensates by enumerating accepted URL forms (file URLs, app deep links, vscode://), which tells the agent what can be passed, but adds no format or validation detail.

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 (open) and resource (link/file URL) plus the mechanism (default app handler) with concrete scheme examples. It is clear what the tool does, but it never contrasts itself with close siblings like browser_open, browser_navigate, or open_app, leaving the agent to infer the distinction.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The scheme examples hint at deep-link/OS-handoff scenarios, but the agent must infer that this is for external default-app opening rather than the in-page browser_* family.

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

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

With no annotations, the description carries the full burden. It usefully discloses execution semantics — space-separated keys run in order, so 'cmd+a delete' is a sequence rather than a literal string — which is behavior the schema does not express. However it says nothing about focus/permission requirements, failure behavior, or side effects, so the disclosure is partial.

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 exclusion is front-loaded in the parenthetical before the examples, and the two-sentence structure is dense with no filler. It is slightly awkward in flow (the routing caveat interrupts the definition), but every clause earns its place by adding either scope or syntax.

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 three-parameter action tool with no annotations and no output schema, the definition covers purpose, syntax, sequencing, and an explicit routing exclusion — enough for correct invocation. It does not mention what happens to non-frontmost apps or error cases, but the schema's 'app' and 'look_after' descriptions cover the surrounding context.

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 67%, and the undocumented parameter is the required 'keys'. The description compensates directly by giving valid string formats and examples of both single keys and space-separated sequences, which is meaningfully more than the bare 'string' type in the schema. The other two parameters are already fully documented in the schema, so no further description is needed there.

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

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

States a specific verb (press) and resource (key or shortcut) and immediately distinguishes it from the sibling browser-related tools. The inline examples ('enter', 'cmd+s', 'cmd+shift+p', 'tab', 'esc', 'down') make the scope of 'keys' concrete enough that an agent can tell this apart from type_text or browser_navigate 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?

Provides an explicit when-not rule with named alternatives ('not for browser navigation: use browser_open/browser_navigate'), which is exactly the kind of routing guidance that prevents misfires. It stops short of a full 5 because it doesn't clarify the boundary against text-entry siblings like type_text or click, so some ambiguity remains for non-navigation use cases.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the default action point (current mouse location) and the non-obvious direction convention (dy negative = down), but omits scroll magnitude, focus/foreground requirements, and animation/completion behavior.

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

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

Two tightly packed sentences that front-load position and direction rules with zero filler. Each clause earns its place.

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

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

For a 7-parameter, no-annotation, no-output-schema tool this is thin. The direction convention is covered, but an agent still lacks guidance on scroll amount and modality (image vs screen coordinates are left to the schema), leaving gaps for correct invocation.

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

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

Schema coverage is only 43%, so the description must compensate. It adds crucial meaning to dy/dx (sign convention, lines unit) that the bare integer schema does not, but dx is only vaguely described as 'for sideways' and x/y, image, screen, and look_after rely entirely on the schema.

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

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

States a specific verb (Scroll) and the resource/position model (x/y mouse position), which is concrete. It does not differentiate itself from the sibling browser_scroll, but for a low-level input primitive the action is unambiguous.

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

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

Provides direction semantics but nothing about when to use this scroll vs browser_scroll, how many lines a call scrolls, whether it can be repeated, or whether the target window must be focused. No alternatives are named.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the call blocks until the user finishes, and the Space/Esc escape hatches. It does not say what is returned when the selection completes.

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

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

Three tight sentences with zero waste. The core action is front-loaded, with the modifier keys and blocking behavior following in priority order.

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, non-destructive interaction tool with no output schema, the blocking behavior, cancel path, and user instruction cover nearly everything an agent needs. The one gap is what the call yields on success (coordinates, image, or confirmation).

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify, and it does not need to compensate for any undocumented inputs.

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

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

States a specific action (show native crosshair) and the exact outcome (user drags a rectangle around the part of the screen they mean). It also distinguishes itself from the window-selection path by noting Space picks a window instead, which separates it from siblings like device_screenshot and list_windows.

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

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

Gives clear in-context guidance: use this to let the user define a region, press Space for window selection, Esc to cancel, and instruct the user to make the selection. It does not explicitly contrast when to prefer this over device_screenshot or look, so it falls short of full when/when-not 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 no annotations, the description carries the full behavioral burden. It does disclose useful runtime behavior: an overlay appears, the answer renders in a bubble above the mouse pointer, and there is a screenshot variant of the shortcut. However, it omits whether the call blocks while the user speaks, whether microphone/accessibility permissions are required, and how voice mode is exited — gaps that matter to an agent deciding to invoke 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?

One sentence, front-loaded with the verb and resource before the colon, with the interaction detail following. Tight overall, though the parenthetical about Option+Command with a screenshot adds detail of marginal value to an agent's decision to 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 a zero-parameter mode launcher with no output schema or annotations, the description covers what the tool is and what the user experiences. It is nearly complete; only the blocking/permission semantics and the absence of a return-value expectation keep it from being fully sufficient.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds nothing about inputs because there are none, and the keyboard-shortcut detail is a user-side interaction rather than a parameter.

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

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

States a concrete verb and resource: 'Launch the voice overlay for this project'. No sibling is explicitly named as an alternative, but no other sibling offers a voice mode, so the purpose is unambiguous. Not a 5 because it never contrasts itself with adjacent tools like 'announce' or 'look'.

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 conveys the user-driven interaction model (user holds Option and speaks), which implies when the tool is relevant, but it never states when to call it versus alternatives or what preconditions must hold. Usage is inferable rather than prescribed.

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?

There are no annotations, so the description carries the full burden. It usefully discloses that `element` is clicked first and that `replace: true` overwrites the whole value, but it says nothing about focus prerequisites, timing/waits, or how typing interacts with existing content. Adequate but not rich for a zero-annotation mutation 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 short sentences, front-loaded with the core action and immediately followed by the mode distinction and the sibling routing rule. 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 5-param tool with no output schema and no annotations, the description covers the main call semantics and the key ambiguity (typing vs. replacing). It doesn't address return behavior or failure/timing, but look_after is already documented in the schema, so the remaining gap is 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 coverage is only 40%, so the description must compensate. It adds real meaning for `replace` (whole-value overwrite vs typing) and `element` (clicked first), but leaves `app`, `look_after`, and `text` to the schema/name. Partial compensation, so a mid score.

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 text with the keyboard') plus the two target modes (focused field, or a clicked `element`). It explicitly distinguishes itself from the sibling press_keys, so an agent can tell them apart 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?

Names the alternative tool and the exact condition that selects it: 'Use press_keys for Enter, Tab, shortcuts.' That is an explicit when-to-use-this-vs-that rule, not implied 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?

readOnlyHint=true already covers the safety profile, and the description adds genuinely useful context beyond it: the data comes from the Accessibility tree, each element carries an id plus a screen-point center, and the default target is the front app. It omits operational caveats such as the Accessibility permission requirement or what happens when the app/window is unavailable.

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

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

Two tight sentences: the first defines scope and return shape, the second gives the actionable follow-up. No filler, and the most decision-relevant content (what you get and what to do with it) 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?

With no output schema, the description carries return-value explanation well by specifying that each element has an id and a center in screen points. It is nearly complete for a one-parameter read tool, missing only failure/permission behavior.

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

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

Schema coverage is 100% for the single 'app' parameter, and its schema description already states 'App name; default is the front app'. The description's '(or a named app)' merely restates this, adding no syntax, format, or edge-case detail beyond the schema.

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

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

States a specific verb (list) and resource (UI elements of the front or named app's focused window), enumerates what is returned (buttons, fields, menus, links, tabs, text) and even names the retrieval mechanism (Accessibility). This distinguishes it from pixel-based siblings like device_screenshot or look, and from browser_elements which targets DOM content.

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 tells the agent how to consume the result: 'Use the id with click/type_text', and frames the choice against the alternative approach ('far more reliable than pixel guessing'). It stops short of stating when to prefer it over browser_elements or look, so the guidance is clear but not complete on sibling selection.

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