Skip to main content
Glama

Run TypeScript

run_typescript

Execute TypeScript code in a fresh isolated V8 sandbox and return printed output, return values, or errors under enforced memory and time limits.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesTypeScript code to run

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.1

TDQS

A4.6/5.0
Behavior5/5

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

With only openWorldHint in the annotations, the description carries the full burden and does so thoroughly: per-call isolation and no shared state, heap and wall-time limits with disposal behavior, fetch proxying with its own timeout/byte caps/redirect rules, and the exact stdout-vs-stderr console mapping. It also documents how results and failures surface (result:, error:, error flag), which is behavior no annotation or schema conveys.

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?

Front-loaded with the one-line purpose, then tightly scoped sections (limits, fetch, language notes). It is long, and some fetch-shim detail could be trimmed, but for a sandboxed-execution tool nearly every bullet prevents a real failure mode, so the length is largely earned.

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 explicitly covers the return shape (first line timing, 'result:' for the return value, 'error:' plus stack traces on failure). Combined with the limit and shim disclosures, an agent has everything needed to call this correctly on the first try.

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% and there is a single 'code' param, so the baseline is 3. The description goes beyond the schema by explaining the semantics of that code string — it runs as an async function body, top-level await and return are legal, and it must be self-contained — which materially changes what the agent writes.

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?

States a specific verb+resource ('Execute TypeScript inside a hardened V8 isolate') with the exact runtime named, so the agent immediately knows this runs TS rather than plain JS. It also names the sibling mechanism ('executed exactly like run_javascript: same isolate, same limits'), making the distinction between the two tools concrete.

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?

It gives clear operating context (type-stripping via esbuild, self-contained snippets) and explicit exclusions ('import'/'export' not supported, no module resolver; no timers, no URL/Request/FormData/Blob). What it does not do is state directly when to prefer this over run_javascript — the routing is implied by the TypeScript-vs-JavaScript distinction rather than spelled out.

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