Cloud World Model

Permanently delete an owned temporary anonymous demo simulation and its metrics, events, failures, and capability. This is the explicit way to free a simulation slot; deletion is irreversible, while the existing demo TTL remains the safety net for abandoned simulations. Prerequisite: a simulationId from simulation.create, or an active simulation in the preserved MCP session. The likely next tool is simulation.create to use the freed slot. A successful response is { deleted: true, id }; failed ownership checks do not delete or revoke anything. Authenticate with an API key to unlock all 64 tools and persistent simulation management.

Fail one compute/Kubernetes node, database, or cache in a temporary anonymous demo simulation (marked critical, not removed). Targeted database quick failures are bounded and reversible; with no serving database at positive load, simulation.step reports 100% errors, zero goodput and errorBreakdown.dbFailure: 100. simulation.recover_resource can restore a database or cache early. An AWS Aurora writer with characteristics.auroraStandbyResourceId pointing to a healthy related replicaOf database has an opt-in modeled failover: the first step is unavailable, the second shows the standby serving without a residual writer-outage penalty. MultiAz or an unrelated second database alone does not establish a standby. Read metrics.databases[].auroraFailover and the promotion event for the failed and standby IDs and success, plus errorRate and throughput. Each quick step is one modeled simulation second, so second-step promotion is one second after injection. Chaos database_crash samples every 10 seconds and defaults to a 30-second promotion and a 1800-second sole-writer restart after its injection duration; compare matching phases, not equal step indices or wall-clock times. These are deterministic assumptions, not observed AWS behavior. No API key required for this temporary anonymous demo operation. Exact targeting: pass resourceName (human-readable name, e.g. 'app-server-01'; exact match preferred, an unambiguous prefix is accepted) or resourceId to fail a specific resource — including an individual named instance, not only a group. If resourceName matches multiple resources the call fails with a 400 listing every matching candidate by name — retry with one exact name (or its resourceId) from that list. The database or cache must be healthy; an already failed database or cache returns a 400 describing its current status. When neither parameter is supplied, a RANDOM healthy compute/Kubernetes node is selected (not a database) — this path is non-deterministic and NOT suitable for controlled scenarios or replay; always target by name/id when reproducing a precise fault sequence. The response always echoes the applied outcome via resolvedResourceId, resolvedResourceName, and previousHealth (populated from the selected resource on the random path too). Network, storage, queue, and security resource types are not supported by quick injection. Cache failures are supported and recoverable with simulation.recover_resource. For typed database_overload use authenticated failure.create (unavailable anonymously); instance_kill PERMANENTLY removes the instance — failure.delete does not restore it; use instance_down instead for a reversible single-node outage. Returns the updated resource list and the failure event that was logged. The likely next tool is simulation.step to observe how the architecture degrades under failure, then simulation.metrics to review the health impact. Do not use it to advance simulation time — that is simulation.step. Pass simulationId from simulation.create when this call is made from a fresh MCP session; otherwise you may omit it to target the current simulation in the preserved MCP session. Authenticate with an API key to unlock all 64 tools including typed durational failures and chaos engineering.

Recover one reversible failed resource in a temporary anonymous demo simulation. No API key required for this temporary anonymous demo operation. Lower traffic to a serviceable level first, then provide resourceId or resourceName from simulation.create, simulation.step, or simulation.metrics. This deactivates applicable instance_down/database_overload failures for only the selected resource and returns recoveryProgress with parked, cooling_down, or healthy state plus cooldown counters. It cannot restore an instance_kill because that failure permanently removes the resource. The likely next tool is simulation.step; keep stepping and inspect the targeted resource until recoveryProgress.state is healthy. Pass simulationId from simulation.create when using a fresh MCP session; a preserved session may omit it. Authenticate with an API key to unlock all 64 tools and unlimited simulations.

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). No API key required for this temporary anonymous demo operation. 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`. When copying a scenario graph that returns `autoscalingConfig`, pass that config to `simulation.create` too so its thresholds and cooldown are preserved. For AWS Multi-Region Failover, scenarioOverrides.awsMultiRegionFailover accepts includeRecoveryRamp (defaults true when the override is supplied), recoveryRampStartStep (absolute integer 40–100000, default 60), and dnsTtlSeconds (positive, at most 86400, default 60). Without an override the recovery ramp is inactive. Select overrides before the first simulation.step. scenario.get exposes characteristics.route53Failover: west fails at evaluation currentTime 5 after creation warm-up through 59, returns at 60; 10 simulated seconds per step, 10-second probes and three consecutive failures/recoveries. The ramp reaches 2600 RPS at step 40 and holds until recovery. For SQS Queue Backlog Saturation, set `scenarioOverrides: { sqsQueueBacklogSaturation: { includeEventBurst: true, eventBurstStartStep: 10 } }` to enable the optional 5,000 RPS burst and choose its absolute start step (integer 6–100000, after the five-step creation warm-up). Within this override, includeEventBurst defaults to true, so eventBurstStartStep alone enables the burst; without the override the burst stays inactive. Omit eventBurstStartStep to use catalog default step 6; select this scenario-only override before the first simulation.step so replay identity is unchanged. For the catalog EKS Spot Interruption Migration scenario, you may set `scenarioOverrides: { eksSpotInterruption: { startupSeconds } }` with an integer startupSeconds from 0 through 3600 to test a different readiness deadline without copying the graph; this override requires scenarioId and is mutually exclusive with resources and connections. For the Web App Autoscaling scenario, create with `scenarioId: "web-autoscaling"` and `scenarioOverrides: { webAutoscaling: { includeTrafficRecovery: true } }` to activate the optional Traffic Recovery ramp and observe scale-in. `includeTrafficRecovery` is optional and defaults to false, leaving the phase inactive. Opt in before the first simulation.step because replay identity is finalized when stepping starts. This override also requires scenarioId and is mutually exclusive with resources and connections. For Database Failover, create with `scenarioId: "db-failover"` and `scenarioOverrides: { dbFailover: { includeTrafficRecovery: true } }` to activate its optional Traffic Recovery ramp; it defaults to false. The scheduled primary-overload phase and ramp are shifted by the five-step creation warm-up. Select the override before the first simulation.step because replay identity is finalized when stepping starts. This override requires scenarioId and is mutually exclusive with resources and connections. For the Redis Cache Crash & Recovery scenario, create with `scenarioId: "redis-cache-crash-recovery"` and `scenarioOverrides: { redisCacheCrashRecovery: { cacheableRequestShare: 0.8, cacheHitRate: 0.8 } }` to set the request share sent to Redis and the configured hit rate among those requests (both fractions from 0 to 1; defaults are 0.8). The selected values are per-simulation and appear in normalizedConfig and per-step requestFlow metrics; they do not change the catalog scenario. Redis Cache Crash & Recovery starts at 5,000 RPS by default; an explicit simulation.create traffic value becomes the starting load, and the scenario has no active traffic pattern. Use simulation.inject_traffic to change load after stepping; this remains valid after replay identity finalizes. `scenario.list` returns graph-free cards with bounded active/optional traffic-phase and retry-workload summaries; it is not a source of resource, connection, traffic-pattern, or failure-injection graphs. Scenario traffic and failure presets are not applied automatically. Custom cache path: use a resource with type 'cache', characteristics.serviceFamily 'elasticache', cacheHitRate as a fraction (0.8, not 80) and optional cacheableRequestShare; connect the load balancer to each app server, each app server to the cache and to the database, and the cache to the database; use responseMode 'full' to see metrics.requestFlow. Use resilienceConfig.externalMetrics for deterministic sampled recommendations: no_ready_endpoints is successful zero only when its trigger sets noReadyEndpointsAsZero:true; discovery_error and fetch_error always remain errors. This is not a KEDA/provider actuator and does not change resource counts. 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). For the exact owned typical fit, set appWeight:'typical', location.regionKey:'us-east-2' on all four AWS nodes, one ALB with serviceFamily:'alb' and loadBalancerScheme:'internal', two m5.large compute apps with workload:'crud-typical', appRuntime:'node', appWorkerCount:2, appDbPoolSize:250, one db.r5.large MySQL with workloadDatabaseEngine:'mysql', workloadDatabaseVersion:'8.0', maxConnections:500, ALB→each app→DB connections, minInstances=maxInstances=2, autoscaling:false, traffic 20–300 RPS. Only typical-fit-20, typical-fit-100 and typical… [7989 more characters not shown]

Change traffic on a demo simulation using targetRps, deltaPercent, or explicit random: true. targetRps takes precedence over deltaPercent; random cannot be combined with either. Missing or unknown selectors are rejected, and no random spike is selected implicitly. Absolute targets are capped at 10000 RPS in demo mode. The change affects metrics after the next simulation.step. For Redis Cache Crash & Recovery, the default 5,000 RPS load has no active pattern, so this controlled traffic update also works after replay identity finalizes. Do not use it to read metrics (simulation.metrics) or advance time (simulation.step). 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. Returns the updated simulation with its new traffic level; the likely next tool is 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). Concurrent simulation.step calls on one simulation either serialize as distinct consecutive steps (in the browser Workspace queue) or receive HTTP 409 simulation_step_in_progress without advancing or consuming a demo credit. Wait for the running call to finish, then retry only rejected calls; distinct simulations can run concurrently. After a timeout, inspect simulation.metrics before retrying an uncertain result. 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. An optional traffic override is applied when no traffic pattern is active; with an active pattern it is rejected with STEP_TRAFFIC_PATTERN_ACTIVE. Use simulation.inject_traffic to change load; it deactivates patterns before replay finalization and uses a runtime-only override for finalized SQS backlog runs, or omit traffic to follow the schedule. 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. Seeded characteristics.eksSpotInterruption telemetry retains its additive migrationEvaluation beside the interruption lifecycle: use its recorded/derived/unavailable field provenance, frozen deadline verdict/counts/reasons, and simulation-clock milestones rather than final service health. The distinct eksSpotMigration contract remains separately reported when configured. Compact responses also include errorBreakdown when the engine provides it. A critical resource with isRoutable: true is degraded but still serving; unavailable identifies a failed or parked node, while scaled_to_zero and cold_start identify Fargate no-task states. 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 until the targeted resource's recoveryProgress.state is healthy, then use simulation.metrics to inspect the resulting state and metrics. 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.

Hydrate one built-in scenario from the live Cloud World Model scenario library. Prerequisite: a scenario id returned by scenario.list. Returns the complete selected scenario graph, including resources and connections plus optional seed, resilienceConfig, protectedResilienceConfig, traffic/failure presets, named traffic-phase summaries, activeFailurePhases and optionalFailurePhases (type, resource/zone target, severity, step range), retry-workload disclosure, and real-world incident metadata. The response includes both title and name for compatibility; pass resources and connections, and optionally seed/resilienceConfig, to simulation.create when you need to edit or inspect the graph. For the shorter handoff, pass the id as scenarioId instead. For SQS Queue Backlog Saturation, the optional 5,000 RPS event burst is inactive by default and starts at step 6 after the five-step creation warm-up when enabled. simulation.create accepts scenarioOverrides.sqsQueueBacklogSaturation.includeEventBurst and an optional absolute eventBurstStartStep (integer 6–100000); omit the step to retain default step 6, and choose it before simulation.step finalizes replay identity. AWS Multi-Region Failover exposes characteristics.route53Failover: 10 simulated seconds per step, 10-second probes, three failures/recoveries and 60-second DNS TTL. West fails at evaluation currentTime 5 after creation warm-up through 59, returns at 60. Load reaches 2600 RPS at step 40 and holds. simulation.create accepts scenarioOverrides.awsMultiRegionFailover.includeRecoveryRamp (default true when supplied; absent override leaves recovery inactive), recoveryRampStartStep (absolute integer 40–100000, default 60), and dnsTtlSeconds (positive, at most 86400), selected before simulation.step. The likely next tool is simulation.create.

List the built-in demo scenarios as compact catalog cards — stable IDs, title/name, description, difficulty, tags, category, duration, provider summary, resource/connection counts, named active/optional traffic phases, and retry-workload disclosure. Use it as the first call when you want a ready-made architecture instead of designing one; the cards intentionally omit resource, connection, traffic-pattern, and failure-injection graphs. Anonymous discovery includes only scenarios with at most 10 resources so every listed card is demo-creatable. No prerequisites. Optionally narrow discovery with provider, category, and/or difficulty filters; omit them to receive the complete demo-creatable catalog. Pass a returned id as scenarioId to simulation.create for server-side expansion, or pass it to scenario.get when you need to inspect the full graph. Larger scenarios require an authenticated session. Returns named activeFailurePhases and optionalFailurePhases with type, resource/zone target, severity, and step range. No API key required. The likely next tool is scenario.get.

Read the latest metrics and resource states for a temporary anonymous demo simulation: latency, CPU, throughput, error rate, cost per hour, and per-resource health. Use it to inspect current state and metrics history without advancing time; do not use it to move the simulation forward — that is simulation.step. Responses are compact by default: principal current metrics plus explicit modeled goodputRps (a post-step point rate sourced from throughput, with provenance), goodputWindow (recorded only from persisted simulation-clock bounds, otherwise unavailable with provenance; never derive it from retrieval time or currentStep), errorBreakdown when available, per-resource status (id, name, status, cpuPercent, routedRps, availabilityState, isRoutable, and recoveryBlockedReason when provided), seeded EKS Spot checkpoint history and migrationEvaluationComplete/provenance when present, and the last 10 metrics-history entries. Pass responseMode: 'full' to get the complete simulation state, normalizedConfig, and full metrics history instead. During recovery, each resource may include recoveryProgress.state (parked, cooling_down, or healthy) with parkWindow and cooldown counters; poll simulation.step until healthy, then use simulation.metrics to inspect the resulting state and metrics. GPU / inference workflow: when the simulation includes a kubernetes resource with characteristics.inferenceMode: true, the response also includes top-level gpuUtilization (%), tokensPerSecond, costPerMillionTokens (USD/M tokens), idleGpuCostPerHour (USD/hr of standby GPU spend), and idleGpuFraction (0-1 idle HA overhead share) from the latest step, and each history entry carries the same inference fields. 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. A fresh session has no current-simulation pointer. At least one simulation.step is needed for meaningful metrics. Read-only; repeated calls may be subject to demo usage limits. The likely next tool is simulation.step or simulation.inject_traffic.