Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
run_javascriptA

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.

run_typescriptA

Execute TypeScript 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 is compiled with esbuild (types stripped) and then executed exactly like run_javascript: same isolate, same limits, same output capture.

  • import/export module syntax is not supported: the isolate has no module resolver, so the snippet has to be self-contained.

  • Constructs that emit new code (enum, namespace, constructor parameter properties) make esbuild produce extra lines, so a runtime stack trace can point past the line you wrote. Plain type annotations keep line numbers exact.

  • 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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation4/5

The two tools are distinguished primarily by language (JavaScript vs TypeScript), which is a clear and predictable selection criterion. However, TypeScript is close to a superset of JavaScript, so a plain JS snippet often runs fine in either tool, leaving a narrow band of genuine overlap.

Naming Consistency5/5

Both names follow the same verb_noun snake_case pattern (run_javascript, run_typescript) with a single shared verb and a language noun. The naming is fully predictable and symmetric.

Tool Count4/5

Two tools is on the thin side, but the server's scope is narrowly 'execute code in a sandbox,' and one tool per supported language is a defensible, minimal surface. No tool feels redundant or padded.

Completeness4/5

Core execution, output capture, error reporting, and fetch are covered, which is the full lifecycle for a stateless code sandbox. Gaps are deliberate constraints rather than omissions: no session/state persistence, no module resolution, no package installation, and no way to pass structured inputs into a run.

Maintenance

ActivityMaintained
ResponsivenessNo issues