Cloud World Model

Simulate Step

simulation.step

Advance a temporary anonymous demo simulation by one time step and return updated metrics — CPU, latency, throughput, error rate, cost (max 20 persisted steps per demo). Use it to observe how the architecture behaves over time, typically right after simulation.create or simulation.inject_traffic. Do not use it to read current state without advancing time — that is simulation.metrics. Pass the simulationId returned by simulation.create when your connector opens a fresh MCP session; preserve Mcp-Session-Id to use the omitted-ID current-simulation default. The likely next tool is simulation.step again (to keep observing) or simulation.inject_traffic (to change load first). Responses are compact by default: principal metrics plus per-resource status (id, name, status, cpuPercent, routedRps, availabilityState, isRoutable, and recoveryBlockedReason when provided) and this step's events. Compact responses also include errorBreakdown when the engine provides it. A critical resource with isRoutable: true is degraded but still serving; availabilityState: unavailable and isRoutable: false identify a failed or parked node. Pass responseMode: 'full' to get the complete simulation state instead. During recovery, each resource may include recoveryProgress with state parked, cooling_down, or healthy, plus parkWindow and cooldown counters. Poll simulation.step or simulation.get and stop when the targeted resource's recoveryProgress.state is healthy. GPU / inference workflow: when the simulation includes a kubernetes resource with characteristics.inferenceMode: true, each step response also includes gpuUtilization (%), tokensPerSecond, costPerMillionTokens (USD/M tokens), idleGpuCostPerHour (USD/hr of standby GPU spend), and idleGpuFraction (0-1 idle HA overhead share) so you can track inference economics step by step. Authenticate with an API key for unlimited steps and GPU right-sizing hints.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`responseMode`	No	Response detail level. 'compact' (default) returns only principal metrics, errorBreakdown when available, per-resource status (id, name, status, cpuPercent, routedRps, availabilityState, isRoutable, and recoveryBlockedReason when provided), and this step's events — keeps observations small for agent loops. 'full' returns the complete backend step response including the entire simulation object with all resource characteristics and connections.	compact
`simulationId`	No	Simulation ID returned by simulation.create. Preserve Mcp-Session-Id to omit this field and use the session's current simulation; if your connector starts a fresh MCP session for each call (for example Grok Bot or Cursor), pass this explicit ID after every fresh initialization. A fresh session has no current-simulation pointer and returns NO_ACTIVE_SIMULATION when the ID is omitted. Anonymous capabilities are short-lived (30 minutes by default), unguessable, and revoked when the demo expires or is deleted; proxy IP changes do not invalidate them. Do not treat the ID as a durable share link.

Output Schema

TableJSON Schema

Name	Required	Description
`events`	No	Events generated during this step
`traffic`	No	Current traffic level in RPS
`errorRate`	No	Error rate (%)
`resources`	No	Per-resource status summary (compact mode)
`latencyP50`	No	50th-percentile latency in ms
`latencyP95`	No	95th-percentile latency in ms
`throughput`	No	Effective requests per second
`costPerHour`	No	Estimated cost in USD/hr
`currentStep`	No	New simulation time step index
`simulationId`	No	ID of the stepped simulation
`errorBreakdown`	No	Validated additive error contributors in percentage-point units; separates pool/DB, compute, capacity, CPU, storage, runtime-memory, and queue absorption effects
`gpuUtilization`	No	GPU utilization (%) — present only on simulations with a GPU inference kubernetes resource
`idleGpuFraction`	No	Share (0-1) of the GPU bill that is idle/standby capacity — present only on GPU inference simulations; values above 0.5 mean over half the GPU spend is HA overhead
`tokensPerSecond`	No	Inference throughput in tokens/second — present only on GPU inference simulations
`idleGpuCostPerHour`	No	USD/hr of GPU spend funding idle/standby capacity (HA overhead) — present only on GPU inference simulations
`costPerMillionTokens`	No	Self-hosted inference cost in USD per million tokens (null when no tokens are being processed) — present only on GPU inference simulations
`resilienceDiagnostics`	No	Bounded resilience diagnostics summary (compact mode). Absent when the resilience model did not run. Use simulation.compare_resilience for full per-path detail.
`retryAmplificationFactor`	No	Retry amplification factor for this step (attemptedRps / originalRps). Values > 1.0 = amplification risk. null = model ran but no traffic. Absent = resilience model disabled.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only report non-read-only, non-idempotent, and non-destructive hints. The description adds rich behavioral context beyond those: state advancement, the max 20 persisted steps, session-current-simulation semantics, NO_ACTIVE_SIMULATION behavior, short-lived anonymous capabilities, API-key requirements for unlimited steps, and detailed response-shape semantics for recovery and GPU tracking.

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?

The description is long, but the tool is genuinely complex with response-shape special cases, session behavior, recovery logic, and GPU inference context. It is front-loaded with the core purpose and then structured into useful blocks, so the length is mostly justified, though some parameter details overlap with the schema.

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?

The description covers purpose, timing relative to sibling tools, state semantics, response modes, recovery stop conditions, GPU/inference metrics, authentication, and session default behavior. Given the tool's complexity and the presence of an output schema, the definition is complete enough for an agent to invoke it correctly in a wide range of scenarios.

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 description coverage is 100%, and the schema already fully documents both simulationId and responseMode, including the fresh-session behavior and NO_ACTIVE_SIMULATION case. The tool description echoes this information but does not add meaningful new parameter-level semantics beyond what the schema already provides, 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?

The description states a specific verb ('Advance'), a specific resource ('a temporary anonymous demo simulation'), and a specific result ('return updated metrics'). It also explicitly distinguishes this tool from simulation.metrics, which reads state without advancing time, so an agent can select it correctly among the sibling tools.

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?

The description gives clear when-to-use guidance: 'typically right after simulation.create or simulation.inject_traffic.' It also states an explicit exclusion: 'Do not use it to read current state without advancing time — that is simulation.metrics,' and names the likely next tools, including simulation.step again and simulation.inject_traffic.

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 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.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

Need Help?