Skip to main content
Glama

Run Code in VM

run_code_in_vm
Destructive

Run a Node.js snippet on the project's compute VM (headless — no browser needed). The project's npm dependencies are importable; network access works, so you can call the project's /_api/* endpoints (get_preview_url → apiBaseUrl). ESM by default; bare require() snippets run as CJS. Returns stdout+stderr.

Calls to the project's /_api/* are rate-guarded exactly like the browser preview: more than 20 calls to one endpoint or 150 total within 5s rejects that fetch and every later /_api/* fetch in the snippet with 'Backend endpoint is called too frequently'. This is a hard guard, not a retry hint — do NOT loop fetch() over rows/ids or fire many parallel calls; batch into one endpoint call, or use _floot.runSQLQuery for bulk reads/writes.

Runs in an ISOLATED temp dir, NOT the project root, with NO access to the project's environment: process.env carries none of the project's env vars or secrets (only PATH/HOME/NODE_ENV are set — anything like process.env.POSTHOG_API_KEY reads back undefined), and project source files are NOT importable by relative path (import './helpers/foo' fails with ERR_MODULE_NOT_FOUND — only npm dependencies resolve; contrast run_code_in_browser, which runs at the project root and CAN import project files). For anything that needs project secrets, env config, or DB access, use the _floot helpers below (they proxy to the project's server context) or fetch the project's /_api/* endpoints over the network — those run server-side WITH the full env; the VM snippet itself never sees it.

A _floot global is available with project-scoped server-data helpers (no DB creds needed, no HTTP wiring): await _floot.runSQLQuery({ query, resourceName?, reasonAndExplanationForNotReadOnly?, dryRun? }) (omit the reason for a read-only query; pass it to allow NON-DESTRUCTIVE writes — INSERT, CREATE TABLE, additive ALTER — e.g. programmatic seeding loops. DESTRUCTIVE statements — DELETE/UPDATE/TRUNCATE/DROP — are rejected here because the user never sees snippet SQL; run those through the execute_sql tool, where the statement appears in the tool call for approval. Resolves to {rows, rowCount, command, truncated?} — or {results: [...]} for multi-statement queries), getHostingUsage({days?}), getLambdaUsage({days?}), getPushHistory({subscription?,from?,to?,offset?}), getProdBackendLogs({filter?,from?,to?,nextToken?,limit?}) (the PUBLISHED app's backend CloudWatch logs; details: get_guides('prod-backend-logs')), storageList(prefix) (prefix MUST start with "public/" or "private/" — e.g. storageList("public/") to list everything public), storageGetUrl(key), storageGetFileSizes(visibility, continuationToken?), storageUpload({filename,sizeBytes,contentType}), storageDelete(key), and getFileById(id) (returns {url, fileName, contentType} — fetch the url for bytes). Same surface as runCodeInBrowser's _floot, minus the DOM/editor-only helpers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYes
projectIdYes
timeout_secondsNo

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only indicate destructiveHint=true and readOnlyHint=false, but the description goes far beyond: it discloses the isolated temp dir, lack of project env vars/secrets, rate-limiting behavior, and the exact behavior of _floot helpers. It also warns against destructive SQL usage in this tool and directs those to execute_sql. This is rich behavioral context that fully complements the annotations with no contradiction.

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 every sentence carries essential information: purpose, constraints, alternatives, helper APIs, and rate-limit warnings. It is front-loaded with the core action and then systematically details behavior. The structure is clear with paragraphs and bullet-like details, though it is dense enough that a shorter version might be possible without losing value.

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?

Given the tool's complexity (many helpers, rate limiting, isolation, and edge cases), the description is remarkably complete. It covers return formats, helper signatures, special constraints like 'prefix MUST start with public/' and the exact rate limit numbers. There is nothing an agent needs to know to call this tool correctly that is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides no descriptions for any of the three parameters (coverage 0%), so the description must compensate. It explains that `code` is a Node.js snippet and how ESM/CJS work, but it does not explain `projectId` or `timeout_seconds` at all. Because two of three parameters remain unexplained, the description fails to provide complete parameter semantics.

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?

The description states a precise action and resource: 'Run a Node.js snippet on the project's compute VM' and immediately clarifies it is headless, distinguishing it from the browser-based alternative. It names the sibling tool (run_code_in_browser) and explains the key difference, so an agent can tell them apart without opening either schema.

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

Usage Guidelines5/5

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

The description gives explicit guidance on when to use this tool vs. others: use _floot helpers or /_api/* endpoints for secrets/env/DB access, use execute_sql for destructive SQL, and use run_code_in_browser when project file imports are needed. It also warns about rate limits and recommends batching instead of looping, making routing decisions unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation4/5

Tools are mostly distinct, but there is some overlap among file-modifying tools (edit_file, write_file, apply_patch) and between run_code_in_vm and run_code_in_browser. Detailed descriptions and clearly scoped use cases help agents select correctly.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (create_project, list_files, execute_sql), but a few deviate (apply_patch, card_upload_asset, run_code_in_vm). Overall readable and predictable, with only minor inconsistencies.

Tool Count2/5

With 46 tools, the server exceeds the typical well-scoped range and approaches the extreme threshold. While the broad scope of a full development platform justifies many tools, this count may overwhelm agents and increase misselection risk.

Completeness4/5

The tool surface covers the full development lifecycle: project creation, file operations, database management, resource provisioning, deployment, testing, and debugging. Minor gaps exist (e.g., no delete_project or checkpoint management), but core workflows are well-supported.

Resources