Runcrate

Schedule a launch

create_schedule

Destructive

Schedule an instance or a job to start later: once at run_at, or on a recurring cron in a timezone. Give exactly one of run_at or cron. spec is the launch itself, with the same fields as creating an instance (kind instance) or running a job (kind job). ALWAYS set spec.max_runtime_minutes: it is required, and the machine is stopped (billing ends) when it runs that long. A schedule fires within about 2 minutes of its time, in the current environment, and bills like a launch made then. Each run launches as you through this agent sign-in: if the sign-in ends (signed out or revoked), the schedule is paused with last_status credential_revoked. Recurring runs must be at least 15 minutes apart, and an environment holds at most 50 schedules (200 per workspace). Env values in spec (env, env_vars) are write-only: list_schedules shows only their names (env_keys). launch_script and startup_commands are shown to everyone in the environment by list_schedules; keep tokens in the environment secrets (set in the dashboard). Returns the schedule with next_run_at. After it fires, list_schedules shows last_status and last_error; update_schedule pauses, resumes or retimes it, and run_schedule_now starts it at once.

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": {
      "kind": "<kind>",
      "spec": "<spec>"
    },
    "name": "create_schedule"
  }
}

Input Schema

Name	Required	Description
`cron`	No	Recurring: a 5-field cron, minute hour day-of-month month day-of-week, read in timezone, e.g. "0 2 * * " for 02:00 daily or "0 9 * MON-FRI". Runs at least 15 minutes apart. Leave out when using run_at.
`kind`	Yes	instance starts a GPU instance; job runs one command on its own GPU machine
`name`	No	Schedule name, 1 to 63 characters (default spec.name, or <kind>-schedule)
`spec`	Yes	The launch, with the API field names. kind job: command, gpu_type and max_runtime_minutes are required. kind instance: name and max_runtime_minutes are required, plus gpu_type or instance_type_id.
`run_at`	No	One-off: when to launch, as an ISO 8601 time with an offset, e.g. 2026-10-21T02:00:00+01:00. In the future and within 365 days. Leave out when using cron.
`enabled`	No	false creates the schedule paused (default true)
`overlap`	No	Recurring only: skip (default) skips a run while the previous run is still live; allow starts it anyway
`timezone`	No	IANA timezone for cron, e.g. Europe/London (default UTC)
`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 26, 2026
- changedInput schema / properties / spec / properties / gpu_count / description
```
Previous value: -"Number of GPUs (default 1)"New value: +"GPUs on the machine: 1, 2, 4 or 8 (default 1)"
```
- addedInput schema / properties / spec / properties / gpu_count / enum
```
Added value: +[
+  1,
+  2,
+  4,
+  8
+]
```
- removedInput schema / properties / spec / properties / gpu_count / maximum
```
Removed value: -8
```
- removedInput schema / properties / spec / properties / gpu_count / minimum
```
Removed value: -1
```

Changed3 schema fields changedOct 21, 2026

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)"

First observedOct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description goes well beyond them: billing behavior per run, ~2-minute fire latency, pause-on-revocation with last_status credential_revoked, minimum 15-minute spacing, quota caps, and the fact that env values are write-only while launch_script/startup_commands are visible to everyone in the environment. It also discloses the return value (schedule with next_run_at) and post-fire status fields.

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 core purpose and the one-of rule, then layered constraints; nearly every sentence carries operational content. It is a dense single paragraph with several run-on clauses (billing, credential revocation, visibility, quotas all crammed together), which slightly hurts scannability.

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?

For a complex, nested-schema, non-idempotent mutation with no output schema, the description covers input constraints, runtime/billing consequences, failure modes (credential_revoked, timed_out), visibility/security caveats, and the lifecycle tools to use afterward. Nothing essential to calling it correctly is missing.

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 100%, so every parameter and nested spec field is already documented in the schema itself; the description largely restates the schema-level rules (exactly one of run_at/cron, max_runtime_minutes required, write-only env). It adds emphasis and cross-field framing rather than new per-parameter meaning, so the baseline of 3 applies.

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+resource ('Schedule an instance or a job to start later') and immediately disambiguates the two modes (one-off run_at vs recurring cron). It also ties the spec semantics back to the sibling launch tools by saying spec has 'the same fields as creating an instance (kind instance) or running a job (kind job).'

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?

Gives an explicit mutual-exclusion rule ('Give exactly one of run_at or cron') and routes follow-up actions to named siblings: list_schedules for status, update_schedule to pause/resume/retime, run_schedule_now to start immediately. It also sets prerequisites (sign-in must remain valid, volume must not be attached elsewhere, per-environment and per-workspace caps).

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.