Skip to main content
Glama

Run a guest script

relay_script

Run one shell, JavaScript, TypeScript, or Python script inside a disposable VM guest as a single recorded operation to drive Playwright, Chrome DevTools, or similar tools, with snapshot evidence.

Instructions

Run one guest script as one recorded operation; never hide several interactions in one call. A command is a shell script. The script drives whatever the image lists, such as cua-driver, Playwright or Chrome DevTools, through their own libraries or command lines, and its exit status says whether it succeeded, so a script that calls cua-driver checks the driver's answer itself. Requires language (shell, javascript, typescript or python) and inline: with inline: true give the script itself as code (up to 1 MiB); with inline: false give localPath, a host file in the project folder (relative to it or absolute inside it, with no symlinks). Give exactly the one inline names; any other call is refused. It runs in the staged workspace: shell with /bin/sh, JavaScript with the guest's Node.js, TypeScript with tsx from the guest's PATH or else the guest Node.js's own type stripping (22.6 or later), and Python with python3 from the guest's PATH (relay_probe scope=guest reports which run); a missing runtime refuses the run before it starts. Evidence is automatic: the relay records a step derived from the call and, when the image lists cua-driver, snapshots the display before and after. Optional reason (intent, never authorization), step (id, title, expected, inputMode) and snapshots.afterIntervalMs (default 500 ms) enrich or tune the record; consecutive keystrokes may form an explicit text group with snapshots.group (first/member/last). timeoutMs bounds execution (default 120000, up to 3600000). The result carries the outcome and bounded stdout/stderr; it names the after-snapshot as pending with its imageId while the image downloads in the background, so call relay_image with that imageId to see it. A refused, uncertain or nonzero result keeps the VM; never replay input whose effect is uncertain. diagnostic: true, for shell scripts only, records a diagnosis or repair without snapshots, even before relay_stage, running the script as /bin/sh -c; it is never visual verification, and its result has one output field with stdout and stderr combined.

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>",
      "language": "<language>",
      "inline": "<inline>"
    },
    "name": "relay_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeNoWith inline: true, the script itself, up to 1 MiB.
stepNoOptional step record overrides; any field left out is derived from the call.
guestYesThe guest this call acts on: the name relay_acquire answered.
inlineYestrue: the script is `code`, given inline. false: the script is the host file `localPath`. Give exactly the one that inline names.
reasonNoOptional intent, retained as evidence. Default: derived from the call.
languageYes
localPathNoWith inline: false, a host script file in the project folder: relative to it, or absolute inside it; no symlinks.
snapshotsNoOptional. Consecutive keystrokes may form an explicit text group (first/member/last); only first gets a before-snapshot and only last an after-snapshot.
timeoutMsNoExecution timeout in milliseconds, default 120000, maximum 3600000. Independent of snapshot delay and lease TTL.
diagnosticNoShell scripts only: explicit diagnosis or repair without screenshot evidence, including before staging. The script and its outcome remain recorded. Never claim visual verification.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.15.0
    • addedInput schema / properties / code
      Added value: +{
      +  "description": "With inline: true, the script itself, up to 1 MiB.",
      +  "maxLength": 1048576,
      +  "type": "string"
      +}
    • addedInput schema / properties / diagnostic
      Added value: +{
      +  "description": "Shell scripts only: explicit diagnosis or repair without screenshot evidence, including before staging. The script and its outcome remain recorded. Never claim visual verification.",
      +  "type": "boolean"
      +}
    • 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 / properties / inline
      Added value: +{
      +  "description": "true: the script is `code`, given inline. false: the script is the host file `localPath`. Give exactly the one that inline names.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / language / enum
      Previous value: -[
      -  "javascript",
      -  "typescript",
      -  "python"
      -]New value: +[
      +  "shell",
      +  "javascript",
      +  "typescript",
      +  "python"
      +]
    • addedInput schema / properties / localPath / description
      Added value: +"With inline: false, a host script file in the project folder: relative to it, or absolute inside it; no symlinks."
    • changedInput schema / required
      Previous value: -[
      -  "localPath",
      -  "language"
      -]New value: +[
      +  "guest",
      +  "language",
      +  "inline"
      +]
  2. Addedv0.5.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover mutability/open-world, but the description adds substantial context beyond them: exit-status semantics, VM retention on refused/uncertain/nonzero results, automatic before/after snapshots, the pending imageId handoff, pre-flight refusal when a runtime is missing, and timeout bounds. This is exactly the extra behavioral detail the safety hints cannot carry.

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?

Purpose and cardinality rule are front-loaded, and the density is justified by the tool's complexity. It is a long single block, however, and the runtime/evidence/diagnostic material could be split for faster scanning.

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, the description still explains the return shape: outcome plus bounded stdout/stderr, the pending after-snapshot imageId, and the single combined `output` field for diagnostic runs. Nothing essential to calling or interpreting the result is 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?

Though schema coverage is already 90%, the description adds material meaning: which runtimes back each `language`, the exclusive contract between `inline` and `code` vs `localPath` (including symlink and project-folder constraints), what `reason` vs `step` control, and how snapshots.group/afterIntervalMs tune the record. This goes beyond restating schema text.

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?

Opens with a specific verb+resource and scope: 'Run one guest script as one recorded operation', and immediately adds the cardinality constraint ('never hide several interactions in one call'). This clearly separates it from relay_probe (probe before running) and relay_stage (submit source files).

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?

Gives concrete routing: use relay_image with the returned imageId to view the after-snapshot, and use diagnostic:true only for shell diagnosis/repair that is 'never visual verification'. It also warns against replaying uncertain input. No explicit statement of when a sibling like relay_stage would be preferable for non-script work, so it falls just short of 5.

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