Skip to main content
Glama

vro_run_script

Execute temporary JavaScript snippets on Orchestrator for prototyping or quick checks. Runs the script, returns output and logs, then deletes the temp action.

Instructions

Run an ad-hoc JavaScript snippet on Orchestrator — for prototyping and quick checks. Creates a temporary action, executes it with the given inputs (available as variables), returns the 'return' value + System.log output, then deletes the action. Script must be plain ES5 (Rhino): var, function(){}, no arrow functions/let/const/template literals.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsNoVariables passed into the script
scriptYesBody of the function. Use `return x;` to return a value.
inputTypesNoOptional explicit types, e.g. {vm: 'VC:VirtualMachine'}
keepActionNoDon't delete the temp action afterwards (to inspect it)
returnTypeNoDefault 'Any'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the temporary-action lifecycle, return value plus System.log output, and the ES5/Rhino script constraints, but omits permissions, rate limits, and potential side effects of executing arbitrary code.

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

Conciseness5/5

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

Three sentences, front-loaded with purpose and usage, then behavior, then constraints. Every sentence earns its place; no redundant or vague wording.

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?

Given the absence of an output schema, the description explains the return value and System.log output. It also covers script language constraints and the temporary action lifecycle, making it largely complete, though it could mention error handling or required permissions for a code-execution tool.

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?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds only that inputs are 'available as variables' inside the script, which is marginal beyond the schema's own descriptions.

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?

States a specific verb and resource: run an ad-hoc JavaScript snippet on Orchestrator. It distinguishes itself from saved-action siblings by noting the temporary action lifecycle ('creates a temporary action ... then deletes the action'), though it does not name an alternative sibling explicitly.

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?

Provides clear usage context: 'for prototyping and quick checks.' However, it does not state when not to use it or name alternative tools (e.g., vro_run_action) for production or repeatable tasks.

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