Cloud World Model

Inject Failure

simulation.inject_failure

Fail one node in a temporary anonymous demo simulation (the node is marked critical, not removed). 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. If the resolved resource is not in a faileable state (already critical/warning) the call fails with a 400 describing its current status. When neither parameter is supplied, a RANDOM healthy node is selected — 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). For typed failure injections (authenticated failure.create): instance_kill PERMANENTLY removes the instance — failure.delete does not restore it; use instance_down instead for a reversible single-node outage that is restored when the failure is deactivated or deleted. 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 61 tools including typed durational failures and chaos engineering.

Input Schema

TableJSON Schema

Name	Required	Description
`resourceId`	No	Optional: ID of the resource to fail. Takes precedence over resourceName.
`resourceName`	No	Optional: name of the resource to fail (exact match preferred; unambiguous prefix accepted). Ambiguous names return a 400 with a candidate list.
`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
`event`	No	Failure event that was logged
`resources`	No	Updated resource list after failure injection
`previousHealth`	No	The resource's health status immediately before the failure was applied
`resolvedResourceId`	No	ID of the resource that was failed (targeted or randomly selected)
`resolvedResourceName`	No	Name of the resource that was failed

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only indicate a non-read-only, non-destructive mutation. The description adds substantial behavior beyond that: the node is 'marked critical, not removed', ambiguous names return a 400 candidate list, un-faileable states return a 400 status, the no-parameter path is non-deterministic, and instance_kill permanently removes the instance while instance_down does not. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded with the core behavior and logically organized into targeting, error handling, random selection, response, and next steps. Some redundancy exists (response echo vs. returned updated resource list, repeated session guidance) but the density is justified by the non-obvious failure modes and warnings.

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?

Given three optional parameters, a high-consequence failure injection, and session-dependent behavior, the description covers targeting strategies, error scenarios, random fallback, session ID handling, next-step tool suggestions, and reversibility. The output schema covers return values, so the description need not detail them further.

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 coverage is 100%, so the baseline is 3. The description adds value by explaining that omitting both resourceName and resourceId selects a random healthy node (non-deterministic), that resourceName can address an individual named instance rather than only a group, and that simulationId is only needed when the session is fresh. These interaction semantics go beyond the individual parameter descriptions.

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 opens with 'Fail one node in a temporary anonymous demo simulation' and immediately clarifies the semantic difference from deletion ('marked critical, not removed'). It also distinguishes itself from siblings by noting it should not be used to advance simulation time, which is simulation.step.

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?

Provides explicit when-to-use and when-not-to-use guidance: warns that the random path is 'NOT suitable for controlled scenarios or replay', instructs to 'always target by name/id when reproducing a precise fault sequence', and names simulation.step and simulation.metrics as likely next tools. It also contrasts reversible instance_down with permanent instance_kill, giving a clear alternative.

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?