Skip to main content
Glama
Sign In
vm-relay

vm-relay

by WeZZard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Finish and deliver evidence

relay_finish
Destructive

Complete one guest's work: extract declared outputs, deliver and verify a portable evidence package, then destroy and unregister its VM; other guests keep running.

Instructions

Complete one guest's work: extract every declared output, deliver and verify a portable evidence package, then destroy the guest's VM and unregister it; the session's other guests keep running. The result reports delivery, snapshot completeness, execution outcome and human review as separate facts; a verified package is not a passing test, and a delivered package is not itself human approval. Call this, or relay_release, explicitly for every guest before you return, since ending the session does not do it for you. A declared output that was never produced is listed in incompleteExtractions and does not stop the delivery; any other failed extraction or delivery keeps the VM for a corrected attempt.

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>"
    },
    "name": "relay_finish"
  }
}

Input Schema

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

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"
+}
    • addedInput schema / required
      Added value: +[
+  "guest"
+]
  2. Addedv0.5.1

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the destructiveHint=true annotation: it names exactly what is destroyed (the guest's VM), what is unregistered, that other guests survive, that an unproduced declared output lands in `incompleteExtractions` without blocking delivery, and that other failures preserve the VM. It also warns that a verified package is not a passing test and delivery is not human approval, which is meaningful behavioral context.

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

Conciseness4/5

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

Front-loads the main action and sequences the steps compactly despite being a dense paragraph. Most sentences carry distinct, load-bearing meaning about outcomes and error behavior, though a couple of clauses could be tightened.

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

Completeness5/5

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

For a destructive, multi-step, no-output-schema tool, the description covers the important ground: the sequence of actions, what the result reports as separate facts (delivery, snapshot completeness, execution outcome, human review), and the failure semantics. Nothing an agent needs to invoke it correctly is missing.

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?

Only one parameter (guest) and schema description coverage is 100%, so the schema already documents its role. The description adds nothing about format or constraints beyond the schema, so the baseline 3 applies.

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?

States a specific multi-step verb chain (extract outputs, deliver/verify package, destroy VM, unregister) on a named resource (one guest). It clearly separates itself from siblings by noting other guests keep running, and it names relay_release as the related alternative.

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?

Explicitly instructs to 'call this, or relay_release, explicitly for every guest before you return' and warns that ending the session does not do it. It also gives the error-path condition (failed extraction keeps the VM). It stops short of stating when relay_release is preferred over relay_finish, leaving that choice slightly ambiguous.

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