Skip to main content
Glama

relay

Perform computer and browser tasks in a disposable VM, capturing snapshots as evidence.

Instructions

One VM enclosure interface. Required action; run and console-open require intent in reason. search: required application name, optional hard os linux/macos; exact, prefix, substring canonical-name/alias matching. Returns installed versions (possibly null), image keys, OS and architecture; truncated means whole installations were omitted. No allocation, boot, installation, capacity reservation or automatic image choice. Empty success is distinct from catalog errors. probe: default scope=host reports host permissions/activity, VM service availability and owned lifecycle state, not guest readiness. scope=guest checks executables on the owned guest before staging or after repair without installing software; capture/browser readiness remains unverified. Unknown is not idle. acquisition-capabilities: read-only versioned VNC options, no acquisition or ownership recovery. console-resolve: read-only status for the owned lease/environment. console-open: explicit user request only, require userRequested=true, console_id, attempt_id, reason and expected; opens on service-host only, never automatically at acquisition. console-cancel: require console_id and attempt_id; closes managed viewing resources, never releases the VM. Console actions are lifecycle operations without screenshots, not authentication/pixel/human evidence. Resolve uncertain attempts; never automatically replay open. Console status ready is guest preflight, not nested attempt success. macOS requires human Standard sharing of the existing console, not a new Log In session or High Performance display. Never auto-confirm selection; server_enforced_view_only=false and viewer-selection-unverified remain limitations even after transport connects. acquire: one fresh VM for this prompt-composed subagent, register ownership and heartbeat; require task, image and extractions (declare outputs up front, [] allowed); optional ttlHours/env/fullWorkspace/vnc (boolean, default false; prepares sharing without opening). stage: hash-check runtime and optional workspace/files/nodePath/cuaDriver/browser. Corrected setup can be retried after errors; a staged runtime accepts corrected executable paths. resetRecording=true explicitly archives existing recording evidence and starts a fresh recording on the same VM, refusing an existing receiver lock. Staging success does not prove capture readiness. Guest Node and driver must exist; support goes under support/. Linux needs native X11 and cua-driver serve --no-overlay. browser:{} enables fresh persistent guest Playwright; no download or CDP attachment. After every browser event the page is settle-waited (load, network idle, fonts, two frames; settleTimeoutMs, default 5000) and an event that changed the address gets a landing page capture; captures and their records land in workspace/browser-captures, declared as an extraction automatically. run: ONE admitted operation, require reason/kind/step/snapshots. exec needs argv; script needs localPath/language; code needs code/language; cua needs tool and optional args; browser needs one browser event: navigate, click, type, press, read, or snapshot (capture the settled page now, optional name). Do not hide multiple UI interactions in a script-level pair. Ordinary UI means real pointer/keyboard, not direct accessibility. Explicit afterIntervalMs required per event or on text group last, no defaults/stability detection. Choose semantics-appropriate waits, e.g. 100ms text, 500ms dialog, 16ms game, not prescribed values. Text groups are sender-declared consecutive first/member/last events. Failures retain the VM and allow agent-directed repair; never automatically replay uncertain input. timeoutMs defaults to 120000 and accepts integers 1..3600000 independently of snapshot delay. exec diagnostic=true explicitly records command diagnosis/repair without screenshot evidence, including before staging; do not claim visual verification. A run result carries the execution identity and outcome, the guest's bounded stdout/stderr, for a browser event the parsed browser answer (settled facts, landing or snapshot capture, read text), and the saved after-image as a typed image block when that phase was captured and delivered. image: retrieve one saved image without input, capture, directory export, or acquisition. target selects display (sessionId/executionId/phase), application (declared name and relative path for a directory), or reference (imageId). PNG/JPEG/WebP only; originals max64MiB, decoded max40M pixels; preview max2000x2000 and 4MiB base64 (PNG originals are resampled in-process; JPEG/WebP pass through only within bounds). Each image delivery has a 90s deadline and at most three eligible file-transfer attempts; recommend no more than two explicit reference recovery calls. Closed enclosures return stale-reference; delivered originals remain readable by host read. Attachment does not prove provider acceptance or inspection. extract: require names, pull only declared outputs, verify hashes and reject traversal/symlinks/changing sources. finish: extract declared outputs, deliver/verify a portable snapshot package then destroy/unregister; delivery, snapshots, execution and human review are separate. release: abandon, retain available evidence and destroy the owned VM without claiming success; safe to retry failed cleanup. Use finish or release explicitly when done. Session shutdown and agent completion pause renewal without destroying the VM; backend expiration handles abandoned leases. Inspect current owned state through probe after context compaction. Only selected-action fields are permitted; no default action. No physical/local UI targets, video API or spawn API. Text output is capped at 50 KiB / 2000 lines; larger responses are retained in a local file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
osNo
envNoCredential pack, default none; never baked into images.
vncNoPrepare guest console sharing, default false. Never opens a viewer automatically.
argsNo
argvNo
codeNo
kindNo
nameNo
stepNo
taskNo
toolNo
filesNo
imageNoImage key from relay action=probe, e.g. ubuntu2404 or macos26.
namesNo
scopeNo
actionYes
reasonNoIntent of this execution. Retained as evidence, never identity, authorization or a retry key.
targetNo
browserNo
expectedNo
languageNo
nodePathNoGuest Node executable, default node; use image nvm path if needed.
ttlHoursNo
cuaDriverNoGuest CUA executable; OS default when omitted.
localPathNo
snapshotsNoStandalone event requires afterIntervalMs. Explicit consecutive text group uses first/member/last; last requires an interval. No inferred groups.
timeoutMsNoExecution timeout in milliseconds, default 120000, maximum 3600000. Independent of snapshot delay and lease TTL.
workspaceNoHost directory copied to the guest workspace, opt-in.
attempt_idNo
console_idNo
diagnosticNoExplicit command diagnosis or repair without screenshot evidence, including before staging. Commands and outcomes remain recorded. Never claim visual verification.
extractionsNo
fullWorkspaceNoExplicit opt-in to deliver the entire workspace.
userRequestedNo
resetRecordingNoExplicitly archive the current recording and start a new session on the same VM. Retains prior evidence; refuses while the receiver lock exists. Use after diagnosing recording damage.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it is exceptionally transparent: it discloses destruction (finish/release destroy or unregister the VM), permission/intent requirements (console-open requires userRequested=true and reason), failure semantics (safe to retry failed cleanup, never automatically replay uncertain input), and limits (staging success does not prove capture readiness, attachment does not prove provider acceptance).

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?

The description is very long, but nearly every sentence carries distinct, action-specific guidance and there is no filler. The action-name-led structure aids scanning, though a bulleted layout would improve readability and front-loading. Length is justified by the 13-action surface, no annotations, and no output schema.

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 tool with 35 parameters, no output schema, and no annotations, the description is remarkably complete: it covers the full lifecycle, prerequisites, side effects, timeout behavior, error distinctions (empty success vs catalog errors, stale-reference), output caps, and return semantics. No critical invocation detail appears missing.

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

Parameters5/5

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

Schema coverage is only 34%, so the description must compensate, and it does thoroughly. It maps the key parameters to their actions (task/image/extractions for acquire, argv/localPath/language/code/tool for run, target forms for image, snapshots group semantics, browser event fields) and adds defaults and constraints such as vnc false by default, timeoutMs 120000 default, and settleTimeoutMs 5000 default.

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?

The description states a concrete verb+resource: 'One VM enclosure interface' and then enumerates each action (search, probe, acquire, stage, run, image, extract, finish, release, console-*) with specific behavior for each. It sharply distinguishes internal actions and their scopes, even though it does not explicitly contrast relay_status/relay_review.

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?

The description gives rich action-level guidance: when to use probe ('Inspect current owned state through probe after context compaction'), when to choose finish vs release, when console-open is allowed, and many exclusions such as 'no default action' and 'never automatically replay open'. It does not explicitly route to its sibling tools relay_status and relay_review, so alternative-tool selection is implied rather than stated.

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