Skip to main content
Glama

code

Execute one sandboxed JavaScript program to drive shell, filesystem, HTTP, and MCP tools, replacing chains of separate calls and returning a small summary instead of raw JSON.

Instructions

Execute one JavaScript program that achieves the whole goal. This replaces chains of separate tool calls: one call here does the work of N, and intermediate data never enters your context.

Available: type ShellInput = { cmd: string; cwd?: string; timeout_ms?: number; } type ShellOutput = unknown type FsReadInput = { path: string; } type FsReadOutput = unknown type FsWriteInput = { path: string; content: string; } type FsWriteOutput = unknown type FsAppendInput = { path: string; content: string; } type FsAppendOutput = unknown type FsExistsInput = { path: string; } type FsExistsOutput = unknown type FsStatInput = { path: string; } type FsStatOutput = unknown type FsListInput = { dir?: string; } type FsListOutput = unknown type FsGlobInput = { pattern: string; cwd?: string; limit?: number; } type FsGlobOutput = unknown type FsGrepInput = { pattern: string; cwd?: string; include?: string; limit?: number; ignore_case?: boolean; } type FsGrepOutput = unknown type FsRemoveInput = { path: string; } type FsRemoveOutput = unknown type FsMkdirInput = { path: string; } type FsMkdirOutput = unknown type HttpInput = { url: string; method?: string; headers?: { [key: string]: string; }; body?: string; timeout_ms?: number; } type HttpOutput = unknown type HttpJsonInput = { url: string; method?: string; headers?: { [key: string]: string; }; body?: string; timeout_ms?: number; } type HttpJsonOutput = unknown

declare const codemode: { /** * Run a PowerShell (Windows) or POSIX shell command. Returns {code,stdout,stderr,ms}. */ shell: (input: ShellInput) => Promise;

/**
 * Read a UTF-8 text file. Relative paths resolve under the sandbox ROOT.
 */
fs_read: (input: FsReadInput) => Promise<FsReadOutput>;

/**
 * Write a file (creates parent dirs).
 */
fs_write: (input: FsWriteInput) => Promise<FsWriteOutput>;

/**
 * Append to a file.
 */
fs_append: (input: FsAppendInput) => Promise<FsAppendOutput>;

/**
 * True if the path exists.
 */
fs_exists: (input: FsExistsInput) => Promise<FsExistsOutput>;

/**
 * Size / dir / mtime.
 */
fs_stat: (input: FsStatInput) => Promise<FsStatOutput>;

/**
 * List a directory.
 */
fs_list: (input: FsListInput) => Promise<FsListOutput>;

/**
 * Glob files under cwd (forward slashes, *, ?). Skips node_modules/.git/dist.
 */
fs_glob: (input: FsGlobInput) => Promise<FsGlobOutput>;

/**
 * Regex search under cwd. Returns ["file:line: text"].
 */
fs_grep: (input: FsGrepInput) => Promise<FsGrepOutput>;

/**
 * Delete a file or directory tree.
 */
fs_remove: (input: FsRemoveInput) => Promise<FsRemoveOutput>;

/**
 * Create a directory tree.
 */
fs_mkdir: (input: FsMkdirInput) => Promise<FsMkdirOutput>;

/**
 * HTTP request. Returns {status, ok, headers, text, ms}.
 */
http: (input: HttpInput) => Promise<HttpOutput>;

/**
 * HTTP request parsed as JSON. Returns {status, ok, json}.
 */
http_json: (input: HttpJsonInput) => Promise<HttpJsonOutput>;

}

Rules:

  • Write an async arrow function that returns the final value. Do NOT use TypeScript syntax.

  • Use forward slashes in paths. A backslash inside a JS string is an escape ("\p" becomes "p") and silently corrupts the path.

  • Return a small JSON-able summary. Anything you do not return is discarded, which is the point: filter and aggregate inside the code, not in the conversation.

  • console.log output is captured host-side but is NOT returned — collect progress in an array and return it.

  • Loop freely: many files, many URLs, many tool calls per execution.

  • Default timeout 120s (CODEMODE_TIMEOUT_MS). Errors throw; catch them inside the code if you want to continue.

Example: async () => { const r = await codemode.shell({ cmd: "...", cwd: "...", timeout_ms: 0 }); return r; }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesJavaScript async arrow function to execute

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: default 120s timeout with the CODEMODE_TIMEOUT_MS override, errors throw rather than return, console.log is captured but not returned, unreturned data is discarded, relative paths resolve under a sandbox ROOT, and glob skips node_modules/.git/dist. The return shapes for each helper (shell → {code,stdout,stderr,ms}, http → {status,ok,headers,text,ms}) are spelled out inline.

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 value proposition and execution rules are front-loaded, and the bullet rules each carry a distinct, non-obvious constraint. It is long, and the helper API is presented twice (TypeScript type blocks plus the declare const with JSDoc), which is mild redundancy, though the second listing adds return shapes and path semantics.

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?

There is no output schema, and the description compensates by explaining what is returned versus discarded. Combined with the enumerated helper surface and the timeout/error model, an agent has everything needed to write a correct call on the first attempt.

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% for the single 'code' parameter, so the baseline is a 3-4, and the description exceeds it by specifying the required shape: an async arrow function returning the final value, no TypeScript syntax, forward slashes only because backslashes are escape sequences. The concrete example anchors the expected form.

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 opening sentence states a specific verb and resource ('Execute one JavaScript program') and frames the scope as 'achieves the whole goal,' which tells an agent exactly what unit of work this tool covers. The follow-up contrast with 'chains of separate tool calls' pins down the abstraction level unambiguously.

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 clearly indicates when to prefer this over sequential tool calls ('one call here does the work of N, and intermediate data never enters your context') and gives operational guidance such as looping freely and catching errors inside the code. It stops short of stating when not to use it, e.g. a single trivial operation where a direct tool would be simpler.

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