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

With no annotations, the description must carry the behavioral burden. It usefully discloses that non-success may have unknown effects and requires querying desktop_result before retrying, which is important safety context. However, it does not state permission requirements, which actions are destructive or reversible, or how timeout behavior affects outcomes.

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 operation and then compactly catalogs actions and retry behavior. The telegraphic action syntax is dense but purposeful, with little wasted text. It is slightly cryptic in places, but appropriately sized overall.

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 complex, mutating, has no annotations, and has 0% schema description coverage. Although an output schema exists and return values need not be explained, the description does not connect task_id, action_id, or native_id to the workflow, leaving the agent without enough information to invoke the tool correctly in all cases.

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 document six parameters. It adds substantial meaning for the action parameter by enumerating action names and argument signatures such as move(x,y) and set_text(element,text). But it leaves the required task_id, action_id, and native_id unexplained, and does not clarify timeout semantics, so it only partially compensates for the schema 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 and resource: run a permitted action on an enrolled target. It enumerates supported actions and mentions inspecting writes, which helps distinguish it from pure read tools such as desktop_screenshot and desktop_result. However, it does not explicitly contrast itself with sibling workflow 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?

It gives clear invocation guidance: use the returned target ID and coordinates, inspect to verify writes, and query desktop_result before any retry. These are meaningful sequencing and retry instructions, but it does not explicitly state when not to use this tool or name alternatives beyond desktop_result.

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 phrase "without inspecting the host desktop" usefully clarifies that this is a static/introspective report with no host probing. However, it says nothing about cost, freshness, or scope of the reported capabilities, and there is an output schema so return-value details are not required.

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 qualifier "actual" and the no-inspection clause both do work, though the phrasing is slightly dense for what is a simple introspection call.

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 parameters, an output schema, and a read-only annotation, the structural side is well covered. What is missing is the decision context: when this belongs in a workflow and how it differs from desktop_discover, leaving a real ambiguity given the sibling set.

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 schema carries no semantic burden and the baseline is 4. There is nothing for the description to disambiguate.

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 (report) and object (backend support and restrictions) are present, but "actual backend support and restrictions" is abstract about what is actually returned, and nothing distinguishes it from the sibling desktop_discover, which plausibly covers overlapping ground.

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 statement of when to call this versus desktop_discover or the task/action tools. The likely intent (check what the backend supports before invoking an action) must be inferred entirely by the agent.

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

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

No annotations are supplied, so the description carries the full burden, and it does disclose a real behavioral split: stopping owned processes versus detaching a live target without closing it. It omits anything about irreversibility, required permissions, what state the task is left in, or how the two modes are selected, which matters for a cancel/terminate operation.

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, semicolon-separated into the general action and its two variants. It is efficient, though the extreme terseness is partly what creates the ambiguity.

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?

An output schema exists, so return values need not be explained, and the dual behavior is at least surfaced. Still, for an unannotated mutation tool with an undocumented required parameter, an agent lacks the information needed to predict consequences or pick a mode confidently.

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 task_id, so nothing in either field explains what identifier is expected or where to obtain it. With one undocumented required parameter, the description should compensate but does not.

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?

It states the effect well enough (cancel work, stop processes, detach a live target) and implicitly contrasts with desktop_open_task, but the jargon 'owned fixture processes' and 'live target' never connects back to the tool's actual resource, a task identified by task_id. An agent has to infer that 'cancel work' means closing the task named in the parameter.

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 explicit when-to-use, no prerequisites, and no named alternative; the sibling desktop_open_task is only obliquely implied by the word 'close'. The clause 'without closing it' hints at a mode distinction but never says under what conditions each mode applies.

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 declares this is a safe read, so the description's main addition is that results are scoped to 'this task's' windows. It does not say whether discovery is required before desktop_action or whether results change over a task's lifetime, leaving meaningful behavioral gaps.

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 compact sentence with the core capability front-loaded and no filler. The terseness costs some clarity 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?

An output schema exists, so return values needn't be described, but for a tool requiring both task_id and action_id with zero schema documentation, the description should do more: define the coordinate space, explain task_id's role, and position discovery relative to desktop_action.

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% for both parameters, so the description must carry the burden. It explains action_id only as 'a unique request identifier' without stating the purpose (deduplication/idempotency) or format, and task_id is never explained beyond the phrase 'this task's'.

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: lists this task's owned windows and coordinate space. It is clearly distinguishable from siblings like desktop_screenshot or desktop_result, but 'coordinate space' is unexplained jargon that leaves the payload partly opaque.

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 indication of when to call this versus desktop_tasks, desktop_capabilities, or desktop_screenshot, and no statement of prerequisites beyond the implied need for a task_id. The agent must infer its place in the workflow.

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 behavioral burden and does disclose an important trait: it runs on a private display and never attaches to user apps. However, it does not describe task lifecycle, cleanup expectations, resource impact, or whether the launched environment needs to be closed separately.

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 short sentences and front-loads the launchable backends and the private-display constraint. Every sentence contributes useful 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?

The output schema means return values need not be explained, and the description covers the key isolation behavior. Still, for a tool with three undocumented parameters and no annotations, it leaves gaps around scale/outputs semantics and task lifecycle.

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 lists valid 'kind' values, which is useful, but it does not explain the 'scale' or 'outputs' parameters, their defaults, or how those values affect the private display.

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, 'Launch', and enumerates the display backends it can start, so the core purpose is clear. It also distinguishes the private-display behavior from attaching to user apps, though it does not explicitly name sibling tools for contrast.

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: launch one of the listed backends on a private display rather than attaching to existing user apps. There is no explicit guidance on when to choose this over sibling tools such as desktop_action or desktop_close_task, nor are prerequisites 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 readOnlyHint=true already present, the description adds useful behavioral context: results are durable and content-free, and images, text, and accessibility content are never persisted. It does not cover auth or rate limits, but it meaningfully clarifies what the tool will and will not return.

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 sentences, front-loaded with the core action and then the key content-exclusion detail. There is no wasted wording.

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 retrieval tool with an output schema and read-only annotation, the description covers the important non-obvious behavior: status is durable and content is not persisted. Missing usage and action_id guidance keep it from being fully complete, but the essential call context is present.

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

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

Schema description coverage is 0%, and the description never mentions the sole required parameter, action_id. The parameter name is fairly self-explanatory, but the description does not explain where the action_id comes from or what format it uses, so it does not compensate for the schema 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 gives a specific verb and resource: 'Retrieve ... action status.' The 'durable, content-free' qualifier narrows the purpose further. It does not explicitly differentiate this from sibling tools such as desktop_action, 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?

There is no explicit guidance on when to use this tool, when not to use it, or which sibling to choose. The name and description imply it retrieves status for a previously run action, but that workflow is left to inference.

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

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

Annotations declare readOnlyHint=true and the description is consistent with that. It adds genuinely useful behavioral context beyond the annotations: the output is a PNG in MCP content and the capture is never written to the audit log, which is exactly the kind of disclosure that isn't in structured fields.

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 tight sentence with the scope constraint front-loaded and the return/audit facts trailing. 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?

The return format and audit-log behavior are covered and no output schema is needed, but for a tool with three fully undocumented required parameters the description leaves a real gap an agent must guess around.

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% for three required parameters (task_id, action_id, native_id), and the description does not explain any of them. 'Enrolled window' weakly hints at native_id but gives no meaning for task_id or action_id or how they relate.

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 (Capture) and resource (the enrolled window) plus the return format (PNG in MCP content). It doesn't name or contrast with any sibling tool, so differentiation is left implicit, but the action itself 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?

There is no statement of when this tool should be used versus alternatives like desktop_result or desktop_action, nor any prerequisite or exclusion. The word 'only' hints at scoping but gives no 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's main added value is the note that operator-enrolled live windows are included in the result. It says nothing about result size, whether enrollment flags are surfaced, or any limits — a modest but real addition over 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?

One short sentence with the resource and the key scope qualifier front-loaded. No filler or redundant 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?

An output schema exists, so return values need not be explained, and with no parameters the input side is trivially complete. The only residual ambiguity is what scope "this client" resolves to and whether the list is paginated or bounded, which an agent may care about for large tenants.

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 implies no filtering input is required and that the listing is implicitly scoped to "this client."

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 this client's tasks") plus a scope detail about operator-enrolled live windows, so an agent can tell it apart from siblings like desktop_open_task or desktop_close_task. It stops short of explicitly naming those siblings as 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 listing role implies when to call it (enumerating existing tasks before acting on one), but the description never says when to prefer it over desktop_discover or desktop_capabilities, nor does it state any precondition. Usage must be inferred from the name and the enumeration framing.

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