Skip to main content
Glama

session_run

Execute a multi-file program in a session workspace. Runs the entry file as a fresh process, resolving relative imports and data files, then returns stdout, stderr, verdict, and entry file path.

Instructions

Run a multi-file program in a session: execute entry_file, which may import other files already in the session workspace (helper.py, data/...).

Runs as a fresh process in the session workdir (not the REPL worker), so relative imports and data files resolve. Returns stdout/stderr/verdict plus the entry file's path. Oversized output spills into the session workspace the same way execute_code's does — see its docstring for stdout_spill/stderr_spill.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stdinNo
timeoutNo
languageNo
entry_fileYes
session_idYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / entry_file / title
      Added value: +"Entry File"
    • addedInput schema / properties / language / title
      Added value: +"Language"
    • 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: +"session_runArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "type": "object"
      -}New value: +null
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description discloses key behaviors: it runs as a fresh process in a specific directory, returns specific outputs, and handles oversized output with spill. It references execute_code's docstring for spill details, which adds context, though it doesn't detail permissions or limit specifics.

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 compact and front-loaded with the core purpose, then adds relevant details. It efficiently explains workdir behavior and spill handling in two short paragraphs, though the reference to execute_code's docstring is somewhat indirect.

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?

Given the tool's complexity (multi-file execution, session state, output handling) and no annotations or output schema, the description is quite complete. It covers execution environment, import resolution, return values, and spill behavior, though it could detail parameter specifics more.

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 coverage is 0%, so the description must compensate. It defines entry_file and session_id implicitly through usage, but does not explain timeout, stdin, or language individually. It adds some meaning around entry_file execution context but not comprehensive parameter semantics.

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 the tool runs a multi-file program by executing an entry_file within a session, and explicitly notes it may import other files. It distinguishes itself from siblings like session_read_file and execute_code by specifying the session workspace execution context and the fresh process in workdir.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly indicates when to use this tool: for multi-file programs in a session where relative imports matter. It contrasts with the REPL worker and mentions spill behavior similar to execute_code, but doesn't explicitly name alternative tools for single-file or non-session execution.

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

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/The-40-Thieves/codecalc'

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