Skip to main content
Glama
Sign In
vm-relay

vm-relay

by WeZZard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Probe host and guest readiness

relay_probe
Read-onlyIdempotent

Probe read-only host and guest facts to choose an image and verify runtimes, catalog software, and snapshot behavior before staging or running scripts in disposable VMs.

Instructions

Read-only host and service facts, used to pick an image; it reports current owned state on its own, so call it again after context compaction rather than trusting earlier messages. Default scope: "host" reports host permissions and activity, VM service availability, and every guest this session holds with its state, not guest readiness. scope: "guest" with guest (an already-acquired guest) reports whether Node.js, which staging requires, is available, and, as facts, whether each relay_script language's runtime runs (/bin/sh, node, tsx, python3), the software the image lists in the catalog, and whether this lease's runs take snapshots, without installing or starting anything, and never claims capture readiness. Acquire one guest for each machine the work needs; several may run at once. Continue each guest in order: relay_acquire, relay_stage, relay_script, relay_image/relay_extract, then relay_finish or relay_release, called explicitly for every guest before you return.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "relay_probe"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
+}
  2. Addedv0.5.1

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses that the tool reports state on its own and must be re-invoked after compaction, that it works 'without installing or starting anything', and that it 'never claims capture readiness'. These are exactly the behavioral limits an agent needs and cannot infer from 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.

Conciseness4/5

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

Front-loaded with purpose and scope behavior, and nearly every clause carries information. It is a single dense block, though, and the workflow enumeration at the end could be broken out for faster scanning, so it falls just short of ideal structure.

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?

With no output schema and only two parameters, the description fully specifies what each scope returns and the constraints around guest acquisition and sequencing. An agent has everything needed to invoke it correctly in the relay pipeline.

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

Parameters4/5

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

Schema coverage is only 50%, but the description compensates by explaining the default ('scope: "host"') and what each scope reports, plus that `guest` must be 'an already-acquired guest' whose name relay_acquire returned. It does not restate the string pattern for `guest`, but the semantics of both parameters are otherwise well covered.

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 verb and resource ('Read-only host and service facts') and immediately gives the concrete reason ('used to pick an image'). It then distinguishes the two scopes precisely, including the caveat that host scope is 'not guest readiness', so an agent can separate this from relay_status and other siblings 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.

Usage Guidelines5/5

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

Explicitly tells the agent to call it again after context compaction instead of trusting prior messages. It also lays out the required sequencing ('Continue each guest in order: relay_acquire, relay_stage, relay_script, relay_image/relay_extract, then relay_finish or relay_release') and the cardinality rule ('Acquire one guest for each machine the work needs').

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