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

The annotations already declare destructiveHint=true and openWorldHint=true, so the description does not need to repeat that. The description adds valuable behavioral constraints beyond annotations: 'No selectors or executable code' clarifies what this tool cannot do, and 'against a fresh observation' indicates that it operates on the latest observation. These details help the agent avoid misuse without contradicting any annotation.

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 two sentences long and front-loaded with the core action ('Execute one precise action'), followed by a key constraint ('No selectors or executable code') and a routing hint ('For several steps prefer computer_run'). Every sentence earns its place with no fluff or repetition.

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

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

Given the tool's complexity (multiple action kinds) and the rich schema that documents them, the description covers the essential context: single action, fresh observation, returned state, and the alternative for multi-step workflows. It does not describe the output format, but no output schema exists and the description says it returns 'the resulting state', which suffices. The destructive nature is covered by annotations. Minor missing details (e.g., that the action must target an element from the observation) are implied by the schema and the 'fresh observation' phrasing.

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 by explaining the parameters (sessionId, observationId, action). It does not. While the schema itself is detailed (listing action kinds like click, fill, scroll), the description adds no semantic meaning to the parameters. 'Against a fresh observation' hints at observationId but does not explain sessionId or the structure of the action parameter. This is a significant gap for a tool with three required parameters.

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

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

The description states a specific verb ('Execute'), a precise resource ('one precise action against a fresh observation'), and the result ('return the resulting state'). It explicitly differentiates from the sibling computer_run by saying 'For several steps prefer computer_run', making the purpose unambiguous and distinguishing it from alternatives.

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

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

The description gives explicit usage guidance: it names the alternative computer_run and the condition under which to prefer it ('For several steps'). It also implies that this tool is for a single action against a fresh observation, which clarifies when it should be chosen over other siblings like computer_inspect or computer_execute.

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 and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by distinguishing running from installed apps and noting installed apps are launchable targets. It does not, however, describe output format, ordering, or any platform-specific edge cases.

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 no filler. It front-loads the primary action and then provides the optional mode. Every word earns its place, and the description is immediately scannable.

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

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

For a simple read-only listing tool with one optional parameter and safety annotations, the description covers the essential invocation knowledge. It does not specify the exact return shape, but the absence of an output schema makes a bit more detail potentially useful. Still, the core usage is clear and complete enough.

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

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

Schema coverage is 0%, so the description must compensate. It does so by tying the 'installed' parameter to the behavior: including installed apps for launchable targets. Since this is the only parameter and its effect is clear from the description, this is strong but not exhaustive.

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

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

The description clearly states a specific action ('List'), a specific resource ('macOS applications'), and two clearly distinguished scopes: running apps vs installed apps. The phrase 'for launchable targets' also hints at downstream launch use, helping differentiate from sibling launch tools like computer_open or computer_run without naming them.

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 when to use the tool: when you need running applications, and when you need installed launchable targets. However, it does not explicitly state when not to use it, nor does it name any alternative tool. The guidance is useful but only implied, not explicit.

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

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

Annotations already show destructiveHint=true and readOnlyHint=false; the description adds genuinely useful behavioral context: the in-flight operation may complete, no further actions will be scheduled, and the caller should poll for the terminal result. This goes beyond the annotations without contradicting them.

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

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

Three short sentences with the core action first and no filler. Every sentence earns its place: what it does, how it behaves, and what to do next.

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 destructive tool with no output schema, the description covers the important operational details: partial completion, no new scheduling, and polling for the final result. It could be more complete with explicit behavior for already-finished tasks, but nothing critical is missing.

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

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

Schema coverage is 0% and the description never mentions taskId or explains how it relates to the 'current input operation'. The parameter name and required status make the intent somewhat inferable, but the description does not add explicit parameter meaning.

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

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

Description opens with 'Request cancellation' and clarifies scope as 'current input operation', so an agent can tell this aborts an ongoing task rather than listing or creating one. It differs semantically from siblings like computer_close or computer_continue, though it doesn't name them.

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

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

No explicit when-to-use or alternative guidance appears. The instruction to 'Poll status for the terminal result' is useful follow-up, but an agent is left to infer that cancel is appropriate when a running operation should be aborted.

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

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

The description meaningfully extends the destructiveHint annotation by specifying exactly what is affected: the automation browser or native session, while native applications remain open. It also discloses a required precondition: cancel and wait for running tasks first. This gives the agent concrete knowledge about side effects and sequencing beyond the annotation alone.

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 deliver all key information without filler. The primary action is front-loaded, and the caveat and precondition follow naturally. Every sentence adds value.

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 destructive close operation, the description covers the main behavioral details and the critical precondition. It does not explain sessionId provenance or return values, but there is no output schema and the operation is straightforward. Sibling tools like computer_sessions can reasonably supply the missing session ID 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 description coverage is 0%, and the description never mentions the sessionId parameter or where it comes from. The parameter name is self-explanatory to a degree, but the description does not explain how to obtain it, what format it should take, or whether it refers to an automation session vs. a native session. Given low schema coverage, the description should have compensated for this 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 uses a specific verb ('Close') and names two concrete targets: an idle automation browser or a native session. It also clarifies that native applications remain open, which helps distinguish this from a broad 'kill everything' operation. It does not explicitly name sibling tools, but the behavior is clear enough.

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

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

The description gives clear usage context: the tool is for idle automation browsers or native sessions, not for active native applications. The instruction to 'Cancel and wait for any running task first' provides explicit ordering guidance and implies this tool should not be used while tasks are still running. It does not explicitly mention alternatives like computer_cancel or computer_sessions, but the intended usage is largely inferable.

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 indicate destructiveHint=true (potential side effects) and readOnlyHint=false. The description adds context that it keeps the same 'apps, observed memory, and success conditions' and returns a new task ID, which is useful. However, it does not disclose the destructive nature explicitly, relying on annotations. There is no contradiction, so a score of 3 is appropriate—description adds some behavioral context but not the full safety profile.

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

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

Three sentences with no fluff. The key action and purpose are front-loaded, followed by behavioral context and the result (new task ID). Every sentence serves a purpose: what it does, what it preserves, and what it returns. Excellent structure.

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

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

For a tool with moderate complexity (3 params, nested object, no output schema), the description covers the essential purpose, context preservation, and the returned task ID. It could provide more details on how to structure 'inputs' or 'guidance', but the description is sufficient for an agent to understand the tool's role. Given the annotations and schema, it is fairly 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 0%, meaning the description must compensate for undocumented parameters. The description explains taskId implicitly ('continues a task') and mentions 'additional guidance' which aligns with 'guidance' parameter. 'inputs' is not mentioned explicitly but is implied by 'missing text values'. Baseline is 3 due to low coverage, and the description does add some meaning, but not comprehensive for all three parameters.

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

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

The description clearly states the verb 'continue' and the resource 'an unfinished stopped task', distinguishing it from a generic new task. It mentions preserving context (apps, memory, success conditions) and observing fresh state, which helps differentiate from sibling tools like computer_act or computer_run that likely start new actions. However, it could more explicitly contrast with siblings for higher clarity.

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 this tool is for continuing a previously stopped task, which is a clear context. It does not explicitly state when NOT to use it or name alternatives like computer_act for starting new actions. The absence of explicit exclusions is a minor gap, but the purpose is clear enough for an agent to infer intended usage.

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

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

Annotations already mark it non-read-only/destructive; the description goes beyond them by explaining the side effect (optional macOS clipboard write, which can overwrite the clipboard) and by clarifying the output is displayed-resolution rather than source resolution. A small caveat is that it does not elaborate on any other destructive or cache effects.

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

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

Three focused sentences: the first states the operation and prerequisite, the second covers outputs and the optional side effect, and the third adds the important resolution caveat. No filler or nested repetition.

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

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

The description tells the agent what the tool returns and one key behavior, but it does not provide enough instruction on required IDs or the prerequisite observation flow to guarantee correct invocation. The absence of an output schema raises the burden, making the missing parameter semantics a notable gap.

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

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

Schema description coverage is 0%, so the prose must define the parameters, but it only clarifies the clipboard option and the notion of a visible image in a fresh observation. It does not explain how to obtain or interpret sessionId, observationId, or elementId, leaving the agent to infer from names.

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?

Uses a specific verb ('copy'), a specific resource ('a visible image from a fresh browser observation'), and states the return artifacts (PNG and source URL). The mention of displayed resolution and optional clipboard makes it distinguishable from generic browser actions and computer_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?

The phrase 'from a fresh browser observation' gives a clear invocation context, and the resolution caveat implicitly guides selection when the rendered image is needed. It does not explicitly name alternative tools or exclusions, so it stops short of a 5.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description adds that it 'returns task and session IDs immediately' and that it 'remembers exact observed text for reuse,' which is useful. However, it doesn't detail the destructive aspects (e.g., what might be modified) or the open-world behavior beyond 'Jev chooses the sequence,' leaving some gaps that annotations only partially cover.

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 concise with five sentences, each adding value. It front-loads the core purpose and then covers key usage details. Some redundancy exists (e.g., 'Targets are available apps, not ordered steps' could be implied), but overall it's tight and well-structured.

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

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

Given the tool's high complexity (nested objects, 8 parameters, no output schema) and zero schema coverage, the description covers the essentials: goal, until, targets, inputs, and session ID return. However, it omits parameter behaviors for maxSteps, timeoutMs, minConfidence, and ocr, and doesn't explain the openWorldHint implications (e.g., unexpected system changes). This is a substantial gap for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain some parameters: 'targets' are apps/browsers and browsers need URL, 'inputs' require exact text, and 'until' conditions are described (e.g., field_from_memory compares to remembered source). However, it doesn't explain 'ocr', 'maxSteps', 'timeoutMs', 'minConfidence', or the finer details of 'until' variants, leaving several parameters under-explained. It adds value over the schema but not enough 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?

The description states the tool executes a goal across native apps and browsers, which is a specific verb+resource. It distinguishes from related tools like computer_act (which likely performs a single action) by focusing on multi-step goal execution. However, the term 'start one goal' is slightly abstract, and the description does not name specific siblings, relying on context to differentiate.

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 provides clear context for when to use this tool: when you have a goal that spans multiple apps or browsers, as opposed to single-step actions. It gives specific guidance on targets (browsers require URL, omitted targets discover apps) and mentions closing the session when finished, implying alternatives for single steps exist, though it doesn't explicitly name them.

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 indicate readOnlyHint=true and destructiveHint=false, so the description adds value by clarifying that this tool avoids opening apps and making paid requests, which are non-obvious behavioral traits. This goes beyond the annotations and helps the agent understand the tool's cost and side-effect profile. However, it doesn't detail what 'health' includes (e.g., does it check network? storage?), leaving some ambiguity.

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

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

The description is a single, compact sentence that front-loads the core purpose ('Check local setup') and includes key constraints ('without opening an app or making a paid model request'). Every word earns its place, and there is no fluff.

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

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

Given the tool's simplicity (zero parameters, no output schema) and the annotations providing safety details, the description is nearly complete. It clearly distinguishes this tool from siblings by emphasizing the lack of side effects and cost. The only gap is the lack of detail on what specific health metrics are checked, but this is minor for a tool with no parameters.

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

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

The tool has zero parameters, so the schema provides no parameter documentation. The description compensates by indicating the tool operates on the local setup as a whole, which is sufficient for a parameterless tool. It doesn't add syntax details, but none are needed.

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

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

The description clearly states the tool's purpose: checking the local setup without opening an app or making a paid request. This distinguishes it from sibling tools like computer_open and computer_execute, which imply other actions. However, it doesn't specify exactly what 'health' entails (e.g., CPU, memory, disk), which could be clearer.

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 when to use this tool: specifically for checking the local setup without side effects. It also hints at exclusions (not opening an app, not making paid requests), which helps differentiate it from siblings. However, it does not explicitly state when not to use it or mention alternative tools for other checks.

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?

Given annotations already declare readOnlyHint=true and destructiveHint=false, the description adds useful behavioral context: it explains that the tool returns an observation with element IDs intended as input for action tools. It also clarifies that ongoing task observations live elsewhere. No contradictions with annotations.

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

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

Three short sentences, each earning its place: the first defines the action, the second explains the output's purpose, and the third routes to a sibling. No filler or redundancy, and the core information is front-loaded.

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

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

The tool has no output schema and no parameter descriptions, so the description is the only source of guidance. It covers the general purpose but leaves out crucial invocation details (how to specify ocr, what sessionId identifies) and how it differs from computer_screenshot. An agent would likely need additional context to call it correctly.

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

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

Schema description coverage is 0%, and the description completely ignores both parameters: it does not explain what sessionId refers to or what the ocr enum values (auto, always, off) do. An agent invoking the tool is left without any hint as to how to construct the object correctly.

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: 'Read visible controls and text.' It distinguishes itself from siblings by explicitly connecting to 'element IDs for direct actions' and by referencing computer_status for running task observations, which makes the scope clear.

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

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

The description provides concrete usage context: use the returned observation and element IDs to drive direct actions photos. It also directs the agent to computer_status for task observations, naming a specific alternative. It stops short of detailing when not to use this tool versus screenshot or other inspection tools.

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 non-read-only, open-world, and destructive behavior. The description adds useful context: existing-chrome uses the personal profile and user-approved remote-debugging flow, and native OCR runs locally. It does not explain destructive side effects or permissions beyond that, but annotations lower the burden.

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

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

The description is three sentences, front-loaded with the core operation and followed by high-value details about connection, allowedOrigins, and OCR. Every sentence earns its place with no filler or 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?

Given 10 parameters, no output schema, and no schema-level descriptions, the description is too sparse to make the tool fully callable. It omits parameter semantics for most arguments, side effects, return information, and how this tool fits with sibling tools like computer_act.

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 description coverage, the description must clarify the parameters. It explains connection and allowedOrigins, and hints at browser/macOS modes via kind, but leaves url, profile, bundleId, headless, recordVideo, and ocr largely unexplained. This is insufficient for a 10-parameter tool.

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

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

The description clearly states the tool opens a dedicated browser, connects to existing Chrome, or opens a native macOS app, giving a specific verb and resource. It does not explicitly contrast sibling tools like computer_act or computer_inspect, but the three modes make the purpose understandable.

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 when to use the tool (when a browser or macOS app is needed) and gives setup guidance for allowedOrigins. However, it never names sibling tools or states when not to use this tool, leaving the when-to-use guidance implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds useful behavioral context: 'Jev chooses actions; code independently verifies completion' and 'This tool operates the target app; only request actions the user authorized.' This adds some value, though the destructive nature implied by annotations is not explicitly reinforced.

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 compact and front-loaded: it states the core action first, then requirements, behavior, and safety in four sentences. No sentence is wasted and the most decision-relevant information appears early.

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

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

Given the high complexity (7 params, nested until objects, no output schema), the description covers the essential purpose and key constraints but omits how maxSteps, timeoutMs, and minConfidence affect behavior. It also does not mention how to use the returned ID with sibling tools like computer_status or computer_continue, which would help an agent after calling this tool.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It meaningfully clarifies the 'until' parameter ('at least one observable until condition', 'All until conditions must pass') and hints at the 'inputs' parameter ('Supply exact text in inputs'). However, sessionId, maxSteps, timeoutMs, and minConfidence receive no semantic explanation, leaving gaps.

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: 'Start a bounded Jev automation task and immediately return its ID.' This clearly conveys what computer_run does. However, it does not explicitly differentiate from siblings like computer_act or computer_execute, so it stops short of full sibling 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?

The description gives clear usage requirements: supply exact input text, provide at least one observable until condition, and ensure all conditions pass. It also indicates this is for bounded automation tasks. It provides good context but does not explicitly state when to choose this over alternatives or when not to use it.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds value by disclosing the permission requirement for native capture, which is a behavioral prerequisite not covered by annotations. It does not, however, explain any side effects, error behaviors, or limitations beyond permission.

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

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

The description is a single, front-loaded sentence that immediately states the output and target, followed by a necessary permission note. Every word adds value, with no redundancy or 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?

The tool is simple, with one parameter and no output schema. The description explains the return type (PNG) and the capture source. However, the lack of any parameter explanation leaves a gap in completeness, as the agent cannot determine what sessionId refers to without additional context. The permission note adds operational context but does not cover parameter semantics.

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 sole parameter sessionId is not described in the input schema (0% coverage) and the description does not mention it at all. The phrase 'controlled browser tab or native window' implies a session context, but the description fails to explicitly link sessionId to identifying the target session. This leaves the parameter's meaning unclear to an agent.

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

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

The description clearly states the tool's function: returning a PNG of the controlled browser tab or native window. It specifies the resource and output type. It does not explicitly differentiate from sibling tools like computer_copy_image, but the purpose is unambiguous enough for an agent to infer its use.

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 mentions a critical prerequisite (Screen Recording permission for native capture), which is a usage condition. However, it does not provide guidance on when to use this tool versus alternatives, nor does it state exclusions. The permission note is the only usage-related detail.

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 and destructiveHint=false, so the safety profile is covered. The description adds the useful scoping detail that sessions are owned by the local MCP process, but it does not explain return format, ordering, or what a 'session' contains.

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

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

A single, front-loaded sentence with no wasted words. Every part contributes meaning: the action, the resource, and the ownership scope.

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

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

For a simple, parameterless, read-only list tool, the description conveys enough to call it correctly. The only minor gap is not describing the shape of the returned session list, but the tool's simplicity and annotations mitigate that need.

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

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

The tool has zero parameters and 100% schema coverage, so there is no parameter meaning for the description to add. Per the zero-parameter baseline, this is well-served.

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?

Uses a specific verb ('List') and a specific resource ('sessions owned by this local MCP process'). The scoping phrase clearly differentiates it from sibling tools like computer_status or computer_health, which concern overall state rather than process-owned session enumeration.

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 the tool is for enumerating sessions, but it does not explicitly state when to use it versus siblings or mention any exclusions. An agent can infer the use-case, but there is no direct routing guidance.

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

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

Annotations already mark the tool read-only and non-destructive; the description goes further by disclosing that waitMs waits up to 20 seconds without busy polling, and that includeObservation returns the latest interface state. No contradiction with 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?

Two sentences, both substantive, with the core purpose front-loaded and parameter behaviors in the second. No filler or 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?

The tool is a simple read-only status query; the description names the returned conceptual groups (status, independent verification, step log, timings) and the two optional parameter behaviors. Without an output schema, a bit more detail on the response shape could help, but the description is sufficient for correct selection and call construction.

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 description coverage, the description carries the semantic load: it explains that waitMs waits up to 20 seconds without busy polling and includeObservation controls return of the latest interface state. taskId is only implied as the task selector, but that is clear from the first sentence.

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 ('Get') and a precise resource: a task's status, independent verification, step log, and timings. This clearly distinguishes it from sibling tools focused on system health, screenshots, or actions. The object of the call 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 description identifies the natural use case – retrieving task status – and adds practical guidance on waitMs as a non-busy-polling wait and includeObservation for latest interface state. It does not explicitly name exclusions or alternatives, but the sibling list and clear scope make the choice reasonably clear.

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

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

The annotations already flag the tool as non-read-only and destructive, and the description adds substantial behavioral context: the engine switches apps and stages without returning control, holds desktop ownership until completion, and leaves native apps open. It also names explicit follow-up mechanisms, making the blocking/lifecycle behavior clear.

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 seven short sentences, each earning its place: purpose, orchestration behavior, input requirements, inputsFrom semantics, desktop ownership, and monitoring/cancellation. It is front-loaded with the core purpose and contains no filler or repetition.

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 workflow tool with no output schema, the description covers what the tool does, how to structure stages, desktop ownership, and how to monitor or cancel. It does not explain return values or the behavior of optional parameters like timeoutMs and minConfidence, but those are partially encoded in defaults and schema, making the description adequate but not fully 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?

With 0% schema description coverage, the description must compensate, and it does add useful meaning for stages (goals, exact inputs, observable conditions) and precisely explains inputsFrom as copying one observed field from an earlier zero-indexed stage. However, it does not explain the other top-level parameters (ocr, timeoutMs, minConfidence) or the until-condition variants, leaving optional tuning behavior undocumented.

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

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

The description clearly states the tool starts an ordered macOS workflow in one call and distinguishes it from step-by-step interaction by noting it switches apps and runs stages without returning to the assistant. It does not explicitly name sibling tools, and the term 'Jev stages' is unexplained jargon, which slightly reduces clarity.

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 use for multi-stage macOS workflows and provides lifecycle guidance by telling the agent to poll computer_status or stop with computer_cancel. However, it never explicitly contrasts this tool with siblings such as computer_act, computer_run, or computer_execute, nor does it state when not to use a workflow.

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