Skip to main content
Glama

Cloud World Model

by ai.cloudworldmodel

Create Simulation

simulation.create

Create a temporary anonymous demo cloud simulation from a list of resources and connections (max 2 active simulations per client, up to 10 resources; the returned simulationId is a short-lived unguessable capability that survives MCP transport teardown, but it is cleaned up when the demo lifetime expires or the simulation is deleted). Built-in scenario workflow: call scenario.list and pass a returned card's id as scenarioId to simulation.create for server-side graph expansion. For full control, call scenario.get and pass its hydrated resources and connections arrays instead. These are two alternatives — do not send scenarioId with resources or connections. scenario.list returns graph-free cards only; it is not a source of resource, connection, traffic-pattern, or failure-injection graphs. Scenario traffic and failure presets are not applied automatically. Use it to start any simulation workflow — either with hydrated resources and connections from scenario.get or your own architecture. Do not use it to modify an existing simulation (use simulation.inject_traffic to change load). To give a resource an explicit capacity, set characteristics.capacityRps — the literal per-node RPS ceiling at which CPU reaches ~95%; do not use maxThroughput for this (it is a legacy internal scaling parameter with different semantics). Omitted capacityRps uses the selected catalog tier and can intentionally produce a stressed baseline (for example, the AWS m5.large catalog denominator is 2,000 RPS); for a healthy, capacity-bounded reliability experiment, declare an explicit per-node capacity such as 500 RPS. That value is an experiment control, not a universal hardware fact. Capacity, node-bound, SKU, and autoscaling values supplied through this MCP tool are recorded as agent-supplied in the immutable normalizationReceipt; request responseMode: 'full' to inspect it. Generic GKE telemetry and recovery apply only to worker nodes; the control-plane management fee is cost-only, with no modeled control-plane CPU, API throttling, or cooldown. To bound the autoscaled fleet size, set the top-level maxInstances / minInstances parameters. If you do not set maxInstances, the engine uses the provider default — AWS 50, GCP 15, Azure/OCI/DigitalOcean 10 — which may be much larger than your intended fleet size. The response includes effectiveMaxInstances / effectiveMinInstances so you can confirm the bounds that will be enforced. For a targeted CPU HPA scale-out threshold, send the canonical autoscalingTargetCpu field in this create call (for example, autoscalingTargetCpu: 70 for GKE). The compatible aliases scaleOutCpuThreshold, scaleOutCpuPercent, and autoscaleTargetCpuPercent are also accepted; if more than one is sent, their values must agree. Every create response includes hpaAudit with the supplied field, persisted thresholds, and any provider default. These four TOP-LEVEL fields are simulation-wide — the engine applies one CPU threshold identically to every resource's scale decision by default. To make ONE resource scale at a different CPU target than the rest of the simulation (e.g. a GKE cluster scaling out at 60% while an EC2 fleet in the same simulation scales out at 80%), set characteristics.scaleOutCpuThreshold and/or characteristics.scaleInCpuThreshold on that specific resource instead — the per-resource value wins over the simulation-wide default for that resource only. A misnamed near-miss field nested under characteristics (e.g. targetCPUUtilizationPercentage) is rejected with a 400 explaining the correct field name — it is never silently dropped and defaulted. Responses are compact by default: id, name, status, traffic, and a per-resource summary (id, name, status, cpuPercent, routedRps, availabilityState, isRoutable, and recoveryBlockedReason when provided). Pass responseMode: 'full' to get the complete simulation object instead. During a failure workflow, lower traffic to serviceable levels before calling simulation.recover_resource, then use simulation.step until the recovered resource is healthy. Recovery progress is included when applicable: recoveryProgress.state is parked, cooling_down, or healthy, and its parkWindow/cooldown objects report totalSteps, completedSteps, remainingSteps, target, and requiredSteps. Poll simulation.get or simulation.step until state is healthy. No prerequisites. Returns the created simulation's id, which every other simulation.* tool consumes; the new simulation also becomes this session's current simulation, so subsequent per-simulation tools may omit simulationId. The likely next tool is simulation.step to advance time. Do not call api.spec to learn the simulation workflow — the tool descriptions in this session contain everything needed. Authenticate with an API key for unlimited persistent simulations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-readable name for the simulation
seedNoDeterministic RNG seed for reproducible replays
trafficNoInitial traffic in requests per second (RPS)
resourcesNoList of cloud resources composing this simulation. For a built-in scenario, pass the hydrated resources from scenario.get; scenario.list cards are graph-free. (max 10 in demo mode; mutually exclusive with scenarioId)
scenarioIdNoLive scenario identifier from scenario.list; mutually exclusive with resources and connections
connectionsNoDirected connections between resources. For a built-in scenario, pass the hydrated connections from scenario.get; scenario.list cards are graph-free. Directed edges should describe traffic flow between resources; omit when using scenarioId.
descriptionNoOptional description of the simulation's purpose
maxInstancesNoHard ceiling on the autoscaled compute fleet size, stored as autoscalingConfig.maxInstances. If omitted, the provider default applies (AWS 50, GCP 15, Azure/OCI/DigitalOcean 10) — which may be much larger than your intended fleet size.
minInstancesNoFloor on the autoscaled compute fleet size, stored as autoscalingConfig.minInstances.
responseModeNoResponse detail level. 'compact' (default) returns id, name, status, traffic, and a per-resource summary (id, name, status, cpuPercent) — keeps the response small for agent loops. 'full' returns the complete simulation object including all resource characteristics and connections.compact
resilienceConfigNoOptional retry/cascade resilience model returned by scenario.get
scaleOutCpuPercentNoGrok-compatible alias for the CPU HPA scale-out target; if multiple target names are sent they must match.
autoscalingTargetCpuNoCanonical CPU HPA scale-out target percent. CWM synthesizes unrelated autoscaling defaults.
scaleOutCpuThresholdNoEquivalent alias for autoscalingTargetCpu; if both are sent they must match.
autoscaleTargetCpuPercentNoGrok-compatible alias for the CPU HPA scale-out target; if multiple target names are sent they must match.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoUnique simulation ID — use with simulation.step, simulation.metrics, etc.
nameNoSimulation name
statusNoCurrent simulation status
trafficNoCurrent traffic in RPS
hpaAuditNoCPU HPA create-time audit: whether a target arrived, its accepted field, the persisted thresholds, and the provider-default explanation when omitted.
resourcesNoPer-resource summary (compact mode) or full resource states (full mode)
normalizedConfigNoEngine-resolved billing parameters for every resource: cost multipliers, hourly rates, autoscale thresholds (scaleOut/scaleIn CPU %), GPU SKU, per-node token throughput, billing floor, connection limits. Use this immediately after create to verify the simulation was set up as intended — e.g. confirm which GPU SKU was resolved, the effective billing floor, or the autoscale CPU threshold that will drive scale-out.
effectiveMaxInstancesNoThe fleet-size ceiling the engine will enforce (autoscalingConfig.maxInstances, or the provider default when unset)
effectiveMinInstancesNoThe fleet-size floor the engine will enforce (autoscalingConfig.minInstances, or the provider default when unset)

TDQS

A4.9/5.0
Behavior5/5

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

Annotations are all false hints, so the bar for disclosure is low, yet the description adds an exceptional amount of behavioral context: the simulationId is a short-lived unguessable capability that survives transport teardown, resources are cleaned up on lifetime expiry, scenario presets are not applied automatically, agent-supplied values are recorded in the immutable normalizationReceipt, GKE control-plane is cost-only with no modeled throttling, misnamed fields are rejected with a 400 rather than silently defaulted, and the new simulation becomes the session's current simulation. Nothing contradicts the annotations.

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?

Nearly every sentence carries a distinct, non-obvious fact — there is essentially no padding and the core purpose and constraints are front-loaded in the first sentence. However, it is a single dense block with abrupt topic jumps (scenario workflow, then capacity, then GKE cost notes, then autoscaling defaults, then HPA aliases, then per-resource overrides, then response formats, then recovery workflow), so it would benefit from explicit sectioning or paragraph breaks. The content-to-fluff ratio is high enough to exceed 'adequate' but the structure prevents a 5.

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 15-parameter tool with deeply nested objects and an output schema, the description covers everything an agent needs to call it correctly: prerequisites (none), limits, the two input modes and their exclusion, response modes, autoscaling bounds and defaults, HPA threshold and alias semantics, per-resource overrides, post-conditions (becomes current simulation), the recovery workflow, and authentication for persistent simulations. It even describes the compact response shape and recoveryProgress structure despite the output schema existing.

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 100%, setting a baseline of 3, but the description adds exactly the cross-parameter semantics the schema cannot express: the alias family around autoscalingTargetCpu and the rule that multiple aliases must agree, the per-resource characteristics.scaleOutCpuThreshold override that 'wins over the simulation-wide default for that resource only', the explicit warning to use capacityRps rather than maxThroughput, the concrete provider default values for maxInstances (AWS 50, GCP 15, Azure/OCI/DigitalOcean 10), and the mutual-exclusivity rule for scenarioId vs resources/connections.

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 specific verb ('create'), a specific resource ('temporary anonymous demo cloud simulation'), and the input basis ('from a list of resources and connections'), with explicit constraints (max 2 active simulations per client, up to 10 resources). It distinguishes itself from siblings by naming scenario.get/scenario.list as sources for built-in scenarios and simulation.inject_traffic as the alternative for modifying load.

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 explicit when-to-use ('start any simulation workflow — either with hydrated resources from scenario.get or your own architecture') and when-not-to-use ('Do not use it to modify an existing simulation — use simulation.inject_traffic'). It spells out the two mutually exclusive alternatives (scenarioId vs resources/connections), the exclusion rule between them, states there are no prerequisites, names the likely next tool (simulation.step), and even gives anti-guidance about not calling api.spec.

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

All Cloud World Model toolsInspect
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.6/5.0
Disambiguation5/5

Every tool targets a distinct step in the scenario/simulation workflow: catalog vs. hydrated graph, create vs. delete, traffic vs. failure injection, metrics vs. step, and recovery. The descriptions even call out look-alike pairs (e.g., simulation.metrics vs. simulation.step) to prevent misselection.

Naming Consistency4/5

The noun.action pattern with scenario.* and simulation.* prefixes is clear and consistent, and multi-word actions use snake_case. The only deviation is simulation.metrics, which uses a noun rather than an imperative verb like get_metrics or read_metrics, though it remains predictable.

Tool Count5/5

Nine tools is a well-scoped size for a demo simulation server: two for scenario discovery, one creation/one deletion, and five for operating/observing a simulation. No tool feels redundant or superfluous.

Completeness4/5

The core lifecycle is covered end to end: discover scenarios, create a simulation, inject load/failures, step, read metrics, recover, and delete. However, the descriptions repeatedly reference a simulation.get tool that is not present in the set; simulation.metrics mostly substitutes, but that documentation gap makes the surface slightly incomplete.

Resources