Skip to main content
Glama
zademy

Context Mode

Official
by zademy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run code in a sandbox (executes the supplied code)

ctx_execute
Destructive

Run code in a sandboxed subprocess to compute answers from data, printing only results so raw output stays out of the conversation.

Instructions

Run code in a sandboxed subprocess. Languages: javascript, shell, typescript, python, perl.

Only what you console.log() enters your conversation — the bytes your code processes stay in the sandbox.

WHEN:

  • You intend to derive an answer FROM data (filter, count, aggregate, parse, compare) — print only the answer

  • Output shape or size cannot be predicted before execution (recursive finds, repo-wide greps, list endpoints, log scans)

  • You would read raw output then mentally compute — that compute belongs here, where its inputs stay out

  • You need a long-running process kept alive (dev server, watcher, daemon) — pass background: true to detach on timeout

  • Output may be large but you want recall-by-topic later — pass intent; outputs over ~5KB are auto-indexed and only section titles + previews come back

WHEN NOT:

  • Single short observational command you will consume verbatim (whoami, pwd, git status on a clean tree) — Bash is simpler

  • File mutations (Edit/Write) or navigation (cd/ls) — Bash is the right surface

RETURNS: Only what your code prints. Wrap risky calls in try/catch — uncaught errors go to stderr. Drill in via ctx_search(queries: [...]).

EXAMPLE: ctx_execute(language: "javascript", code: "const out = require('child_process').execSync('npm test', {encoding:'utf8', stdio:['ignore','pipe','pipe']}); console.log(out.split('\n').filter(l => /(FAIL|✗|×|Error:|Tests +.*(failed|passed))/i.test(l)).slice(0, 60).join('\n'))")

Input Schema

NameRequiredDescriptionDefault
cwdNoOptional working directory for shell commands. Non-shell languages still execute from their sandbox temp directory.
codeYesSource code to execute. Use console.log (JS/TS), print (Python/Ruby/Perl/R), echo (Shell), echo (PHP), fmt.Println (Go), IO.puts (Elixir), or Console.WriteLine (C#) to output a summary to context.
intentNoWhat you're looking for in the output. When provided and output is large (>5KB), indexes output into knowledge base and returns section titles + previews — not full content. Use ctx_search(queries: [...]) to retrieve specific sections. Example: 'failing tests', 'HTTP 500 errors'. TIP: Use specific technical terms, not just concepts. Check 'Searchable terms' in the response for available vocabulary.
languageYesRuntime language
timeoutMsNoMax execution time in MILLISECONDS — timeoutMs: 120000 is two minutes, timeoutMs: 120 is 0.12 seconds. When omitted, the host's own RPC timeout governs where it has one; on hosts that do not bound a call (Pi, Antigravity CLI) a generous server-side default applies instead. Pass an explicit value for long-running builds (Gradle/Maven/SBT), or background: true to detach.
backgroundNoKeep process running after timeout (for servers/daemons). Returns partial output without killing the process. IMPORTANT: Do NOT add setTimeout/self-close timers in background scripts — the process must stay alive until the timeout detaches it. For server+fetch patterns, prefer putting both server and fetch in ONE ctx_execute call instead of using background.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds substantial context beyond them: the sandbox boundary means only console.log output reaches context, uncaught errors go to stderr, background:true detaches on timeout, and large outputs are auto-indexed. These are exactly the execution-semantics facts an agent cannot get from annotations or schema.

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 core purpose and well-sectioned via WHEN / WHEN NOT / RETURNS, so an agent can scan it quickly. The closing EXAMPLE is quite long, and the RETURNS note on intent auto-indexing duplicates the schema's intent description, costing a little economy.

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?

With no output schema and a destructive, open-world execution tool, the description covers everything needed: return shape (printed output only), error handling, timeout/background behavior, and the follow-up retrieval path (ctx_search). Nothing material is left for the agent to discover by trial.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters are already fully documented. The description's mentions of intent and background largely restate the schema text rather than adding new meaning, which is the baseline-3 case. It does tie those flags to concrete situations, but that is guidance already present in the WHEN section.

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?

States a specific verb and resource — 'Run code in a sandboxed subprocess' — and enumerates the supported runtimes, so the agent knows exactly what the tool produces. It does not, however, name or distinguish itself from the close sibling ctx_execute_file, leaving that boundary to be inferred.

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 WHEN / WHEN NOT structure gives explicit positive triggers (derive an answer from data, unpredictable output, keep a process alive, index large output) and explicit exclusions (short observational commands, file mutations, navigation) with the correct alternative named for each (Bash, Edit/Write). This is about as clear as routing guidance gets.

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