Skip to main content
Glama
The-40-Thieves

codecalc

by The-40-Thieves
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Execute Code

execute_code

Run code in 31 languages in an isolated sandbox and get stdout, stderr, exit code, timing, and verdict, with optional sessions, dependencies, and network blocking.

Instructions

Execute code in language in a sandbox. Use this, not execute_code_stream/run_submit/session_run, for one program whose result you can wait for within a 120s cap.

Returns stdout, stderr, exit_code, duration_ms, cpu_ms, peak_memory_kb, verdict (OK/TLE/MLE/OLE/RTE).

  • session_id: run inside a session workspace (see session_start); with a stateful session (python3/node) interpreter state persists across calls. Also reports artifacts_created (files just created/modified) since that workspace outlives the call; a sessionless run has none. See session_run for the same field plus inline content blocks.

  • max_output_kb: the 240 KiB hard ceiling is what the anthropic/maxResultSizeChars this tool advertises in its _meta already assumes — the cap leaves no headroom to raise past it without the real result exceeding that hint. A run whose real output needs more than 240 KiB belongs in a session instead: leave max_output_kb at its default (0) with session_id set (below), and oversized output SPILLS to a full-fidelity file readable via session_read_file rather than truncating — see the spill paragraph further down. An EXPLICIT max_output_kb, even under the 240 KiB ceiling, is honoured as a literal cap with no spill.

  • no_net: Linux enforces in-kernel via a seccomp-bpf filter. macOS / no-seccomp kernel: best-effort symbol shim, disclosed in unenforced when that's the only guarantee that held. See SECURITY.md.

  • compact: never drops unenforced, output_error, artifacts_created, or dependencies — if a guarantee you asked for was not applied, or a declared install failed, a compact result still says so.

  • dependencies: merged with a PEP 723 # /// script block for python3, deduped by normalized name with this argument winning; the only source for node. A block ALONE, with no dependencies argument, is enough to trigger an install — see SECURITY.md. Installed BEFORE the sandboxed step, through the same confined install_package path — never inside the sandbox — and refused (capability_not_requested) without installing anything when no_net=True or the capability policy denies or strictly limits network. Bounded by a fixed install-time budget separate from timeout (120s aggregate across every dependency; codecalc.dependencies.DEFAULT_DEPENDENCY_INSTALL_BUDGET_SECONDS) and, session-less, by CODECALC_SESSION_DISK_QUOTA_MB on the run's own workdir — either one exceeded refuses the run with a stamped, coded error naming the ceiling. See the dependencies field on the result.

With session_id set and max_output_kb left at its default, output that would otherwise be truncated is instead SPILLED: the inline stdout/stderr still carry the same truncated prefix as before, and stdout_spill/stderr_spill name a codecalc://session/{sid}/files/... resource carrying the fuller stream (session_read_file or the resource route reads it back) — capped at 4 MiB, ..._spill_capped: true if even that was not enough to hold everything. Passing an EXPLICIT max_output_kb is honoured as a literal ceiling with no spill, same as before. Session-LESS runs (no session_id) have no workspace to spill into and keep the old truncate-and-drop behaviour.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesSource code to run in `language`
stdinNoText piped to the program's standard input; empty means no input
no_netNoBlock outbound network access for this run; best-effort on platforms without seccomp
compactNoDrop diagnostic fields (timings, workdir, platform) from the result; safety disclosures are always kept, and stderr is kept whenever the run did not succeed — dropped only on a clean successful run (ok=true, exit_code 0, verdict OK)
max_cpuNoPer-call CPU-time ceiling in seconds; 0 means no explicit limit is set
timeoutNoWall-clock seconds before the run is killed as TLE; clamped to a 120s ceiling
languageYesRuntime to execute in, e.g. 'python3', 'node'; see list_languages for the full catalog
providerNoExecution backend id to use (see list_execution_providers); default picks automatically
session_idNoRun inside this session's workspace (from session_start) instead of a throwaway sandbox
dependenciesNoPackages to install before running, e.g. ['requests==2.31.0']; merged with any PEP 723 block
max_memory_mbNoPer-call memory ceiling in MiB; 0 means no explicit limit is set
max_output_kbNoStdout/stderr capture cap in KiB per stream; 0 uses the 64 KiB default, hard-clamped to 240

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.13.0
    • changedInput schema / properties / compact / description
      Previous value: -"Drop diagnostic fields (timings, workdir, platform) from the result; safety disclosures are always kept"New value: +"Drop diagnostic fields (timings, workdir, platform) from the result; safety disclosures are always kept, and stderr is kept whenever the run did not succeed — dropped only on a clean successful run (ok=true, exit_code 0, verdict OK)"
  2. Changed12 schema fields changedv0.12.0
    • addedInput schema / properties / code / description
      Added value: +"Source code to run in `language`"
    • addedInput schema / properties / compact / description
      Added value: +"Drop diagnostic fields (timings, workdir, platform) from the result; safety disclosures are always kept"
    • addedInput schema / properties / dependencies / description
      Added value: +"Packages to install before running, e.g. ['requests==2.31.0']; merged with any PEP 723 block"
    • addedInput schema / properties / language / description
      Added value: +"Runtime to execute in, e.g. 'python3', 'node'; see list_languages for the full catalog"
    • addedInput schema / properties / max_cpu / description
      Added value: +"Per-call CPU-time ceiling in seconds; 0 means no explicit limit is set"
    • addedInput schema / properties / max_memory_mb / description
      Added value: +"Per-call memory ceiling in MiB; 0 means no explicit limit is set"
    • addedInput schema / properties / max_output_kb / description
      Added value: +"Stdout/stderr capture cap in KiB per stream; 0 uses the 64 KiB default, hard-clamped to 240"
    • addedInput schema / properties / no_net / description
      Added value: +"Block outbound network access for this run; best-effort on platforms without seccomp"
    • addedInput schema / properties / provider / description
      Added value: +"Execution backend id to use (see list_execution_providers); default picks automatically"
    • addedInput schema / properties / session_id / description
      Added value: +"Run inside this session's workspace (from session_start) instead of a throwaway sandbox"
    • addedInput schema / properties / stdin / description
      Added value: +"Text piped to the program's standard input; empty means no input"
    • addedInput schema / properties / timeout / description
      Added value: +"Wall-clock seconds before the run is killed as TLE; clamped to a 120s ceiling"
  3. Changed2 schema fields changedv0.11.0
    • addedInput schema / properties / dependencies
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dependencies"
+}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "execute_codeDictOutput",
+  "type": "object"
+}
  4. Changed14 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / code / title
      Added value: +"Code"
    • addedInput schema / properties / compact / title
      Added value: +"Compact"
    • addedInput schema / properties / language / title
      Added value: +"Language"
    • addedInput schema / properties / max_cpu / title
      Added value: +"Max Cpu"
    • addedInput schema / properties / max_memory_mb / title
      Added value: +"Max Memory Mb"
    • addedInput schema / properties / max_output_kb / title
      Added value: +"Max Output Kb"
    • addedInput schema / properties / no_net / title
      Added value: +"No Net"
    • addedInput schema / properties / provider
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Provider"
+}
    • addedInput schema / properties / session_id / title
      Added value: +"Session Id"
    • addedInput schema / properties / stdin / title
      Added value: +"Stdin"
    • addedInput schema / properties / timeout / title
      Added value: +"Timeout"
    • addedInput schema / title
      Added value: +"execute_codeArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  5. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the annotations, disclosing sandboxing semantics, timeout clamping, output truncation/spill behavior, dependency installation ordering and refusal conditions, no_net enforcement differences across platforms, compact result guarantees, and artifact creation in sessions. Annotations only state readOnly=false/openWorld=true, and nothing in the description contradicts them; the description carries rich additional behavioral context.

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 well-structured with bolded parameter names, bullet-like paragraphs, and front-loaded purpose, making dense information navigable. However, it is noticeably long and contains some repeated spill/truncation explanations (e.g., the explicit max_output_kb cap and 'honoured as a literal ceiling' wording appears twice). It earns most of its length for a complex tool, but it is not maximally concise.

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, 12 parameters, rich annotations, and large sibling set, the description covers the full invocation lifecycle: return fields, output spill path, dependency installation conditions and limits, session semantics, safety guarantees even in compact mode, and platform-specific network enforcement. An agent has nearly everything needed to call this tool correctly, and the presence of an output schema reduces the need to describe return values in detail.

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

Parameters5/5

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

Input schema coverage is 100%, so the baseline is 3, but the description substantially deepens the meaning of several parameters: max_output_kb gains the 240 KiB ceiling, spill behavior, and the distinction between explicit and default values; session_id gains state persistence, artifact reporting, and workspace outliving; dependencies gains PEP 723 merging, install-before-run ordering, network refusal, and install budgets; no_net gains seccomp vs best-effort shim details. This is far more than the schema alone provides.

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 opens with a specific verb and resource: 'Execute code in language in a sandbox', and immediately distinguishes itself from execute_code_stream, run_submit, and session_run by identifying the exact use case: 'one program whose result you can wait for within a 120s cap.' This makes the tool's identity and boundary unambiguous.

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?

It explicitly says when to use this tool versus alternatives: use this, not execute_code_stream/run_submit/session_run, for a single waitable program within 120s. It also explains when a session is the right alternative, e.g., oversized output beyond 240 KiB and stateful runs, and references session_run for inline content blocks. This is direct routing guidance, not merely implied context.

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