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

Annotations already declare idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious semantics: cancellation is cooperative and only takes effect at the next provider call or mutation, meaning the agent should not expect or poll for immediate effect. It still omits what the response looks like or how to confirm the run actually stopped.

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 written sentences with the purpose front-loaded and the behavioral caveat immediately after. Nothing is redundant and nothing extraneous remains.

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, non-destructive cancellation call the definition covers purpose and the key timing behavior. However, with no output schema present, the description says nothing about the return value or how the agent learns whether cancellation was accepted, leaving a modest but real 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?

There is a single parameter (run_id) with 0% schema description coverage, so the description technically has room to compensate. It only indirectly conveys that run_id must reference an active run; no format or sourcing guidance is given, but the parameter is a trivially understood identifier.

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 ('Request cancellation of an active run'), which is unambiguous and clearly distinct from sibling tools like observe_window or list_windows. It does not explicitly name or contrast itself with siblings, but the action is self-evident.

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?

'Active run' implies the prerequisite that the run must still be in progress, but there is no explicit when-to-use/when-not guidance, no mention of alternatives, and no statement of what to do if the run has already completed.

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 establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description is not required to restate it. It instead adds non-obvious behavioral context: the journal is redacted and omits page text, credentials, and field values, which sets correct expectations about what data will be missing. It stops short of describing the event format or ordering.

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

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

Two sentences, zero waste, and the core purpose is front-loaded ahead of the redaction caveat. Every clause earns its place by telling the agent what it gets and what it won't get.

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-parameter read tool with no output schema, the description covers purpose and the key data-availability caveat. It is nearly complete; only the journal's structure, ordering, or pagination behavior is left unspecified.

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 single run_id parameter is undocumented in the schema, so the description must compensate. "For a run" implies run_id is a run identifier, but it adds no format, source, or sourcing guidance (e.g., where to obtain the id). With only one self-evident parameter the gap is small, so a baseline 3 is fair.

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 pairs a specific verb ("Read") with a specific resource ("the redacted event journal for a run"), so the agent knows exactly what operation it performs. It does not explicitly name or contrast any sibling, but none of the siblings (run_browser, observe_window, cancel_run) overlap with journal retrieval, so confusion is unlikely.

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: reading a run's journal is the obvious way to inspect what happened during a run, and the sibling list contains no competing journal-reading tool. There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives, so the agent must infer the context.

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

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

Annotations already declare the safe read profile, so the bar is lower, yet the description adds real operational context: titles are untrusted screen text, and windows marked protected (terminals possibly hosting the caller) cannot be run_windows targets. That protected/untrusted distinction is not derivable from the schema or annotations.

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

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

Front-loaded with the core action and target_id purpose, then progressively adds filtering and safety caveats. Dense but every clause carries information; the final sentence is slightly cramped.

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

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

With no output schema, the description correctly covers what comes back (target_id, ordering front-to-back) and the filtering/safety caveats. Complete enough for a one-parameter, read-only list tool.

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

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

Schema coverage is 0% for the single parameter, so the description carries the burden — and it does, explaining that title_contains matches by title *or process name*, which is meaning beyond the bare schema property.

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

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

States a specific verb and resource ('List visible top-level Windows windows front to back') and even names the two secondary surfaces it includes (Progman, taskbar). It also declares the return contract — a target_id consumable by run_windows and observe_window — which distinguishes it from the sibling observe_window.

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 clearly implied: call this to obtain target_ids for run_windows/observe_window, which are named explicitly. What's missing is an explicit when-not or a stated boundary versus observe_window, which may also enumerate windows.

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

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

Annotations already cover readOnly/idempotent/openWorld/non-destructive, and the description adds genuinely new behavior: screenshot brings the tab to the front and costs roughly 1-1.5k tokens, contents are untrusted data, and contains filtering ignores spaces. It does not cover error cases such as a missing or closed tab, so not a full 5.

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

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

The read action and its scope are front-loaded, and every clause carries information (return payload, filter, screenshot cost, trust warning). It is a dense run-on of semicolon-joined clauses rather than clean sentences, which slightly hurts scanning.

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

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

For a no-output-schema read tool, the description covers the return payload, the filtering parameter, the screenshot trade-off (token cost plus foregrounding) and a data-trust caveat. Only the provenance/requirements of tab_id and failure behavior remain unstated.

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

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

With 0% schema coverage the description carries the load and does well: contains is defined as keeping matching items and text lines with spaces ignored, and screenshot's side effect, cost and recommended ordering ('read the text first') are explained. tab_id is only implicitly identified via run_browser(keep_tab) and never marked required.

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

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

States a specific verb (read) and resource (a browser tab kept by run_browser(keep_tab)) and enumerates what is returned (offered targets with kind/label/states plus visible page text), which separates it from observe_window and get_run_journal. The phrase 'without any input' is slightly misleading given tab_id is required, keeping it below a 5.

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

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

Gives a concrete usage scenario ('to see No results or a validation error before choosing the next goal'), which implies when to inspect. It never names alternatives (observe_window, list_windows) or states exclusions, so the agent must infer routing from the scenario alone.

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

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

Adds substantial context beyond the readOnly/idempotent/destructive annotations: no input lock, no indicator, labels are untrusted data, refs last 60 seconds, and screenshot costs ~1-1.5k tokens. It even discloses the return shape (in_focused_input on caret line, offscreen placeholders). Only slight gap is that nothing is said about pagination/truncation of very large label sets.

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

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

Front-loaded with purpose and the key distinction from run_windows, and each sentence carries distinct information (filters, item flags, screenshot cost, safety note, ref affordance). The final run-on about calling run_windows with {goal, ref} is dense and could be trimmed, but nothing is pure filler.

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

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

With no output schema, the description carries the full burden and delivers: it explains the label model (UIA vs OCR), the special item flags (in_focused_input, offscreen with placeholder rect), token cost, and the ref-based handoff to run_windows. An agent has everything needed to call it and interpret results.

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 33%, so the description must compensate, and it does: 'contains keeps only labels containing that text (spaces ignored)' and 'screenshot true adds the window image (about 1-1.5k tokens)'. This meaning goes beyond the bare schema types for two of the three params, though target_id's schema description already covers the third.

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

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

States a specific verb+resource ('Read a window's current labels') and immediately scopes it against the sibling run_windows ('as run_windows would observe them... without any input, input lock or indicator'). An agent can distinguish this read-only observation from an active run without opening any schema.

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

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

Explicitly says when to use it ('to check a result instead of starting another run') and gives conditional guidance for the screenshot param ('read the text first and ask for the image only when the text does not explain the state'). It also routes to the alternative tool with concrete instructions for acting on an item.

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 give only openWorldHint/idempotentHint/destructiveHint, but the description discloses far more: tab lifecycle (opened at start_url, closed at end unless kept), failure semantics (run stops at first goal not done, rest returned in remaining_goal_ids), allowed_origins defaulting rules, fill_values meaning, and the contents of final_state and out_of_reach. Nothing here contradicts the annotations.

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

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

Purpose is front-loaded in the first sentence and each subsequent sentence carries distinct operational content (tab lifecycle, failure semantics, origin scoping, result shape). It is a dense block rather than a bulleted structure, which costs a point, but no sentence is filler.

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

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

With no output schema, the description still enumerates the return payload (final_state with url/title/rejected fields/downloads/form values/text lines, unmet_effects, remaining_goal_ids, tab_id, out_of_reach/screen_target). For a 12-parameter, nested-object, open-world tool this is unusually 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 description coverage is only 8% across 12 parameters, so the description must compensate. It explains goals ordering, keep_tab, tab_id continuation, start_url omission, allowed_origins defaults, and fill_values — a solid share — but says nothing about run_id, deadline_ms, action_budget, provider_attempt_budget, or denied_operations. Useful but incomplete compensation for the coverage gap.

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

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

Opens with a specific verb+resource+scope ('Run one or more browser goals in order') and immediately distinguishes itself from siblings by naming observe_browser ('a separate observe_browser is needed only for more than that') and run_windows ('screen_target, the window run_windows can act on'). An agent can route between these tools without opening a schema.

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

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

Explicit when-to-use and when-not-to-use guidance: put every known step, including post-click navigation, in one run; a later goal never runs after an earlier failure; use a separate observe_browser only when final_state is insufficient. It also states the tab continuation contract (keep_tab true → tab_id → later run with that tab_id, start_url may be omitted).

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

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

Goes well beyond the annotations: it discloses the input mechanism (SendInput after foregrounding vs UIA patterns when synthetic_input_allowed is false), the default allowed_operations set and the full alternative list, the drop_target_id contract, the provider_uncertain/blocked failure modes, and that screen_candidates are untrusted data. This is unusually rich behavioral context for a destructive, open-world 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?

Front-loaded with the core operation, but it is a dense, semicolon-heavy wall of text, and several statements (routing, drop_target_id, target_id format) restate text already present in the input schema, adding length without new meaning.

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

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

For a complex 12-parameter tool with no output schema, the description covers the operational flow, failure modes, and even return-relevant concepts (final_state, screen_candidates). The remaining gap is that the numeric budgets and run_id are never explained, so an agent cannot reason about timeouts or run continuation.

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 33%, so the description must compensate, and it does add real meaning for fill_values (goal id: exact text), allowed_operations (defaults plus the full alternate list), drop_target_id, routing, and synthetic_input_allowed. However, run_id, deadline_ms, action_budget, provider_attempt_budget, and app_annotations are left completely opaque, so the gaps roughly match the covered parameters.

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

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

The opening sentence states a specific verb and resource with scope: 'Run Windows UI goals in order on one window.' It also distinguishes the Windows path from the browser path via routing, but the sibling differentiation (vs run_browser/observe_window) is embedded in later routing detail rather than stated crisply up front.

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

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

Explicit when-to-use conditions are given for the key decision points: when to use windows_only vs browser_if_singleton, when to pass a ref instead of restating a goal, and what to do when a goal ends provider_uncertain or blocked. Alternatives and their selecting conditions are named, not implied.

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