Skip to main content
Glama

Execute Code Stream

execute_code_stream

Stream live code execution output and progress updates while the program runs, enabling real-time monitoring before completion, with configurable limits for memory, CPU, and output size.

Instructions

Execute code and STREAM progress + partial output as it runs. Use this, not execute_code/run_submit/session_run, for the same run when you want output while it runs, up to a 300s cap.

Reports progress notifications to the client while the program runs, so agents can see output before the process finishes. Returns the same result shape and applies the SAME ceilings as execute_code: max_memory_mb, max_output_kb and max_cpu are forwarded to the executor exactly as execute_code forwards them, including the same 240 KiB per-stream clamp.

dependencies: same as execute_code's (PEP 723 merge, no_net/policy refusal, 120s budget, workdir quota) — installed before streaming starts; a refusal/failed install is the stream's only event.

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
max_cpuNoPer-call CPU-time ceiling in seconds; 0 means no explicit limit is set
timeoutNoWall-clock seconds before the run is killed; clamped to a 300s ceiling (longer than execute_code's)
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
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. Changed10 schema fields changedv0.12.0
    • addedInput schema / properties / code / description
      Added value: +"Source code to run in `language`"
    • 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 / 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; clamped to a 300s ceiling (longer than execute_code's)"
  2. 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_code_streamDictOutput",
      +  "type": "object"
      +}
  3. Changed12 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / code / title
      Added value: +"Code"
    • addedInput schema / properties / language / title
      Added value: +"Language"
    • addedInput schema / properties / max_cpu
      Added value: +{
      +  "default": 0,
      +  "title": "Max Cpu",
      +  "type": "integer"
      +}
    • addedInput schema / properties / max_memory_mb
      Added value: +{
      +  "default": 0,
      +  "title": "Max Memory Mb",
      +  "type": "integer"
      +}
    • 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 / stdin / title
      Added value: +"Stdin"
    • addedInput schema / properties / timeout / title
      Added value: +"Timeout"
    • addedInput schema / title
      Added value: +"execute_code_streamArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "type": "object"
      -}New value: +null
  4. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by explaining progress notifications, the same result shape and ceilings as execute_code, the 240 KiB per-stream clamp, and dependency installation timing. It also states that a refusal/failed install is the stream's only event, which is non-obvious behavior an agent needs to know.

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 dense and front-loaded, with the core purpose and routing in the first sentence. It is longer than minimal, but the additional paragraphs each carry essential behavioral and dependency details rather than filler.

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?

Complete for a streaming execution tool: it covers when to use it, how it behaves, and key parameter quirks, while the output schema handles return value details. Referencing execute_code for exact ceilings avoids duplication and keeps the definition self-consistent.

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%, so the schema already documents all parameters. The description adds meaningful extra semantics for dependencies (PEP 723 merge, no_net/policy refusal, 120s budget, workdir quota) and confirms that max_memory_mb, max_output_kb, and max_cpu are forwarded exactly as in execute_code.

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?

States a specific verb and resource: executing code while streaming progress and partial output. It distinguishes itself from execute_code/run_submit/session_run in the first sentence, so an agent can immediately grasp what makes this tool unique.

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?

Explicitly tells the agent when to choose this over alternatives: use this for the same run when output is wanted while it runs, with a 300s cap. This is concrete routing guidance with named sibling tools and a clear condition.

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