Skip to main content
Glama
Sign In
vm-relay

vm-relay

by WeZZard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Show relay status

relay_status
Read-onlyIdempotent

Lists every guest held by the current session with VM lease, staging state, evidence path, maxGuests, project directory, VM service origin, and active environment; read-only and does not touch VMs.

Instructions

List every guest this session holds, by the name relay_acquire answered, each with its VM lease (backend binding, guest state, renewal, console observation, last error), staging state and evidence path, plus the most guests the session may hold (maxGuests), the project directory, the VM service origin and the selected environment in use; active:false when no guest's lease is being renewed. Read-only; it does not touch the VMs.

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_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered upstream. The description reinforces this ("Read-only; it does not touch the VMs") — mildly redundant but reassuring — and adds the active:false field semantics, but discloses no pagination, cost, or auth constraints beyond that.

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

Conciseness3/5

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

The content is substantive rather than padded, but it is delivered as one very long, clause-heavy sentence dense with internal jargon (backend binding, renewal, console observation, evidence path). It is not front-loaded around a single takeaway, so an agent must parse the whole run-on to extract the essentials.

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?

With no output schema, the description carries the full burden of describing the return shape, and it does so thoroughly — naming lease fields, staging state, maxGuests, project directory, VM service origin, and selected environment. An agent knows what it will get back and can call the tool correctly; only the absence of usage/exclusion guidance keeps it from a 5.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter detail because there is nothing to specify.

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

Purpose4/5

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

The description states a specific resource — every guest the session holds, keyed by the name relay_acquire answered — and enumerates the lease, staging, and session-level fields returned. It is easy to tell this is the introspection/status sibling of relay_acquire and relay_release, though it never names a sibling to make that distinction explicit.

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

Usage Guidelines3/5

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. Usage is only implied: an agent infers this is the call to make when it wants the current session's guest/lease state. Nothing warns about when another sibling would be more appropriate.

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