Skip to main content
Glama

Run Jev Script

jevrelay_run
Destructive

Validate and execute declarative Jev Scripts locally with Playwright, running browser actions, extraction, and assertions; use inference only for explicit decide steps.

Instructions

Validate and execute a Jev Script locally with Playwright. Inference is used only for explicit decide steps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoWait for completion before returning
inputsNoValues overriding script inputs
scriptYesThe declarative Jev Script JSON object
headlessNoRun the browser without a window

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: execution happens locally via Playwright (browser automation against open-world targets) and inference is invoked only for explicit decide steps, which forewarns of cost and non-determinism. It still omits what state/side effects the run leaves behind.

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?

Two short sentences, front-loaded with the core action, and the second sentence carries real information about the inference boundary. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 should explain what a run returns — especially given the wait flag and the existence of jevrelay_status, which imply asynchronous execution and polling. It also never mentions required permissions or prerequisites for the destructive browser run, leaving real gaps for a tool with nested inputs and open-world side effects.

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%, with wait, inputs, headless and script each described in the schema itself, so the baseline is 3. The description adds nothing parameter-specific beyond hinting at decide steps, so it does not raise the bar.

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 pair (validate and execute) plus the resource (Jev Script) and the execution environment (locally, Playwright). This clearly separates it from jevrelay_validate, though the differentiation is implied rather than stated outright.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance, and none of the three sibling tools (jevrelay_validate, jevrelay_status, jevrelay_stop) are named. The agent must infer the boundary between validating and running, and when to poll status or stop instead.

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