Runcrate

Run a job again

rerun_job

Destructive

Run a job again as a new job, on a fresh machine, with any run_job field changed, e.g. {"gpu_count": 2} or {"max_runtime_minutes": 240}. The variables of the first run are reused when you submitted it (they are never shown); anyone else sends them again as changes.variables. changes.variables is merged over them. Returns the new job, with rerun_of set, followed the same way as a run_job job.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "rerun_job"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	ID of the job to run again
`changes`	No	run_job fields to change: variables (merged over the first run's), and under the API's names gpu_type, gpu_count, command, max_runtime_minutes, image, storage_id, name, region, capacity_wait_minutes, max_retries, retry_on, retry_exit_codes, tags, webhook_url
`workspace`	No	Workspace ID (optional: defaults to the authenticated workspace)
`environment`	No	Environment name (optional: defaults to the environment this session acts in)

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 21, 2026

changedInput schema / properties / changes / description

Previous value: -"run_job fields to change, under the API's names: gpu_type, gpu_count, command, max_runtime_minutes, image, env, storage_id, name, region, capacity_wait_minutes, max_retries, retry_on, retry_exit_codes, tags, webhook_url"New value: +"run_job fields to change: variables (merged over the first run's), and under the API's names gpu_type, gpu_count, command, max_runtime_minutes, image, storage_id, name, region, capacity_wait_minutes, max_retries, retry_on, retry_exit_codes, tags, webhook_url"

removedInput schema / properties / env

Removed value: -{
-  "description": "Environment name (optional — defaults to main)",
-  "type": "string"
-}

addedInput schema / properties / environment

Added value: +{
+  "description": "Environment name (optional: defaults to the environment this session acts in)",
+  "type": "string"
+}

changedInput schema / properties / workspace / description

Previous value: -"Workspace ID (optional — defaults to authenticated workspace)"New value: +"Workspace ID (optional: defaults to the authenticated workspace)"

AddedOct 21, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare non-idempotent, destructive, open-world, so the bar is lower; the description still adds real behavior: the rerun lands on a fresh machine, produces a new job with rerun_of set, and inherits the original variables unless overridden. It does not mention cost duplication or that the original job is untouched, but the core side effects are disclosed.

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?

Front-loaded with the action and an inline example, then the variable-inheritance caveat. The variables sentence is slightly convoluted ('reused when you submitted it (they are never shown)'), but overall it is compact and every sentence carries information.

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?

No output schema exists, yet the description covers the return ('the new job, with rerun_of set') and points to run_job for how to follow it. Remaining gaps are minor: no mention of billing impact or what happens to the source job.

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 baseline would be 3; the description goes further by explaining merge semantics for changes.variables (merged over the first run's) and the ownership rule that other users must resend variables because stored ones are never shown. This is meaning the schema alone does not convey.

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 ('Run a job again as a new job') and immediately distinguishes it from run_job by scope: a fresh machine with any run_job field changed. An agent can tell exactly what this does versus run_job without opening a schema.

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?

Usage context is clear — re-run an existing job when you want to alter run_job fields such as gpu_count or max_runtime_minutes — and it implicitly routes agents to run_job for new jobs. It lacks an explicit 'do not use when...' statement or a named alternative for starting fresh.

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

All Runcrate tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.