Cloud World Model

What it can reach

From its install config and its own description; a sandbox run will confirm this later.

Checks on v1.1.0

1. Real tool

   passrules 2026-09-29.1 · 5 hours ago

2. Static scan

   failrules 2026-09-29.1 · 5 hours ago
   • criticalPairs a secret with an instruction to send data.tool:simulation.create.description
   • criticalPairs a secret with an instruction to send data.tool:simulation.step.description

Install

Each app still asks you to confirm. Everything is pinned to the version checked above.

{
  "servers": {
    "cloud-world-model": {
      "type": "http",
      "url": "https://www.cloudworldmodel.ai/mcp"
    }
  }
}

Tools it offers

As the server describes them. This text comes from the publisher and is shown as-is.

• simulation.inject_failure

  Fail one compute/Kubernetes node or database 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 the database 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 must be healthy; an already failed database 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, cache, queue, and security resource types are not supported by quick injection. 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 62 tools including typed durational failures and chaos engineering.