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

With all annotations false, the description carries the full behavioral burden and does so richly: it discloses the ownership heartbeat, that nothing is extracted automatically, that env is never baked into images, that vnc only prepares console-sharing and never opens a viewer, and that a failed step keeps the VM for repair rather than replaying uncertain input.

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 dense but mostly front-loaded, leading with the core action and required parameters. The final lifecycle sentence packs many directives and there is slight redundancy between 'One task per enclosure' and 'call this once per task,' so it is not maximally tight.

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

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

For a 7-parameter lifecycle tool with no output schema and unhelpful annotations, the description gives the agent everything needed to call correctly: prerequisites, optional-parameter semantics, a one-call-per-task constraint, next steps, and failure behavior. The lack of an explicit return-value description is mitigated by the stated handoff to relay_stage/relay_run.

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

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

Schema coverage is only 57%, but the description compensates by explaining task as a short slug, image as a key from relay_probe/relay_search, extractions as pre-declared outputs ([] allowed), ttlHours default 4, env as a credential pack, fullWorkspace as opt-in, and vnc's exact console-sharing semantics.

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

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

The opening sentence names a specific action and resource: 'Acquire one fresh VM for this task and start its ownership heartbeat.' This clearly positions it as the acquisition step and separates it from image-lookup tools like relay_probe/relay_search and later stage/run 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 explicit preconditions ('Requires task, image, extractions') and lifecycle direction ('Continue with relay_stage, relay_run ... relay_finish or relay_release'), plus an exclusion: 'call this once per task, not again for another task.' It does not name an alternative tool for the same purpose, but the pipeline context makes when-to-use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by explicitly stating it 'neither acquires a VM nor recovers ownership of one,' clarifying behaviors beyond the generic annotation hints. This is useful behavioral disclosure about side-effect boundaries without contradicting 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?

The description is two concise sentences with no filler. The core purpose is front-loaded, and the clarifying non-behavior sentence adds meaningful distinction without redundancy.

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

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

For a parameterless, read-only capability inspection tool with strong annotations, the description covers purpose and side-effect boundaries sufficiently. It does not describe the return format, but this is a minor gap given the simple nature of the tool and the absence of an output schema.

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 schema description coverage is 100%, so the schema fully documents that no inputs are needed. The description correctly focuses on the tool's purpose rather than parameter details. The baseline of 4 for zero-parameter tools applies here.

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 the backend's versioned VNC console options for the images it serves.' It also explicitly differentiates the tool from acquisition and ownership-recovery actions by saying it 'neither acquires a VM nor recovers ownership of one,' which distinguishes it from sibling tools like relay_acquire and relay_console_resolve.

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 inspecting capabilities without side effects, and the read-only clarification helps an agent understand not to expect acquisition. However, it does not explicitly state when to prefer this tool over alternatives such as relay_acquire or relay_console_resolve, nor when not to use it. Usage context is present but indirect.

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 signal readOnlyHint=false and openWorldHint=true; the description adds that evidence is automatic and that optional params are shared with relay_exec. However, for an arbitrary code runner it does not disclose side effects, result/output behavior, failure modes, or why openWorld semantics apply, leaving significant behavior implicit.

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

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

Three short sentences front-load the core purpose and add the only required-input details; no filler. The relay_exec reference is compact but slightly dense, so it is not quite a perfect example of concision.

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

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

For an execution tool with no output schema, high complexity, and six parameters, the description omits what the tool returns or surfaces on success/failure, and offers no routing guidance against similar siblings. It is enough to attempt a call, but not enough to invoke correctly and interpret the result 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 coverage is 67%, so the schema already documents reason, step, snapshots, and timeoutMs. The description adds that code is required up to 1 MiB and enumerates languages, but those values are largely mirrored by schema constraints (maxLength, enum); it does not explain the semantics of code beyond the name and title.

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 first sentence states a concrete action and object ('Run inline guest code') and frames it as 'this call's single recorded operation', which is distinctive. It references relay_exec but does not explicitly differentiate from siblings like relay_script or relay_run, so full sibling separation is not achieved.

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 a use case—inline guest code in a single recorded operation—and points to relay_exec as a behavioral reference. It never states when to prefer relay_code over relay_exec, relay_script, or relay_run, and gives no exclusions or prerequisites beyond the required parameters.

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 this is a non-read-only, non-idempotent, non-destructive operation. The description adds that it only closes managed viewing resources and never releases or destroys the VM, providing a clear boundary for side effects. It doesn't discuss failure states or prerequisites, but the added scoping 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?

The description is exactly two sentences, front-loads the core action, and every sentence adds value—first the operation, then the boundary. No wasted words 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?

For a simple two-parameter cancel operation, the description covers the action's effect and its non-destructive boundary. It does not explain return values or error conditions, but given this is a small tool with no output schema, that omission is minor and unlikely to prevent correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions both `console_id` and `attempt_id` as the identifiers of the attempt, but provides no additional detail about their relationship, format, or roles beyond the parameter names and regex patterns in the schema. This is minimal but adequate for a simple cancellation action.

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

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

The description states a specific action ('Cancel an open or uncertain console-viewing attempt') and clearly identifies the resource and scope ('Closes managed viewing resources only; it never releases or destroys the VM'). It distinguishes itself from related siblings like relay_console_open and relay_release by framing what it does and does not affect.

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 context for when to use the tool (canceling an open or uncertain console-viewing attempt) and an explicit exclusion ('never releases or destroys the VM'), which helps an agent decide when not to use it. However, it does not explicitly name alternative sibling tools that may be considered, leaving some inference to 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?

Annotations only indicate it is not read-only, not idempotent, not destructive, and not open-world. The description goes far beyond this by disclosing that it opens on the declared service host, never a remote client, and is never triggered automatically. It also reveals that a failed or uncertain open keeps the attempt, which is critical behavioral context for the agent to handle retries correctly.

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 dense paragraph that front-loads the core purpose and then adds necessary constraints and cross-references. Every sentence carries essential information—no filler. It is structured logically: purpose, prerequisites, behavioral constraints, and failure handling.

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 5 required parameters, no output schema, and only false annotations, the description covers all essential aspects: what it does, when to use it, where it operates, what it requires, and how to handle failures. It appropriately defers to relay_console_resolve for deeper status semantics, and nothing critical for correct invocation 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 only 20% (only 'reason' has a description). The description compensates fully by explaining that console_id and attempt_id come from relay_console_resolve, that userRequested must be true (which it enforces as const), that reason captures intent, and that expected is what the human should expect to see. This gives the agent the semantic meaning needed to construct valid calls.

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 opens with a specific verb and resource: 'Open console viewing for the owned lease', and immediately constrains it to explicit user requests. It distinguishes itself from siblings by referencing relay_console_resolve and relay_acquire, clarifying it is never automatically triggered by relay_acquire's vnc option. The purpose is unambiguous and clearly 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?

The description provides explicit when-to-use guidance: only after an explicit user request to watch. It also gives what-not-to-do: never triggered automatically by relay_acquire's vnc option. It instructs that a failed or uncertain open should be resolved or canceled rather than re-opened, effectively routing the agent to the correct alternative actions (relay_console_resolve/relay_console_cancel).

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

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

Goes well beyond the readOnlyHint, idempotentHint, and destructiveHint annotations. It discloses that the tool never recovers ownership, never establishes authentication or human confirmation, never auto-confirms the macOS sharing choice, and that view-only limitations persist even after transport connects. No contradiction with 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?

The core action is front-loaded in the first sentence, and every subsequent sentence adds meaningful caveats or routing guidance. The description is dense and somewhat long for a zero-parameter refresh action, but the platform-specific warnings justify most of the 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?

The description explains the meaning of a 'ready' result, the operation's limitations, the macOS prerequisites, and the cancellation alternative, which is strong context given zero parameters and rich annotations. It does not spell out the exact response shape or possible status values beyond 'ready,' but that is a minor gap.

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

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

The tool has zero parameters, so the schema is trivially complete and there are no parameter descriptions needed. The description adds useful contextual semantics by referring to 'this session' and 'the owned lease,' which frames the scope of the operation. This is the appropriate baseline for a no-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 the specific action: 'Refresh this session's non-secret console-viewing status for the owned lease.' It clarifies this is read-only, never recovers ownership, and contrasts with viewer-launching behavior by noting it carries no screenshots and never establishes authentication or displayed pixels. The 'ready' status caveat further pins down exactly what the tool does and does not confirm.

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

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

Provides explicit when-to-use guidance: 'Never replay an uncertain attempt: resolve it here, or close it with relay_console_cancel.' It also names the alternative tool and gives platform-specific prerequisites for macOS (Standard sharing of the existing console, not a new Log In session or High Performance display), so an agent knows how to interpret a successful resolution.

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 discloses many non-obvious behaviors beyond annotations: automatic before/after display snapshots, derived step recording, bounded stdout/stderr in results, VM retention on refused/uncertain/nonzero results, and the diagnostic mode's different snapshot/output behavior. This is exactly the kind of context annotations cannot convey.

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 dense but every sentence earns its place. It front-loads the core operation, then clusters optional parameters and safety/behavioral notes without fluff. Long paragraphs are justified by the tool's complexity and the high-value details they convey.

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 complex nested schema and no output schema, the description compensates fully: it explains result contents, snapshot grouping behavior, timeout bounds, diagnostic mode semantics, and safety guarantees. An agent has enough to invoke the tool correctly and interpret its return value.

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

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

Even with 83% schema coverage, the description adds meaning beyond the schema: `reason` is intent and 'never authorization', snapshots.group is for consecutive keystrokes with explicit first/member/last phases, afterIntervalMs defaults to 500 ms, and diagnostic output is a single combined `output` field. These clarifications help an agent tune calls 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 opens with a specific verb and resource: 'Run one guest command (`argv`) as one recorded operation'. It also adds a crucial scoping rule, 'never hide several interactions in one call', which distinguishes this executor from bulk or multi-step siblings. The title reinforces the same message, so an agent can select it confidently.

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: it is for single guest commands, evidence is recorded automatically, and `diagnostic: true` is for diagnosis/repair even before relay_stage. It also warns not to replay input whose effect is uncertain. It does not explicitly name sibling tools for comparison, but the guidance is sufficient for correct invocation.

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

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, leaving safety to the description. The description adds valuable behavioral context: verification of source and host hashes, rejection of path traversal, symlinks, and changed sources. It does not contradict annotations; the pull operation is consistent with readOnlyHint=false.

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, front-loaded with the core action and then adding essential constraints. Every word contributes; there is 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?

For a tool with one parameter and no output schema, the description covers what it does, the precondition (declared on relay_acquire), and the safety checks. It does not specify return values or post-pull effects, but those are likely implied by the operation name and context. Minor gap, not critical.

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% (no parameter descriptions). The description mentions 'by `names`', indicating the parameter is a list of output names, and ties it to 'already-declared extraction outputs'. This adds some meaning beyond the bare array-of-strings schema, but it does not explain format, constraints, or examples, 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?

States a specific verb ('pull'), resource ('already-declared extraction outputs'), and mechanism ('by names'). Differentiates from siblings by noting the constraint 'Only outputs declared on relay_acquire may be pulled', which clearly separates it from other relay tools like relay_acquire or relay_stage.

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 explains the intended use: pulling already-declared outputs early. It provides a clear context (outputs must be declared on relay_acquire) but does not explicitly name alternatives or give when-not-to-use guidance. Still, the context is specific enough for an agent to infer when this tool is appropriate.

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 say destructiveHint=true, and the description goes further by disclosing VM destruction, unregistration, and the delivery/verification workflow. It also clarifies important result semantics: a verified package is not a passing test, and a delivered package is not human approval, which is valuable beyond the structured 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?

The description is compact and front-loaded with the main workflow, then covers result semantics, call timing, and failure behavior. Every sentence adds distinct operational value with no filler.

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

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

For a zero-parameter finalization tool with no output schema, the description covers what the tool does, what the result reports, when to call it, and what happens on failure. Nothing critical is missing for an agent to invoke 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?

There are zero parameters and the schema is fully empty, so the baseline is 4. The description adds no parameter-level ambiguity and needs no parameter documentation; its mention of 'every declared output' is behavioral context rather than a parameter definition.

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

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

The description states a specific verb-resource pair: 'Complete the task' by extracting declared outputs, delivering/verifying evidence, and destroying/unregistering the VM. This clearly separates it from most siblings, but it does not distinguish relay_finish from the closely related relay_release beyond saying 'Call this, or relay_release'.

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

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

It gives explicit timing guidance: call before returning because ending the session does not finalize. It also names relay_release as an alternative and describes failure behavior (failed delivery keeps the VM), but it does not specify when to prefer this tool over relay_release.

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 idempotentHint=true, but the description adds extensive behavioral context: it confirms the tool never acquires a VM, specifies format and size limits (PNG/JPEG/WebP, up to 64 MiB, 40M pixels, preview at most 2000x2000 px and 4 MiB base64), describes delivery behavior (90-second deadline, up to three attempts), and clarifies the meaning of 'attached image proves only inclusion, not inspection'. 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?

The description is dense but well-structured, with the core purpose front-loaded and technical details organized logically. While it is longer than typical tool descriptions, the complexity of the tool justifies the length. It could be slightly more concise by trimming redundant explanations, but every sentence carries 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?

Given the tool's complexity (nested anyOf target variants, no output schema, no explicit parameter documentation), the description covers all necessary aspects: usage scenarios, constraints (size, format, deadlines), error handling (`stale-reference`), and recovery workflow. An agent would have sufficient information to call the tool correctly and interpret results.

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

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

The input schema has 0% description coverage, but the description compensates fully by explaining the semantics of the `target` parameter: it distinguishes the three source types (display, application, reference), defines the fields for each (e.g., `sessionId`/`executionId`/`phase` for display; `name` and `path` for application; `imageId` for reference), and clarifies the purpose of `relay-run`. This adds meaning far beyond the raw schema structure.

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 explicitly states 'Retrieve one already-saved image' and enumerates what it is not ('never a new capture, input or directory export, and it never acquires a VM'), clearly distinguishing it from siblings. The three target forms (display, application, reference) are defined with precise semantics, leaving no ambiguity about the tool's function.

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 provides explicit when-to-use instructions, including recovery of relay_run images ('If a run's inline image did not arrive, recover it here...'), and when-not-to-use guidance ('never by repeating the input or capturing again'), with a stop condition ('stop after at most two such recovery calls'). It also mentions alternative tools for closed enclosures (host file tools). This is exemplary usage 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 read-only, idempotent, and non-destructive; the description adds that it reports current owned state and must be re-called after compaction, that guest scope installs or starts nothing, and that it never claims capture readiness. It also clarifies 'unknown is not idle.' These are meaningful behavioral details 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?

Every sentence carries distinct information: purpose, state-freshness caveat, host scope semantics, guest scope semantics, usage boundary, and workflow order. It is dense but not wasteful, and it front-loads the read-only purpose and the key re-call behavior.

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 absence of an output schema, the description summarizes what each scope reports and warns about known pitfalls (unknown vs idle, capture readiness). It also embeds the tool in the relay sequence so an agent knows when and in what order to invoke it. Some exact response structure is not specified, but the essential 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 coverage is 0% and the schema only lists an enum, but the description thoroughly explains both `scope: "host"` and `scope: "guest"` including what each reports and their caveats. This gives an agent the full semantic meaning of the only parameter, even without additional schema descriptions.

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: it probes read-only host/service facts to judge interruptiveness and pick an image. It explicitly distinguishes the two scopes and notes that `host` is not guest readiness, which separates it from a generic probe. The tool's role in the relay workflow is immediately 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?

Explicitly says when to use it: before interruptive relay work, and after context compaction rather than trusting earlier messages. It names the alternative (local tools for non-disruptive/headless work) and provides the full ordered relay lifecycle. No ambiguity about where this tool fits.

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 destructiveHint=true, but the description adds valuable context about evidence retention, success status, and retry behavior. It goes beyond the structured metadata to describe side effects and failure semantics.

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 concise sentences, front-loaded with the primary action, then the usage distinction, then retry safety. Every sentence adds necessary information with no redundancy.

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

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

For a zero-parameter destructive action with no output schema, the description covers purpose, usage, side effects, and retry behavior. Nothing an agent needs to decide to call this tool is missing.

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

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

The tool has zero parameters, so there is nothing to document. The description correctly omits parameter details, and the empty schema fully covers the interface. Baseline of 4 is appropriate.

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

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

The description explicitly states the tool destroys and unregisters the owned VM, retains evidence, and does not claim success. It clearly distinguishes itself from relay_finish by naming the alternative and the condition for 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?

It directly instructs to use this instead of relay_finish when the task is not being completed, and clarifies retry semantics (safe to retry, failed release keeps ownership). This gives explicit when-to-use and when-not-to-use 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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses a concrete behavioral trait: 'Evidence is automatic: snapshots before and after, and a step record,' and that reason/expected/afterIntervalMs only override that evidence. The caution 'Never replay an uncertain call' aligns with the non-idempotent, open-world hints. It stops short of a 5 because it does not address failure/error propagation or side-effect expectations.

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?

Four sentences, roughly 70 words, each earning its place: purpose, target enumeration, discovery routing, evidence model, and a safety caution. The core verb-resource pair is front-loaded in the first sentence, and there is no fluff or redundant restatement of schema descriptions.

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 7-parameter open-world tool with no output schema, the description covers the essential operational knowledge: target choices, forwarding semantics, the discovery prerequisite, automatic evidence, and optional overrides. Minor gaps remain — the exact return/step-record shape and the lease prerequisite implied by siblings relay_acquire/relay_release — but these do not prevent a correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning by grouping parameters into two semantic classes — tool/args are 'forwarded unchanged' (the actual remote call) versus reason/expected/afterIntervalMs as 'optional overrides' of the evidence record — a relationship the per-property schema entries only imply. This framing tells the agent which parameters affect the remote server and which only affect the step record.

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 opens with a specific verb-resource pair, 'Send one tool call to an MCP server inside the VM,' and enumerates the three valid targets with parenthetical mappings (cua, playwright, chrome-devtools). It also clarifies the forwarding semantics for tool and args, and the relay_tools reference helps distinguish this tool from its discovery sibling without opening the schema.

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

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

It explicitly routes the discovery step to the relevant sibling — 'Use relay_tools to see a target's exact tools' — which is the natural confusion point. It also states a when-not condition with 'Never replay an uncertain call' and clarifies which parameters are optional evidence overrides, so an agent knows what to supply and what to leave out.

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

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

The description adds meaningful context beyond the annotations: evidence is automatic, this is a single recorded operation, and execution happens under the staged workspace. It does not contradict the annotations. However, for a tool that executes arbitrary guest scripts, it does not disclose potential side effects, sandboxing limits, or what happens on failure, leaving the agent to infer behavioral risk beyond the basic openWorldHint and readOnlyHint flags.

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 with no filler. It front-loads the core purpose ('Run one guest script file'), then packs the essential constraints and cross-reference to relay_exec into the second sentence. Every clause 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?

For a tool with no output schema, the description is missing a critical piece: what the caller receives after execution (stdout, exit code, recorded evidence reference, error behavior). It covers invocation inputs, shared optional parameters, and workspace context, but an agent cannot fully predict how to consume the result. The nested snapshots and step objects are explained by the schema, so the biggest gap is the unspecified return/result 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 description adds meaning for the two required parameters that the schema leaves undocumented: localPath is 'a host file path' and language is restricted to 'javascript', 'typescript' or 'python'. Since schema coverage is 67%, the description compensates for the biggest gap. It does not need to re-explain step, reason, snapshots, and timeoutMs because those already have descriptions in the schema.

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

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

The description states a specific verb and resource: 'Run one guest script file as this call's single recorded operation.' It adds useful scope by calling out that this is a single recorded operation, which separates it from broader multi-step tools. However, it does not explicitly contrast it with sibling tools like relay_exec, relay_code, or relay_run, instead only referencing relay_exec for shared optional parameter semantics.

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 primary use case: run a guest script file under the staged workspace. It also states required inputs (localPath and language), which gives the agent a baseline for when the tool is applicable. But it never explicitly says when to prefer this tool over relay_exec, relay_code, or relay_run, nor does it provide exclusions or alternative 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 declare readOnlyHint and idempotentHint, but the description adds behavioral details: matching logic (exact/prefix/substring), optional os filter, return shape (installed versions possibly null, image keys, OS, architecture), and the distinction between truncated results and empty results versus catalog errors. It also clarifies it never allocates, which adds safety context 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?

The description is comprehensive yet efficient, leading with the core purpose, then matching behavior, then return semantics, and ending with what it does not do. Every sentence adds distinct value with no redundancy.

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

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

Given no output schema, the description explains return values (installed versions, image keys, OS, architecture) and handles edge cases (null versions, truncated results, empty vs error). It also specifies the optional filter. For a search tool, this covers everything an agent needs 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?

With 0% schema description coverage, the description fully compensates by explaining the 'name' parameter as matching by exact, prefix, and substring, and the 'os' parameter as an optional hard filter with enum values linux/macos. This gives meaning beyond the schema's bare property definitions.

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 opens with a clear verb 'Find' and resource 'installed application in the image inventories', and it explicitly differentiates from relay_acquire by stating it is optional before acquiring and does not choose an image. This distinguishes it from sibling tools like relay_acquire and relay_probe.

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 states it is optional before relay_acquire, and clarifies what it never does (allocates, boots, installs, reserves capacity, chooses an image), guiding when to use it. It does not explicitly name alternatives, but the context of being a search step is clear. The 'optional before relay_acquire' provides a clear usage slot.

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 all annotation hints false or unhelpful, the description carries the behavioral burden and does so richly. It discloses hash-checking, staging of support files, first-use server staging, retry semantics, the limitation that 'staging does not prove capture readiness,' and reset/resubmission behavior including the receiver-lock refusal.

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 dense paragraph with no filler. Every clause earns its place: scope, prerequisites, Linux-specific requirements, retry rules, reset behavior, and the readiness caveat are all packed in without 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 six parameters, no output schema, and no meaningful annotations, the description is unusually complete. It covers prerequisites, retry and resubmission constraints, browser default and target behavior, reset semantics, and the warning that staging does not prove capture readiness—enough for an agent to invoke it correctly after acquisition.

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 high (83%), so the baseline is 3, but the description adds meaningful context: `files` lands under `support/`, `nodePath`/`cuaDriver` must already exist, `browserExecutable` selects the launched guest browser for specific targets, and `resetRecording` archives evidence and starts fresh. It does not add meaning to `files[].local`, whose schema description is also missing.

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 opens with a specific action: 'Push and hash-check the guest runtime, plus an optional workspace and support files... onto an acquired VM.' This clearly identifies the resource and distinguishes staging from siblings like relay_acquire or relay_exec/run.

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?

Prerequisites are explicit: guest Node and CuaDriver executables must already exist, and Linux guests need native X11 plus `cua-driver serve --no-overlay`. It also defines retry/resubmission constraints and when `resetRecording` is appropriate, though it does not explicitly name alternatives or say 'use relay_stage instead of X.'

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 idempotentHint=true, so the safety profile is covered. The description adds the active:false behavior when nothing is owned and repeats 'Read-only; it does not touch the VM,' which is redundant with annotations. The added context about the active flag is useful, but overall the description provides only marginal behavioral detail beyond the annotations, earning a 3.

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 long sentence but front-loaded with the primary output (owned VM lease) and then lists the rest. It is efficient, avoids fluff, and every phrase adds information. It could be slightly more structured, but it is appropriately sized and informative.

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 has no parameters, no output schema, and annotations covering the safety profile, the description is quite complete. It enumerates all the fields the agent can expect (lease details, staging state, evidence path, project directory, service origin, environment, and active flag). The only missing element is the exact return format (e.g., JSON structure), but that is not critical for a status tool and the description suffices for correct invocation.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). The description does not need to explain parameters, and the baseline for zero-parameter tools is 4. No additional parameter information is required, so this dimension is satisfied.

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 shows the session's owned VM lease, staging state, evidence path, project directory, VM service origin, and selected environment, plus an active:false indicator. It uses a specific verb ('show') and identifies a distinct resource (relay status) with a detailed list of contents, making its purpose unambiguous. However, it does not explicitly differentiate from sibling tools like relay_probe or relay_console_resolve, though the read-only inspection nature is evident from context.

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 inspecting the current session state before or after operations, but it does not provide explicit guidance on when to use it versus alternatives. No exclusions or conditions are stated, leaving the agent to infer from the read-only nature and the listed contents. This is adequate but lacks the explicit 'when to use' framing that would merit a 4.

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 idempotentHint=true and destructiveHint=false; the description adds valuable context that it starts the server if needed without sending a tool call. This goes beyond what annotations provide, with no 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?

Two concise sentences with the core purpose front-loaded and no filler. The second sentence adds side effects and prerequisites without 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?

No output schema exists, but the description covers what is returned (names, descriptions, input schemas) and the side effect of starting the server. It also notes the prerequisite. Missing error handling is not essential for a listing tool.

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

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

Schema coverage is 100% with descriptive parameter text for both `tool` and `target`. The description adds only a minor clarification that `tool` returns just one, which is already implied by the schema. No significant extra meaning over the schema.

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

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

States a specific action ('List') and a clear resource ('a relay_run target's real tools'), and spells out what is returned (names, descriptions, input schemas) plus the `tool` option to return one. This clearly distinguishes it from siblings like relay_search or relay_probe.

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

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

Provides a prerequisite ('Requires relay_stage') but does not explicitly compare with sibling tools or state when to use this instead of alternatives. The context is clear enough to infer use, but no exclusions or alternatives are named.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds that it opens a local browser (side effect), verifies every artifact/hash/reference, and leaves human review pending. This contextual behavior 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?

Two sentences, front-loaded with the core action and scope, followed by a state note. No wasted words; the description is efficient 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?

For a tool with one parameter and no output schema, the description covers purpose, verification scope, side effect (browser open), and pending human review. It does not explain failure behavior or return value, but these are minor given the simplicity and annotations.

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 only parameter 'directory' is fully described in the schema (100% coverage). The description does not add extra parameter details beyond referring to the package directory. Baseline 3 is appropriate since the schema handles 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?

The description states a specific verb ('verify') and resource ('delivered relay evidence package') followed by an action ('open its trajectory viewer'). It clearly identifies what the tool does, and the trajectory viewer is distinct from sibling console tools, though it doesn't name an alternative explicitly.

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

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

The description implies usage: when a relay evidence package has been delivered and needs verification and viewing. It gives clear context ('delivered relay evidence package') but does not explicitly state when not to use it or name alternatives like relay_console_open. This is adequate without exclusions.

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