Skip to main content
Glama
Sign In
vm-relay

vm-relay

by WeZZard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Cancel console viewing

relay_console_cancel

Cancel an open or uncertain console-viewing attempt to close its resources without releasing the VM.

Instructions

Cancel an open or uncertain console-viewing attempt by console_id and attempt_id. Closes managed viewing resources only; it never releases or destroys the VM.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "guest": "<guest>",
      "console_id": "<console_id>",
      "attempt_id": "<attempt_id>"
    },
    "name": "relay_console_cancel"
  }
}

Input Schema

NameRequiredDescriptionDefault
guestYesThe guest this call acts on: the name relay_acquire answered.
attempt_idYes
console_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.15.0
    • addedInput schema / properties / guest
      Added value: +{
+  "description": "The guest this call acts on: the name relay_acquire answered.",
+  "pattern": "^[a-z0-9][a-z0-9-]{0,47}$",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "console_id",
-  "attempt_id"
-]New value: +[
+  "guest",
+  "console_id",
+  "attempt_id"
+]
  2. Addedv0.5.1

TDQS

A4.2/5.0
Behavior4/5

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

With annotations declaring non-readonly, non-idempotent, non-destructive, the description adds real value by scoping what is torn down: managed viewing resources only, never the VM. That is exactly the blast-radius context an agent needs before invoking a cancel. It doesn't discuss retry semantics or failure states, keeping it out of 5 territory.

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

Conciseness5/5

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

Two sentences, no filler, and the key scoping caveat (never releases or destroys the VM) is placed second as a guardrail. Every clause earns its place.

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

Completeness4/5

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

No output schema and thin parameter documentation, so the description must stand in for more. It covers purpose, scope of effect, and identifiers well, but leaves the post-cancel state and whether the attempt can be retried unstated.

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

Parameters3/5

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

Schema coverage is 33% (only guest is documented in the schema), so the description carries extra burden here. It names console_id and attempt_id as the identifiers but adds no format, provenance, or validity semantics beyond that, so it only marginally compensates for the gap.

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

Purpose5/5

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

Specific verb (cancel) + resource (console-viewing attempt) scoped by console_id and attempt_id, and it explicitly distinguishes itself from the release/destroy path. An agent can pick this over relay_console_open/resolve/release without opening any schema.

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

Usage Guidelines4/5

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

'open or uncertain console-viewing attempt' gives a clear trigger condition for using this tool, implying the counterpart open/resolve flows. It stops short of naming sibling alternatives or stating when not to use it, so it falls just below the explicit when/when-not bar.

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

Deploy Server

Other Tools