Windows Sandbox MCP

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

Annotations already declare this is a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it discloses the return encoding (native MCP image vs base64) and that SHA-256 integrity metadata is included. It does not, however, discuss error behavior for missing/invalid artifacts.

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

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

A single front-loaded sentence that packs the return format and integrity metadata without waste. It is efficient, though terse to the point of omitting usage context.

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 usefully documents the return payload (PNG/base64 plus SHA-256), which is the most important missing piece. But the required parameter's semantics and the tool's relationship to retrieval siblings like sandbox_download are left unexplained.

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 single parameter 'artifact_id' has only a title, no description. The description adds nothing about what an artifact_id is, its format, or where it comes from, so it fails to compensate 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?

States a specific verb ('Return') and resource ('PNG'/'file') plus the output encoding formats, so the agent knows it retrieves artifact content. However, it does not differentiate itself from close siblings like sandbox_download, sandbox_screenshot, or sandbox_collect_evidence, leaving ambiguity about when this is the right retrieval tool.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g., how the artifact_id is obtained), and no reference to alternatives. The agent must infer usage entirely from the name and sibling list.

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 destructiveHint=true and readOnlyHint=false, so write/destructive behavior is already disclosed. The description adds the opt-in CDP prerequisite, but omits what gets destroyed by click/fill actions, how references become stale, or the effect of a snapshot on DOM state.

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

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

It is a single terse sentence, which avoids bloat, but the compression sacrifices clarity. Circumlocutions like 'a fresh reference' are front-loaded without definition.

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, 0% param coverage, and a destructive multi-action tool, the description omits parameter behavior, return values, error modes, and action semantics. It is far too sparse for the tool's complexity.

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

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

Schema coverage is 0%, so the five parameters (port, text, action, reference, target_id) are undocumented in both schema and description. The description mentions 'reference' and 'port' obliquely but never defines the action enum, text payload, or target_id semantics. Full compensation was needed and is absent.

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 domain (guest CDP, DOM targets) and verb-ish operations (snapshot, click, fill), but the phrasing is compressed and cryptic. It does not clearly distinguish it from siblings like sandbox_click or sandbox_text, which appear to overlap in purpose.

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 notes an opt-in prerequisite ('Requires launch with cdp_port') and mentions fresh references, but never states when to use this tool versus sandbox_click or sandbox_text. No exclusions or alternative routing is provided.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutating nature is covered. The description adds a small amount of context by implying the click should be verified afterward, but says nothing about focus/foreground requirements, whether coordinates are absolute vs window-relative, or failure behavior.

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

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

A single front-loaded sentence with the action and coordinate source stated first, then the verification step. Efficient and free of padding, though the trailing clause is slightly clipped in 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?

No output schema exists and no annotations explain return values, yet the description says nothing about what a click returns or what 'verify state' concretely means. Combined with 0% parameter coverage and undocumented hwnd/button semantics, the definition is too thin for a 4-parameter, destructive input 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% across 4 parameters, so the description carries the burden and only partially covers it: 'guest physical desktop coordinates' conveys the meaning of x and y. The hwnd (target window, default 0) and button (default 'left') parameters are left entirely unexplained, leaving no way to know valid button values or what hwnd=0 means.

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

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

States a specific verb ('click') and resource ('guest physical desktop coordinates'), which clearly separates it from sibling input tools like sandbox_keys or shell-oriented sandbox_exec. It does not name which sibling it differs from, but the action and target are 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 phrase 'from fresh inspection' implies coordinates must come from a prior inspection step, and 'verify state afterward' implies a follow-up check, giving implied workflow guidance. However, no sibling tool is named (e.g. sandbox_inspect) and there are no explicit when-not conditions or 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the notable behavioral detail that the observation record is 'host-only,' implying where evidence is persisted, but it says nothing about where artifacts are written, naming, or whether repeated calls overwrite prior evidence. 'Save' is slightly at odds with readOnlyHint, but saving a new evidence artifact is a common convention for read-only capture tools, so this is context rather than a true contradiction.

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 verb front-loaded and no filler. The item list is dense but each element carries information about scope; a short clause on output location would have been the only addition worth its length.

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 zero parameters and no output schema, the description is the agent's only source of information, and it covers what is collected but not where evidence lands or how it is retrieved afterward (presumably via sandbox_artifact). Adequate for a no-arg capture call, but the retrieval link is left implicit.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The enumerated evidence types are the only variable part of the call, and they are adequately conveyed.

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 ('Save') and enumerates the evidence types it captures (screenshot, window list, UI inspection, hashes, host-only observation record), so the agent knows exactly what this tool produces. It does not, however, distinguish itself from overlapping siblings like sandbox_screenshot, sandbox_windows, and sandbox_inspect, leaving the agent to infer that this is the bundled/aggregate variant.

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 to use this composite collector versus the individual siblings (sandbox_screenshot, sandbox_windows, sandbox_inspect), nor any prerequisite or ordering guidance. The only implied usage is 'capture everything at once,' which the agent must infer from the enumerated item list.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful clarification that it 'does not start Sandbox,' but does not explain what prerequisites are checked or what the output looks like.

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 extremely concise and front-loads the core purpose before the non-action clarification. Every word earns its place.

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

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

For a zero-parameter, read-only diagnostic tool with annotations covering safety, the description is nearly complete enough. It could say more about the expected result, but invocation requires no additional information.

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

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. The baseline for zero-parameter tools is 4.

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 ('Report host prerequisites') and explicitly distinguishes itself from the start sibling by saying it 'does not start Sandbox.' It is clear enough for an agent to identify the tool, though 'host prerequisites' is still somewhat broad.

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 checking prerequisites and clarifies that it does not start the sandbox, which helps exclude sandbox_start. However, it gives no explicit when-to-use guidance, prerequisites, or named alternatives, so usage is only implied.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral constraint, the 4 MiB cap, plus the scoping of the source to the guest C:\work area. It does not explain oversize failure behavior or what the returned artifact reference looks like, but the size limit is real value beyond 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 front-loaded sentence with the verb first, zero filler, and the size constraint folded in without a second clause. Nothing to trim.

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

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

For a trivial one-parameter tool whose annotations already carry the safety profile, the description covers operation, direction, scope and the size limit. The main gaps are the format of the returned artifact identifier and error behavior on oversize, but these are minor against an otherwise tight definition.

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 the single 'path' parameter, so the description must carry the load. It adds meaning by indicating the path resolves to a guest C:\work file, but gives no format guidance (absolute vs relative, drive handling, quoting). Partial compensation, not full.

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 (Copy), source (guest C:\work file) and destination (host-owned opaque artifact), so the direction is unambiguous and clearly opposite to the sandbox_upload sibling. It stops short of naming the alternative explicitly, but the operation is decipherable 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?

There is no when-to-use or when-not-to-use guidance and no reference to alternatives like sandbox_artifact or sandbox_collect_evidence. Usage is only implied by the verb; an agent must infer that this is the tool for pulling a file off the guest.

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 real behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=false): stdout/stderr are bounded, exit code and timeout status are returned, and child processes are killed on completion. It still doesn't say what permissions are required or how 'bounded' is enforced, but the process lifecycle disclosure is valuable.

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

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

Two dense, telegraphic sentences with zero filler and the core action front-loaded. Slightly clipped to the point that clarity suffers, but nothing needs to be cut.

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

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

No output schema exists, so the description correctly steps in to say what comes back (stdout/stderr bounds, exit code, timeout status). However, for a destructive execution tool it omits prerequisites (sandbox state), input format, and what happens to the guest environment after the command runs.

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 does nothing to compensate: it never says whether 'command' is a full PowerShell script, a single command, or a base64 payload, nor what 'timeout' does when exceeded (the 'timeout status' phrase hints at it but never states it kills the run). Two undocumented params leave an agent guessing at call syntax.

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

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

States a concrete verb+resource: run PowerShell in the guest. The execution semantics distinguish it from capture/UI siblings like sandbox_screenshot or sandbox_click, though it never explicitly names a sibling or the boundary with sandbox_launch/sandbox_upload.

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

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

No when-to-use guidance, no prerequisites (does the sandbox need to be started first?), and no exclusions. The agent must infer from the name alone that this is the tool for arbitrary command execution rather than one of the other 17 sandbox_* 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description does add real value with "in a killable guest worker," signalling isolation and timeout tolerance, but says nothing about output format, tree size, or failure behavior.

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

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

It is short and front-loaded, but the two telegraphic fragments read as under-specified rather than disciplined prose. No sentence is wasted, yet the brevity costs comprehension.

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

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

For a 5-parameter UI inspection tool with no output schema, the description omits what is returned (a node/element dump), what hwnd=0 defaults to, and how max_nodes/timeout affect results. Annotations cover safety but not the operational picture an agent needs.

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% across 5 params, so the description must compensate, and it only partially does: it enumerates the backend values (auto/uia3/uia2/ia2/win32) and view values (control/raw/content) without mapping them to the backend/view parameter names. hwnd, timeout, and max_nodes are entirely 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 verb "Inspect" is present and the backend/view vocabularies hint at UI accessibility-tree inspection, but the object of inspection (a window's element tree via hwnd) is never named. It does not distinguish itself from siblings like sandbox_windows or sandbox_collect_evidence, so an agent must infer its role.

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

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

No when-to-use statement, no exclusions, and no named alternatives. The mention of backends and views describes the tool's options but never says when an agent should pick this over sandbox_windows or sandbox_screenshot.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered by structured data. The description adds only 'guest' (it targets the guest OS, not host) and 'verify afterward,' but says nothing about focus requirements, what happens if no window has focus, or which window the keys hit.

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 action front-loaded; examples are packed efficiently. The trailing 'verify afterward' is slightly disjointed but does not bloat the text.

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?

Placeholder.

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 carries the full burden. It partially compensates for 'chord' via examples, but gives no syntax rules for combining keys, and 'hwnd' is completely unexplained in both description and schema.

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

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

The description gives a specific verb and resource ('Send guest shortcut') and supplies concrete chord examples (CTRL+A, ALT+F4, ENTER, TAB), so an agent knows it injects keyboard input into the guest. It does not explicitly contrast with sandbox_text or sandbox_click, which are the nearest siblings, so it stops short of full sibling differentiation.

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

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

There is no when-to-use guidance or exclusion criteria. The only guidance is the trailing 'verify afterward,' which hints at a workflow step but never states when to prefer this over typing text (sandbox_text) or clicking (sandbox_click).

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=false, so the mutation/safety profile is covered externally. The description adds some behavioral detail beyond them: the accessibility flag injects a Chromium flag and the CDP port is scoped to guest loopback. This is genuinely useful but terse and cryptic for a destructive launch 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?

Two short, front-loaded sentences with no wasted words. It is efficient, though the second sentence compresses several distinct behaviors into a slightly opaque clause.

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

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

For a 4-param, all-optional tool with no output schema, the description covers some flag side effects but omits what the tool returns, what the default executable implies, and any interaction with the guest lifecycle siblings. Adequate but with clear gaps for a destructive launch 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 must carry parameter meaning. It touches three of four params (arguments are quoted, accessibility adds a Chromium flag, cdp_port is guest loopback) but leaves executable unexplained and gives no format/defaults detail, only partially compensating 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 a verb ("Launch") and a resource ("guest GUI"), which gives a rough sense of the action. However, "guest GUI" is vague and the description never distinguishes this tool from the many related siblings (sandbox_exec, sandbox_start, sandbox_browser), so an agent cannot confidently route between them without opening schemas.

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

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

There is no explicit guidance on when to use this tool versus the host of sibling launch/exec/browser tools, and no prerequisites or exclusions are stated. The reader must infer the entire selection 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 destructiveHint=true, and the description adds the crucial consequence the annotation can't express: the guest disk is not recovered, so prior state is permanently lost. It does not mention rate limits, permissions, or whether other host-side resources survive, so it falls short of a 5.

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

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

Two short sentences, the destructive effect is front-loaded, and every clause carries information. No padding whatsoever.

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 destructive tool the description covers the single most important fact (irreversible disk loss), and there is no output schema to explain. However, with zero parameter documentation and no mention of permissions or side effects on host resources, it leaves the caller under-informed for a 3-parameter destructive operation.

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

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

Schema description coverage is 0% and all three parameters (memory_mb, networking, startup_timeout) are bare titles with defaults. The description supplies no meaning for any of them, leaving the agent to guess units, valid ranges, and whether they affect the fresh session's configuration.

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?

"Destroy current guest and create fresh session" gives a specific verb pair and the resource it acts on, clearly distinguishing a restart/reset from the sandbox_start/sandbox_stop siblings in the lifecycle family. It stops short of explicitly naming those siblings, so it is clear but not fully differentiated.

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 guidance on when to choose this over sandbox_start, sandbox_stop, or sandbox_launch, all of which live in the same lifecycle family. The only hint is the implied intent of wanting a clean state, which the agent must infer.

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 readOnlyHint=true, non-destructive, non-open-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the result is an artifact rather than inline data, and a specific second tool is needed to fetch it.

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

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

One compact sentence, front-loaded with the action and resource, with the retrieval hint as a trailing clause. Nothing is padded or repeated.

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-arg capture tool with a clear artifact handoff and annotations covering safety, this is nearly sufficient. The only gap is that the artifact identifier/handle returned is not mentioned, though an agent can discover that via sandbox_artifact.

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 zero parameters and 100% schema coverage there is nothing to document; the baseline for a no-argument tool applies. The description correctly avoids inventing parameters and instead explains the artifact handoff.

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?

Specific verb (capture) plus a precise resource (guest virtual desktop) and output form (PNG artifact). It also distinguishes itself from sibling tools by pointing at sandbox_artifact for retrieval rather than implying inline image return.

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

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

It clearly states the follow-up workflow — capture here, retrieve via sandbox_artifact — which tells the agent how this tool fits with a sibling. It does not, however, say when to prefer this over sandbox_windows or sandbox_browser, so conditional guidance is incomplete.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates state. The description usefully adds the security caveat that enabling networking exposes the guest to the host/LAN, but leaves unexplained what "owned" means, what happens on resource exhaustion, and what startup_timeout governs.

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, with the action front-loaded and the caveat second. However, the terse style tips into under-specification rather than disciplined conciseness, and "owned" is never clarified.

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 state-creating tool with no output schema, no parameter descriptions, and a broad sibling set, the definition omits what is produced, resource defaults/limits, and startup behavior. Annotations cover the safety profile but not the operational details an agent needs.

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% across three parameters, so the burden falls on the description, which only alludes to networking (via the opt-in warning). memory_mb and startup_timeout receive no explanation at all, leaving two of three parameters 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?

States a specific verb and resource ("Create owned Sandbox"), which separates it cleanly from siblings like sandbox_stop, sandbox_exec, and sandbox_status. The word "owned" is unexplained and the name/description mismatch (start vs. create) is mildly confusing, but the core action is unambiguous.

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

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

No guidance on when to call this versus alternatives such as sandbox_launch, sandbox_restart, or sandbox_windows. The description gives no prerequisites or conditions that would tell an agent which sibling to pick.

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, destructiveHint=false, and openWorldHint=false. The description adds that it returns retained artifact metadata, which is useful context beyond the annotations, but it does not explain what 'session state' includes or the response format.

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 that is front-loaded with the verb and the returned resources. It contains no filler or redundant 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?

Given the low complexity (no parameters, no output schema) and annotations that already cover the safety profile, the description provides enough return content for an agent to invoke the tool correctly. It could specify what 'session state' includes, but it is adequate.

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 are zero parameters, so there is no parameter semantics to convey and the empty schema needs no additional explanation. Baseline 4 applies for a 0-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?

States a specific verb ('Return') and two resources ('session state' and 'retained artifact metadata'). It is clear what the tool does, but it does not differentiate itself from siblings like sandbox_doctor or sandbox_inspect.

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

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

No when-to-use guidance or alternatives are provided. An agent cannot tell from the description alone when to prefer this over sandbox_doctor, sandbox_inspect, or sandbox_artifact.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is clear. The description adds that termination works even after bridge failure and that evidence is retained on host, which is valuable behavioral context beyond 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?

Single, front-loaded sentence with no waste. Efficiently communicates key behaviors.

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 zero params, no output schema, and clear annotations, the description covers the essential behavior (termination despite bridge failure, evidence retention). However, it doesn't mention whether evidence is automatically retained or requires a separate step, leaving minor gap.

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

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

The tool has zero parameters, so baseline is 4 per rules. No additional parameter semantics 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?

States a specific verb (Terminate) and resource (owned Sandbox), distinguishing it from siblings like sandbox_restart or sandbox_start. However, it doesn't explicitly differentiate from other stop-like siblings (none exist besides restart), leaving minor ambiguity.

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?

Implies usage when bridge failure occurs or when termination is needed, but does not explicitly state when to use this vs. sandbox_restart or other lifecycle tools. The condition 'even after bridge failure' provides some 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 flag destructiveHint=true and openWorldHint=false, but the description adds real behavioral context the annotations lack: input is injected at the guest level via SendInput, output is bounded to 16384 UTF-16 characters, and the host clipboard is deliberately not used. This is genuinely useful for predicting side effects.

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

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

A single dense sentence with the mechanism and the two key constraints front-loaded; nothing is wasted. The clipped telegraphic style is efficient but slightly at the cost of readability.

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 small two-parameter tool with no output schema and annotations covering the safety profile, the description is adequate on mechanism and limits. However, the undocumented hwnd parameter and absent guidance versus sandbox_keys leave a 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?

Schema description coverage is 0%, so the description must carry both parameters. It partially covers 'text' with the 16384 UTF-16 character limit, but says nothing about 'hwnd' (default 0), which is entirely undocumented in both the schema and the description.

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

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

States a specific verb (type), the resource (Unicode text), and the mechanism (guest SendInput), which is more concrete than most sibling names. It does not explicitly distinguish itself from sandbox_keys, which likely also produces keystrokes, so it falls short of 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?

No guidance on when to use this versus sandbox_keys, sandbox_click, or sandbox_exec. The 'no host clipboard' note hints at a distinction but never states the selection condition, leaving the agent to infer.

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

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

Annotations already declare destructiveHint=true and openWorldHint=false, so the safety profile is partially covered. The description adds real context beyond them: a hard 4 MiB size cap and the fact that content goes into the guest filesystem rather than reading from a host path, which are concrete operational constraints not present in 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?

Two short sentences, zero filler, with the size limit and destination front-loaded and the input-type caveat kept as a compact trailing clause. Every clause carries information.

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

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

For a mutation tool with no output schema and 0% schema coverage, the description is thin: it omits whether an existing file at the target path is overwritten, how 'path' relates to the hardcoded C:\work destination, and what a successful call returns. The annotations at least carry the destructive flag, so the gap is partial rather than total.

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 and it only partly does: it clarifies that data is bytes (base64 payload) and that the target is a guest path, not a host path. However, it never resolves what the 'path' parameter means relative to the stated fixed destination C:\work, leaving the most important parameter ambiguous.

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

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

States a specific verb (Upload) and resource (bytes into the guest's C:\work directory), which is clearly distinguishable from the sibling sandbox_download. It stops short of explicitly naming the sibling/alternative, but the directionality makes the intent 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 constraints 'at most 4 MiB' and 'input is bytes, never a host path' implicitly tell the agent when this tool applies versus a host-side write, but there is no explicit when-to-use/when-not guidance or named alternative tool. Usage is implied rather than directed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description still adds a genuinely useful behavioral trait beyond that: hwnd values are only stable for the current state, warning that handles can go stale and should be re-discovered. It stops short of saying what 'visible' filters out or whether transient/minimized windows are excluded.

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, which is appropriate for a no-argument discovery tool. The compressed hyphenated phrase 'stable-for-current-state' is the one spot where brevity shades into 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?

There is no output schema, so the description carries the burden of explaining what comes back, and it only says 'windows and hwnd values' without indicating whether titles, class names, z-order or counts are included. For a zero-parameter tool with no output schema this is the minimum viable, not 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?

The tool takes zero parameters, so per the rubric the baseline is 4 and there is nothing for the description to disambiguate. It correctly avoids describing nonexistent inputs.

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

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

States a specific verb (discover) and resource (visible guest windows) plus the payload it returns (hwnd values), which is enough to distinguish it from mutating siblings like sandbox_click or sandbox_exec. It does not explicitly contrast itself with overlapping siblings such as sandbox_inspect or sandbox_screenshot, and the phrasing 'stable-for-current-state hwnd values' is jargon-heavy enough to slow an agent down.

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

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

No when-to-use guidance, no prerequisites, and no mention that the returned hwnds are the inputs other tools (e.g. sandbox_click, sandbox_text) expect. The agent must infer the tool's role purely from its name and requires this enumeration to be its own idea.

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