Skip to main content
Glama
Quicksilver0218

JavaScript VM

by Quicksilver0218
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Run JavaScript

run_javascript

Execute JavaScript in a fresh V8 isolate with no host access, then capture stdout, stderr, return values, and errors under fixed time and memory limits.

Instructions

Execute JavaScript inside a hardened V8 isolate (isolated-vm) and return everything it printed.

Each call gets a brand new isolate, so no state, memory or globals are shared between runs. The isolate is a separate heap with no access to the host process: there is no require, process, timer or file-system API available.

Limits, per call:

  • 512 MB of V8 heap.

  • 30 seconds of wall time; the isolate is disposed when the limit is hit.

fetch is available: the isolate has no network stack of its own, so each request is performed by the host process and the response is copied back in. Per request:

  • 10 seconds of wall time; a slower request rejects with a TimeoutError.

  • Bodies in either direction are capped at 8388608 bytes.

  • http: and https: URLs only; the host sends no cookies and follows redirects unless redirect says otherwise.

Language notes:

  • The first line of the response reports how long the run took.

  • The snippet runs as the body of an async function, so top-level await and top-level return are both allowed.

  • console.log/console.info/console.debug are captured as stdout; console.warn, console.error and console.trace are captured as stderr.

  • fetch, Headers, Response, AbortController, TextEncoder and TextDecoder are minimal shims: response.text(), response.json(), response.arrayBuffer() and response.clone() work, but response.body is null (no streams, no blob()), URL/Request/FormData/Blob do not exist, and the isolate has no timers, so setTimeout and AbortSignal.timeout are unavailable.

  • A top-level return value is reported back under result:. - Uncaught exceptions, syntax errors and their stack traces are reported back under error:, and the tool is flagged as an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesJavaScript code to run

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.1

TDQS

A3.9/5.0
Behavior5/5

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

With only openWorldHint=true as an annotation, the description carries the full behavioral burden and does so thoroughly: it discloses isolate isolation, no shared state, memory and wall-time limits, fetch behavior and timeouts, URL restrictions, output capture channels, and error reporting. It also warns about missing APIs and shim limitations.

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 long but front-loaded and mostly dense with important constraints. It is appropriately sized for a complex sandboxed-execution tool, though there is minor redundancy (timers are mentioned twice, and the host network proxy role is restated).

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?

Although there is no output schema, the description explains the response structure: the first line reports elapsed time, stdout and stderr capture, a `result:` channel, and an `error:` channel with error flagging. Combined with the runtime limits and network constraints, it gives an agent everything needed to invoke the tool correctly.

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?

Schema coverage is 100% (the single `code` parameter is documented), so the baseline is 3. The description adds meaningful runtime semantics for that parameter: the code runs as the body of an async function, top-level await and return are allowed, console methods are mapped to stdout/stderr, and return/error handling is explained.

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 first sentence gives a specific verb (Execute), resource (JavaScript), and execution environment (hardened V8 isolate), and says it returns printed output. It does not explicitly differentiate itself from the sibling run_typescript, so an agent must infer that this is for JavaScript rather than TypeScript.

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?

The description explains the runtime environment and limits but never says when to choose run_javascript over run_typescript or when not to use it. No selection guidance or exclusions are provided despite there being a clear sibling tool.

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