Skip to main content
Glama

Execute Code

ctx_execute

Execute code in a sandboxed subprocess and return only concise summaries. Large outputs are indexed for targeted search, preserving LLM context.

Instructions

MANDATORY: Use for any command where output exceeds 20 lines. Execute code in a sandboxed subprocess. Only stdout enters context — raw data stays in the subprocess. Available: javascript, shell, python, perl.

PREFER THIS OVER BASH for: API calls (gh, curl, aws), test runners (npm test, pytest), git queries (git log, git diff), data processing, and ANY CLI command that may produce large output. Bash should only be used for file mutations, git writes, and navigation.

THINK IN CODE: When you need to analyze, count, filter, compare, or process data — write code that does the work and console.log() only the answer. Do NOT read raw data into context to process mentally. Program the analysis, don't compute it in your reasoning. Write robust, pure JavaScript (no npm dependencies). Use only Node.js built-ins (fs, path, child_process). Always wrap in try/catch. Handle null/undefined. Works on both Node.js and Bun.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
languageYesRuntime language
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.
timeoutNoMax execution time in ms. When omitted, no server-side timer fires — the MCP host's RPC timeout governs (which is the right layer for this policy). Pass an explicit value for long-running builds (Gradle/Maven/SBT).
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.
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.
Behavior4/5

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

The description explains sandboxed execution, that only stdout enters context, timeout behavior (server-side vs RPC timeout), background mode details (keeps process alive, returns partial output), and intent parameter's indexing behavior. It does not cover stderr handling or error response format, but with no annotations, it provides substantial context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with bold headings, bullet points, and clear separation of sections. It is approximately 150 words, front-loads critical usage instructions, and every sentence provides meaningful guidance without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema or annotations, the description covers purpose, usage, parameter details, and behavioral traits. It lacks explicit mention of error handling, stderr behavior, or return object format, but for a code execution tool, it is comprehensive enough for an agent to use effectively.

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?

All parameters are documented in the schema (100% coverage). The description adds significant value by specifying output functions for each language (e.g., console.log, print), clarifying background mode pitfalls (no setTimeout), and explaining intent's search integration. This exceeds the baseline expectation.

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 clearly states 'Execute code in a sandboxed subprocess' and provides a strong verb-resource pair. It distinguishes itself from sibling tools like bash by specifying when to prefer this tool over alternatives (e.g., API calls, test runners, git queries).

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?

Explicit guidelines are provided, including mandatory use for outputs exceeding 20 lines, preferences over bash for specific tasks, and when to use bash instead (file mutations, git writes, navigation). Also includes advice on thinking in code and handling large outputs.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mksglu/context-mode'

If you have feedback or need assistance with the MCP directory API, please join our Discord server