Skip to main content
Glama
zademy
by zademy

Run code over a file (executes code, reads the given path)

ctx_execute_file
Destructive

Run code over a file inside a sandbox to extract line counts, matches, or aggregates without loading raw bytes into context.

Instructions

Read a file into a sandboxed FILE_CONTENT variable and run code over it. Only what you console.log() enters your conversation — the file bytes stay in the sandbox. Same principle as ctx_execute, scoped to one named file.

WHEN:

  • You want to KNOW SOMETHING ABOUT a file (line count, matches of a pattern, parsed structure, statistical aggregate) without needing to SEE all of it

  • The file is structured (CSV, JSON, log, code) and a code-level derivation is cheaper than reading verbatim

  • The file is large enough that reading it would burn conversation memory you need for the actual work

  • The derivation may itself be large and you want recall-by-topic later — pass intent; outputs over ~5KB are auto-indexed and only matching sections come back, retrievable via ctx_search

WHEN NOT:

  • You intend to EDIT the file — use Read so the subsequent Edit can match the exact text

  • You only need one specific line and you know its offset — Read with offset/limit is the simplest path

  • The file is small AND you will consume all of it — Read directly

RETURNS: Only what your code prints. FILE_CONTENT holds the raw bytes inside the sandbox; nothing else leaves. Auto-indexed output returns searchable section titles + previews instead of raw stdout.

EXAMPLE: ctx_execute_file(path: "huge.log", language: "javascript", code: "const errs = FILE_CONTENT.split('\n').filter(l => /ERROR|FATAL/.test(l)); console.log(${errs.length} error lines); console.log(errs.slice(-5).join('\n'))")

Input Schema

NameRequiredDescriptionDefault
codeYesCode to process FILE_CONTENT (file_content in Elixir). Print summary via console.log/print/echo/IO.puts/Console.WriteLine.
pathYesAbsolute file path or relative to project root
intentNoWhat you're looking for in the output. When provided and output is large (>5KB), returns only matching sections via BM25 search instead of truncated output.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations it discloses real behavior: only console.log output enters the conversation, file bytes stay in the sandbox, outputs over ~5KB are auto-indexed and retrieved via ctx_search, and the FILE_CONTENT variable name. It does not reconcile the sandbox-containment framing with the destructiveHint=true/openWorldHint=true annotations — arbitrary code can still have side effects, which the description does not warn about.

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?

Headings (WHEN, WHEN NOT, RETURNS, EXAMPLE) front-load the decision logic and make it scannable, and every bullet adds a distinct rule. The EXAMPLE is verbose and the timeoutMs detail is left entirely to the schema, so it is slightly longer than strictly necessary.

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, the description carries the return contract itself via the RETURNS section ('only what your code prints', auto-indexed section titles + previews). Combined with usage routing, param behavior, and a worked example, an agent has everything needed to call it correctly.

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 description coverage is 100%, so baseline is 3. The description goes further by explaining the FILE_CONTENT variable the `code` param operates on and the auto-indexing behavior triggered by `intent` when output exceeds ~5KB, adding meaning beyond the schema text.

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 verb+resource: read a named file into a sandboxed FILE_CONTENT variable and run code over it. It explicitly positions itself against ctx_execute ('Same principle as ctx_execute, scoped to one named file') and against plain Read in the WHEN NOT section, so an agent can distinguish it without opening any 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?

A dedicated WHEN/WHEN NOT structure gives four selecting conditions (derivations, structured files, large files, recall-by-topic) and three exclusions that name the correct alternative each time (Read for editing, Read with offset/limit for a known line, Read for small files). This is explicit when/when-not/alternative guidance.

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