Skip to main content
Glama

runtime_jobs

Destructive

Jobs run a command in a fresh sandbox, once or on a cron schedule. Each run spends the free usage first while it fits the limits without credit, then credit at the sandbox rates, within your spending limits. An unknown outcome is never retried by itself. A run that cannot start says why in blockedReason (credits, capacity, cost_cap, permission, volume) and tries again every 30 seconds. To keep data between runs, attach a volume (compute.volumes). create(input), list, get, pause, resume and cancel(id), trigger(id): run it now, once, beside its schedule (a paused job stays paused; refused with run_in_progress while a run is starting or going), reschedule(id, schedule): a new schedule, the next run at its next time, update(id, input): change command, image, compute, secrets, alert, timeoutSeconds or retry in place (the next run uses them; history stays), runs(id, order?: newest): a job's attempts, oldest first or newest first, run(id): one attempt, logs(id of a run, cursor?): its output.

Input Schema

NameRequiredDescriptionDefault
idNo
inputNocreate: {name, schedule: {kind: once, at (Unix ms; a past time runs at once)} or {kind: cron, expression (five fields), timezone? (IANA, default UTC)}, compute: {region (us-east), vcpu (1-16, usually 2), cpuMode (shared), cpuFloorMillis (50), memoryMiB (up to 65536, usually 4096), diskMiB (at least 3072), durationSeconds (the paid time per run, at most 3600, at least timeoutSeconds), volumes?: [{volumeId, path (such as /data), mode? (rw, the default: one run at a time, so the next run reads what the last wrote; or snapshot: a read-only copy)}] (at most 4, in the same region as the job)}, command: {argv (no shell: ["bash", "-lc", "..."]), cwd? (under /workspace)}, timeoutSeconds, retry?: {maxAttempts (1-5), backoffSeconds}, secrets?: [{name, secretId}] (from runtime_secrets action jobs_put), maxTotalCostMicros?, image? (an image of the account: id, name, name:tag or name@version; default the standard image), alert?: {afterFailures? (runs in a row, default 1), webhook?: {url (https), secretId? (a jobs secret that signs it; the key must be allowed to reveal it, not only use it)}, email? (true: mail the job's person)}}. update: any of command, image (null: the standard image), compute (the fields given), secrets, alert (null: none), timeoutSeconds, retry, maxTotalCostMicros.
limitNo
orderNoruns: oldest first (the default) or newest first
actionYes
cursorNo
scheduleNoreschedule: {kind: once, at (Unix ms; a past time runs at once)} or {kind: cron, expression (five fields), timezone? (IANA, default UTC)}.
limitBytesNo
idempotencyKeyNoOptional: left out, one is made and returned as idempotencyKey. Send it back only to retry this exact call after a temporary error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / order
      Added value: +{
      +  "description": "runs: oldest first (the default) or newest first",
      +  "enum": [
      +    "oldest",
      +    "newest"
      +  ],
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "create",
      -  "list",
      -  "get",
      -  "pause",
      -  "resume",
      -  "cancel",
      -  "trigger",
      -  "reschedule",
      -  "runs",
      -  "run",
      -  "logs"
      -]New value: +[
      +  "create",
      +  "list",
      +  "get",
      +  "pause",
      +  "resume",
      +  "cancel",
      +  "trigger",
      +  "reschedule",
      +  "update",
      +  "runs",
      +  "run",
      +  "logs"
      +]
    • changedInput schema / properties / input / description
      Previous value: -"create: {name, schedule: {kind: once, at (Unix ms; a past time runs at once)} or {kind: cron, expression (five fields), timezone? (IANA, default UTC)}, compute: {region (us-east), vcpu (1-16, usually 2), cpuMode (shared), cpuFloorMillis (50), memoryMiB (up to 65536, usually 4096), diskMiB (at least 3072), durationSeconds (the paid time per run, at most 3600, at least timeoutSeconds)}, command: {argv (no shell: [\"bash\", \"-lc\", \"...\"]), cwd? (under /workspace)}, timeoutSeconds, retry?: {maxAttempts (1-5), backoffSeconds}, secrets?: [{name, secretId}] (from runtime_secrets action jobs_put), maxTotalCostMicros?}."New value: +"create: {name, schedule: {kind: once, at (Unix ms; a past time runs at once)} or {kind: cron, expression (five fields), timezone? (IANA, default UTC)}, compute: {region (us-east), vcpu (1-16, usually 2), cpuMode (shared), cpuFloorMillis (50), memoryMiB (up to 65536, usually 4096), diskMiB (at least 3072), durationSeconds (the paid time per run, at most 3600, at least timeoutSeconds), volumes?: [{volumeId, path (such as /data), mode? (rw, the default: one run at a time, so the next run reads what the last wrote; or snapshot: a read-only copy)}] (at most 4, in the same region as the job)}, command: {argv (no shell: [\"bash\", \"-lc\", \"...\"]), cwd? (under /workspace)}, timeoutSeconds, retry?: {maxAttempts (1-5), backoffSeconds}, secrets?: [{name, secretId}] (from runtime_secrets action jobs_put), maxTotalCostMicros?, image? (an image of the account: id, name, name:tag or name@version; default the standard image), alert?: {afterFailures? (runs in a row, default 1), webhook?: {url (https), secretId? (a jobs secret that signs it; the key must be allowed to reveal it, not only use it)}, email? (true: mail the job's person)}}. update: any of command, image (null: the standard image), compute (the fields given), secrets, alert (null: none), timeoutSeconds, retry, maxTotalCostMicros."
  3. Changed2 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "create",
      -  "list",
      -  "get",
      -  "pause",
      -  "resume",
      -  "cancel",
      -  "runs",
      -  "run",
      -  "logs"
      -]New value: +[
      +  "create",
      +  "list",
      +  "get",
      +  "pause",
      +  "resume",
      +  "cancel",
      +  "trigger",
      +  "reschedule",
      +  "runs",
      +  "run",
      +  "logs"
      +]
    • addedInput schema / properties / schedule
      Added value: +{
      +  "description": "reschedule: {kind: once, at (Unix ms; a past time runs at once)} or {kind: cron, expression (five fields), timezone? (IANA, default UTC)}.",
      +  "type": "object"
      +}
  4. Added

TDQS

A4.1/5.0
Behavior5/5

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

Discloses far more than the annotations: billing order (free usage first, then credit at sandbox rates within spending limits), no automatic retry on unknown outcomes, blockedReason enum values (credits, capacity, cost_cap, permission, volume) with a 30-second retry cadence, run_in_progress refusal on trigger, paused jobs staying paused, and volume rw vs snapshot semantics. Nothing here contradicts readOnlyHint=false / destructiveHint=true.

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

Conciseness3/5

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

The front-loaded first two sentences are strong and every clause carries real information, but the back half degenerates into a comma-spliced run-on enumerating ten actions, which is hard to parse at a glance. Content-dense but poorly structured.

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?

For a 9-parameter, deeply nested, 12-action tool with no output schema, the description covers execution, billing, failure and mutation semantics thoroughly. The gap is return values — list/get/runs/logs output shapes are never described, and the output schema's absence means the agent learns nothing about them here.

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?

Schema coverage is only 44%, but the description compensates by mapping each action to the parameters it consumes — create(input), cancel(id), trigger(id), reschedule(id, schedule), update(id, input), runs(id, order?), run(id), logs(id of a run, cursor?). That action-to-parameter mapping is nowhere in the schema and is exactly what an agent needs to call this multi-action tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: jobs run a command in a fresh sandbox, once or on a cron schedule. That distinguishes it from runtime_sandboxes_exec (one-off execution) by the scheduling dimension, and it points at runtime_volumes semantics for persistence. It never explicitly names the sibling it replaces, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage conditions are implied through the action enumeration (pause/resume/cancel/trigger/reschedule/update/runs/run/logs) and a few cross-references (runtime_secrets action jobs_put, compute.volumes). It explains trigger's refusal behavior precisely, but gives no explicit 'use this instead of X when Y' guidance against sibling sandbox tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.