Control Plane

Create a Workload

create_workload

Create a serverless/standard/stateful workload — or a SCHEDULED JOB by setting type: "cron". Define the container(s) in the typed containers[] array (the only way — there are no flat image/cpu/port fields) and scaling in the single autoscaling block. For a cron workload set type: "cron" and a required schedule (plus optional job policy); autoscaling/timeoutSeconds/debug do not apply to cron and are rejected. Decide reachability IN THIS CALL: a user-facing service needs public: true (or an explicit firewallConfig); omitted = deny-by-default, no internet access — do not create closed and patch the firewall afterward. Use the production-grade defaults from get_cpln_rules: explicit readiness + liveness probes, minScale ≥ 2 for user-facing services, CPU/memory sized to the runtime (NOT the platform defaults of 50m / 128Mi), autoscaling metric matched to traffic shape, never scale-to-zero unless the user asked for it by name. Type and name are immutable — changing either = delete + recreate. For databases / caches / queues / brokers / search / gateways / WAF / S3-compatible storage, propose the matching Template Catalog entry first (see get_cpln_rules). Recommended reading before first use: get_cpln_skill("workload") — the runbook for this tool family (read once per session).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`gvc`	Yes	GVC slug (lowercase kebab-case). Use the GVC the user named; otherwise discover with list_resources (kind="gvc") and let them choose — never guess (a wrong GVC targets the wrong environment).
`org`	Yes	Organization slug (lowercase kebab-case). NEVER guess — if the user has not named one, ask. On org-not-found, stop and ask; do not retry variants.
`name`	Yes	Workload name (lowercase kebab-case, must start with a letter, max 49 chars, cannot end with -headless). The name is IMMUTABLE — "renaming" requires delete + recreate (loses public URL, internal DNS, policy targetLinks).
`tags`	No	Optional tags (key/value pairs such as env=prod).
`type`	No	Workload type (default: standard — always-running). Use "cron" for a SCHEDULED JOB: then `schedule` is REQUIRED and the job-policy fields apply, while autoscaling/timeoutSeconds/debug do NOT (they are rejected — probes and autoscaling have no meaning for a cron run). vm is not supported.	standard
`debug`	No	Enable or disable spec.defaultOptions.debug. Not valid with type: "cron".
`public`	No	Convenience shortcut: opens the external firewall BOTH ways — inbound 0.0.0.0/0 AND outbound 0.0.0.0/0 (a public service almost always needs both directions). Mutually exclusive with firewallConfig, and an explicit firewallConfig overrides it. OMITTED = no external access (deny-by-default) — decide exposure here, at create time; do not create closed and patch the firewall open afterward.
`suspend`	No	Enable or disable spec.defaultOptions.suspend (no replicas run while suspended; for a cron workload this pauses scheduled runs)
`schedule`	No	REQUIRED when type is "cron" (and ONLY valid then): a NUMERIC 5-field cron expression like "0 /6 * *" (no @daily macros, no MON/JAN names). Omit entirely for serverless/standard/stateful.
`capacityAI`	No	Enable or disable spec.defaultOptions.capacityAI — applies to every type (default ON for serverless/standard/cron; on cron the new reservation takes effect at the next scheduled run). Explicit true is rejected with the cpu metric and with GPUs.
`containers`	Yes	Required full container specs (1-8). Each item minimally needs name and image; all other container fields are optional. This is the only way to define containers — there are no flat image/cpu/port fields.
`autoscaling`	No	Autoscaling configuration → spec.defaultOptions.autoscaling (metric, target, minScale, maxScale, scaleToZeroDelay, maxConcurrency, keda). This is the ONLY place scaling is configured. Omit to use platform defaults (minScale 1, maxScale 5).
`description`	No	Workload description
`historyLimit`	No	Number of completed job instances to retain (default 5)
`identityLink`	No	Identity link granting 3rd-party cloud resource access, e.g. //identity/my-id
`restartPolicy`	No	What to do when a job instance fails
`firewallConfig`	No	Inbound/outbound access control. Access is restricted by default.
`timeoutSeconds`	No	Set spec.defaultOptions.timeoutSeconds — max request duration (platform default 5s; serverless caps at 600)
`concurrencyPolicy`	No	What to do when a run is due while a prior run is still active (default Forbid)
`supportDynamicTags`	No	Enable or disable spec.supportDynamicTags (detects image digest changes).
`activeDeadlineSeconds`	No	Max seconds to wait for the job to complete before it is stopped

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the call succeeded.
`data`	No	The full machine-readable result — list rows, the resource object, query results. Read THIS, not just the summary.
`summary`	Yes	One-line summary of the result.
`nextSteps`	No	Recommended follow-up actions for this task, in order.

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses that for cron workloads autoscaling/timeoutSeconds/debug are rejected, that type and name are immutable (changing = delete + recreate), and that deciding reachability must happen in this call (deny-by-default, don't patch later). It also mentions reading get_cpln_rules for production-grade defaults. No contradiction with annotations.

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 description is dense and front-loaded with the main workflow, but it's long and includes a fair amount of detail (e.g., 'the only way', 'do not create closed and patch the firewall afterward') that could be trimmed since it's partly repeated in the schema comments for containers[] and public. Not egregiously verbose, but borderline. It gets a 3 because it's a bit overlong for a tool that has a 100% schema-coverage and a rich schema.

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?

Given the high complexity (21 params, nested objects, many enums) and the 100% schema coverage, the description complements by pointing to get_cpln_rules and get_cpln_skill for runbook details, and covers the decision logic for cron vs other types and when to use templates. It doesn't repeat return values (output schema exists). It could mention error cases (except org-not-found which is in the schema's org param) but that's minor. Overall, complete enough.

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 baseline is 3. The description adds value by linking parameters to the goal: containers[] is the only way to define containers (no flat image/cpu/port fields), autoscaling is the only place to configure scaling, and public/firewallConfig decide reachability. For cron, it says schedule is required and autoscaling/timeoutSeconds/debug are rejected. It also references get_cpln_rules for defaults like minScale ≥ 2 for user-facing services. This slightly exceeds the baseline.

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 clearly states it creates a workload covering serverless/standard/stateful and cron job types. It's specific about the resource (workload) and the action (create), and it distinguishes from siblings like update_workload, install_template, and build_image. Unlike the sister tools that handle domains or templates, this is the only creation tool for workloads. It also teases the cron type and points to helper tools (get_cpln_rules, get_cpln_skill) for guidance.

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?

Explicitly tells when NOT to use this tool: for databases/caches/queues/brokers/search/gateways/WAF/S3-compatible storage, propose the matching Template Catalog entry first. It also directs to get_cpln_rules and get_cpln_skill before first use, naming the runbook and skill. This contrasts with sibling tools (install_template, update_workload, create_gvc) and gives clear decision criteria.

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

All Control Plane tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Every tool targets a distinct resource/action pair (e.g., get_resource vs get_resource_schema, list_deployments vs list_workload_replicas) and descriptions clearly differentiate purposes. No two tools appear to do the same thing.

Naming Consistency5/5

All tools follow a verb_noun snake_case pattern (create_gvc, update_workload, list_resources, query_metrics) with consistent verbs. The few imperative verbs (browse, build, mount) still maintain the same verb-first structure.

Tool Count1/5

With 55 tools, this server far exceeds the typical well-scoped 3-15 tool range. While each tool appears purposeful, the sheer number creates selection overhead and falls into the extreme 50+ category on the rubric.

Completeness4/5

The surface covers nearly the full Control Plane lifecycle: CRUD for GVC, workload, identity, policy, volumeset, and domain, plus observability, templates, image builds, and Terraform. Minor gaps include referenced but missing configure_workload_* tools and no secret creation/deletion (by design).

Create a Workload

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources