Skip to main content
Glama
The-40-Thieves

codecalc

by The-40-Thieves
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Run Submit

run_submit

Submit code for background execution and get a run ID immediately, so you can poll for results later instead of keeping the call open.

Instructions

Submit code for BACKGROUND execution; returns a run_id immediately. Use this, not execute_code/execute_code_stream/session_run, when you do not want to hold the call open — poll run_inspect(run_id), and run_cancel(run_id) to stop it early.

Same request shape as execute_code minus session_id (a run is a standalone process, not a session workspace). timeout bounds the WORK itself, not how long you wait to collect it.

This call's own reply carries no output — a small run_id handle — so the anthropic/maxResultSizeChars hint lives on run_inspect instead, which returns the full envelope, same shape execute_code returns, once the run lands.

Admission is capped (CODECALC_MAX_ACTIVE_RUNS, default 64): past that many runs still running/cancelling at once, this returns a resource_exhausted error rather than growing without bound — call run_inspect/run_cancel to make room, or wait for one to finish.

Retention: see run_inspect.

dependencies: same semantics as execute_code's own. A refusal is returned directly with no run created. Otherwise this call still returns immediately: the install itself runs on the background worker, ahead of the code, and a failed install becomes the run's own terminal error — readable via run_inspect(run_id) like any other outcome.

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 120s ceiling, same as execute_code
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 120s ceiling, same as execute_code"
  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": "run_submitDictOutput",
+  "type": "object"
+}
  3. Addedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses much more than the annotations: background execution, immediate return, timeout semantics, admission cap, dependency installation behavior, and the fact that the initial reply carries no output. It also explains that a resource_exhausted error can occur and how to resolve it. No contradictions with the extended coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized in clear, front-loaded paragraphs that show the causal narrative. It starts with the core purpose, then usage guidance, then execution/response nuances, then capacity, and then dependencies. Each sentence carries meaningful information, with no repetitive filler or redundancy. The length is justified by the complexity.

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?

Despite the complexity of the tool (10 parameters, asynchronous execution, related reserve), the description covers all essential aspects: what the tool does, when to use it, how to process the result, how to cancel, what happens on failure (install fails on worker), capacity limits, and the relationship to output via run_inspect. The output schema provided handles the return shape documentation; the description does not need to restate it. An agent has everything needed to invoke and reason about this tool.

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?

The input schema covers all 10 parameters (100% coverage), so the baseline is 3. The description adds value by explaining that 'timeout' bounds the work itself not the collection time, that 'dependencies' follows execute_code semantics and triggers runtime installs, and that the call shape is the same as execute_code minus session_id. These semantic details go beyond the schema descriptions, so a 4 is appropriate.

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 opening sentence states a clear specific action: 'Submit code for BACKGROUND execution; returns a run_id immediately.' It names the exact verb, resource, and the key return value. It also explicitly contrasts itself with execute_code, execute_code_stream, and session_run, making the distinction obvious without needing to open other schemas.

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?

The description gives explicit when-to-use guidance: 'Use this, not execute_code/execute_code_stream/session_run, when you do not want to hold the call open.' It also tells the agent exactly what to do next (poll run_inspect, run_cancel) and describes the request-shape relationship with execute_code. Nothing is left to inference.

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