Skip to main content
Glama
The-40-Thieves

codecalc

by The-40-Thieves
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Session Run

session_run

Execute a multi-file program in a session workspace with correct relative imports and data file resolution. Returns output, verdict, and created artifacts.

Instructions

Run a multi-file program already written into a session workspace (via session_write_file). Use this, not execute_code/execute_code_stream/run_submit, when entry_file may import other files already in that 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.

Reports artifacts_created and inlines small ones as extra content blocks (image/text/link), capped at 8 blocks / 4 MiB encoded; truncated_inline: true past either cap. dependencies installs packages before running, same rule as execute_code's — see its docstring.

This tool takes no max_output_kb (its inline stdout/stderr stay at the 64 KiB default and spill past that, same as execute_code's session branch) but the anthropic/maxResultSizeChars _meta it advertises covers only that text envelope — the JSON result serialized as the reply's content text block. The inlined artifact blocks above (image/text/link, up to 8 of them within the 4 MiB encoded budget) are SEPARATE MCP content blocks, outside the text block this hint bounds.

Every run copies entry_file's own source into the runner's private scratch subdirectory before executing it — never into a root-level main.<ext> file a session's own files could collide with. A session's own main.py (or the equivalent for another language) at the session root is never touched by running a different entry file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stdinNoText piped to the program's standard input; empty means no input
timeoutNoWall-clock seconds before the run is killed
languageNoLanguage to run `entry_file` as; omit to infer it from the session/file
entry_fileYesRelative path of the file to execute; may import other files already in the workspace
session_idYesId of the session workspace to run in
dependenciesNoPackages to install before running, e.g. ['requests==2.31.0']

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.12.0
    • addedInput schema / properties / dependencies / description
      Added value: +"Packages to install before running, e.g. ['requests==2.31.0']"
    • addedInput schema / properties / entry_file / description
      Added value: +"Relative path of the file to execute; may import other files already in the workspace"
    • addedInput schema / properties / language / description
      Added value: +"Language to run `entry_file` as; omit to infer it from the session/file"
    • addedInput schema / properties / session_id / description
      Added value: +"Id of the session workspace to run in"
    • 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"
  2. Changed1 schema field changedv0.11.0
    • addedInput schema / properties / dependencies
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dependencies"
+}
  3. 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
  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?

The description goes well beyond annotations, explaining that execution happens in a fresh process in the session workdir, not the REPL worker, and that the entry file is copied into a private scratch subdirectory to avoid collisions with root-level main files. It also details output spill behavior, inline artifact caps, and the exact scope of the maxResultSizeChars hint, all non-obvious behavioral facts an agent needs.

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 long, but almost every sentence carries a distinct behavioral fact that is not visible from the schema. It is front-loaded with purpose and usage, then covers execution semantics, output behavior, and file-safety guarantees. It could be tightened, but for a complex tool the density is justified.

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 still covers what the tool returns (stdout/stderr/verdict, entry file path, artifacts_created), how truncation is signaled, how dependencies behave, and how output can appear outside the main text envelope. Given the tool's complexity and the absence of an output schema, this is remarkably complete.

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 the schema already documents all parameters. The description adds meaningful context beyond that by clarifying that entry_file may import other workspace files, and that dependencies installs packages before running with the same rule as execute_code, enriching the agent's understanding without repeating the schema.

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: 'Run a multi-file program already written into a session workspace.' It also names the sibling tools it should not be confused with (execute_code/execute_code_stream/run_submit), making the tool's identity and scope immediately clear.

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?

Usage is explicitly conditioned: 'Use this, not execute_code/execute_code_stream/run_submit, when `entry_file` may import other files already in that workspace.' This gives the agent a concrete decision rule and names the alternatives, which is exactly the guidance needed.

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