Simulate, test, and analyze cloud architectures without deploying real infrastructure. Cloud World Model enables AI agents to model cloud environments, evaluate architecture behavior and costs, run failure and chaos simulations, and explore infrastructure scenarios across cloud providers.
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, 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. The likely next tool is simulation.create.
| Name | Required | Description | Default |
|---|---|---|---|
| scenarioId | Yes | Scenario identifier returned by scenario.list |
| Name | Required | Description |
|---|---|---|
| id | No | Stable scenario identifier |
| name | No | Scenario display name; equivalent to title |
| seed | No | |
| tags | No | |
| title | No | Scenario title |
| status | No | Result status; not_found when the requested scenario does not exist |
| message | No | Error or guidance message |
| category | No | |
| duration | No | |
| resources | No | Full resource graph; pass to simulation.create |
| difficulty | No | |
| connections | No | Full connection graph; pass to simulation.create |
| description | No | |
| resilienceConfig | No | |
| realWorldIncident | No | |
| defaultTrafficPatterns | No | |
| defaultFailureInjections | No | |
| protectedResilienceConfig | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral detail: it returns the complete scenario graph including resources, connections, optional seed/resilienceConfig, presets, and incident metadata. It also discloses compatibility behavior ('both title and name') and how to hand off to simulation.create. This goes well beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it states the purpose, prerequisite, return contents, compatibility nuance, handoff usage, and next step. It is front-loaded with the core action and structured so an agent can quickly extract the essential call context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, existing annotations, and rich output schema, the description covers everything an agent needs for correct invocation: where the id comes from, what the response contains, how to use the result, and what to do next. There are no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents scenarioId with 100% coverage, so the baseline is 3. The description adds meaningful context by tying the parameter to scenario.list's output and explaining the alternative handoff mode via scenarioId. This is a clear value-add over the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Hydrate'), resource ('one built-in scenario'), and source ('live Cloud World Model scenario library'), and clearly distinguishes the tool from scenario.list and simulation.create by describing the handoff. An agent can tell exactly what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite (scenario id from scenario.list), explains the next likely step (simulation.create), and gives two usage modes — passing resources/connections for editing, or passing scenarioId for a shorter handoff. This is clear, actionable guidance for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in demo scenarios as compact catalog cards — stable IDs, title/name, description, difficulty, tags, category, duration, provider summary, and resource/connection counts. 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. The likely next tool is scenario.get.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only scenarios in this category, such as scaling, failure, reliability, networking, or cost | |
| provider | No | Only scenarios that include resources from this cloud provider | |
| difficulty | No | Only scenarios at this difficulty level |
| Name | Required | Description |
|---|---|---|
| scenarios | Yes | Available demo scenarios |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond those annotations: the catalog-card form, intentional omission of graph details, the 10-resource limit for anonymous discovery, the authenticated-session requirement for larger scenarios, and the explicit 'No prerequisites' note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: core action, response contents, usage context, anonymous limitations, filter behavior, and follow-up tools. It is front-loaded with the most important information and contains no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with a full output schema and read-only annotations, the description covers the essential operational facets: card content, anonymous vs authenticated behavior, optional filters, resource cap, and next tools. The only minor gap is that it doesn't spell out the exact error/omission behavior when an unauthenticated caller might target a larger scenario, though this is implied by the anonymous-discovery cap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are already fully documented in the schema with descriptions and two enums, so the baseline is adequate. The description adds the key semantic of optionality—'omit them to receive the complete demo-creatable catalog'—and names the three filters, reinforcing their role without duplicating schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('List') and resource ('built-in demo scenarios') and enumerates the response fields (IDs, title, description, difficulty, tags, category, duration, provider summary, resource/connection counts). It explicitly contrasts with scenario.get (full graph) and simulation.create (server-side expansion), making sibling differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use it as the first call when you want a ready-made architecture instead of designing one' and provides routing to siblings: pass a returned id to simulation.create or scenario.get when the full graph is needed. It also names the likely next tool, scenario.get, which gives the agent a clear decision path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable name for the simulation | |
| seed | No | Deterministic RNG seed for reproducible replays | |
| traffic | No | Initial traffic in requests per second (RPS) | |
| resources | No | List 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) | |
| scenarioId | No | Live scenario identifier from scenario.list; mutually exclusive with resources and connections | |
| connections | No | Directed 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. | |
| description | No | Optional description of the simulation's purpose | |
| maxInstances | No | Hard 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. | |
| minInstances | No | Floor on the autoscaled compute fleet size, stored as autoscalingConfig.minInstances. | |
| responseMode | No | Response 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 |
| resilienceConfig | No | Optional retry/cascade resilience model returned by scenario.get | |
| scaleOutCpuPercent | No | Grok-compatible alias for the CPU HPA scale-out target; if multiple target names are sent they must match. | |
| autoscalingTargetCpu | No | Canonical CPU HPA scale-out target percent. CWM synthesizes unrelated autoscaling defaults. | |
| scaleOutCpuThreshold | No | Equivalent alias for autoscalingTargetCpu; if both are sent they must match. | |
| autoscaleTargetCpuPercent | No | Grok-compatible alias for the CPU HPA scale-out target; if multiple target names are sent they must match. |
| Name | Required | Description |
|---|---|---|
| id | No | Unique simulation ID — use with simulation.step, simulation.metrics, etc. |
| name | No | Simulation name |
| status | No | Current simulation status |
| traffic | No | Current traffic in RPS |
| hpaAudit | No | CPU HPA create-time audit: whether a target arrived, its accepted field, the persisted thresholds, and the provider-default explanation when omitted. |
| resources | No | Per-resource summary (compact mode) or full resource states (full mode) |
| normalizedConfig | No | Engine-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. |
| effectiveMaxInstances | No | The fleet-size ceiling the engine will enforce (autoscalingConfig.maxInstances, or the provider default when unset) |
| effectiveMinInstances | No | The fleet-size floor the engine will enforce (autoscalingConfig.minInstances, or the provider default when unset) |
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.
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.
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.
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.
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.
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.
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 61 tools and persistent simulation management.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| id | No | ID of the deleted simulation |
| deleted | No | True when the simulation was deleted |
| simulationId | No | ID used for the deletion |
| simulationIdSource | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond them: deletion is irreversible, it cascades to metrics, events, failures, and capability, failed ownership checks 'do not delete or revoke anything' (a benign failure mode), and there are session dependencies. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, and each substantive sentence earns its place: irreversibility, TTL contrast, prerequisites, failure behavior, and the next-step recommendation are all functional. The closing sentence about authenticating with an API key and 'unlock all 61 tools' is mildly promotional, which keeps this from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, a rich input schema, and an output schema, the description covers the full decision space: what gets destroyed, irreversibility, prerequisites, session modes, ownership-failure semantics, and the freed-slot workflow. An agent has everything needed to call it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the simulationId parameter description is already exhaustive, covering session preservation, fresh-session NO_ACTIVE_SIMULATION errors, anonymous capability TTL, proxy IP behavior, and the do-not-treat-as-share-link warning. The tool description adds only the prerequisite framing, so the schema rightfully carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence specifies a precise verb and resource: 'Permanently delete an owned temporary anonymous demo simulation and its metrics, events, failures, and capability.' It states both the action and the full scope of what is deleted, which cleanly separates it from sibling tools like simulation.create, simulation.step, and simulation.metrics. The 'explicit way to free a simulation slot' framing further anchors its role in the lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to use this tool ('the explicit way to free a simulation slot'), contrasts it with the demo TTL as the safety net for abandoned simulations, and states the prerequisites (a simulationId from simulation.create, or an active simulation in the preserved session). It also names the likely follow-up tool, simulation.create, though the when-not-to-use guidance is implicit rather than an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
Change the traffic load on a demo simulation. Omit traffic to trigger a random 2×–5× spike (sends random: true internally); provide traffic to set an absolute RPS level (capped at 10000 RPS in demo mode). Use it to stress-test the architecture before stepping; the change only affects metrics after the next simulation.step. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| traffic | No | Absolute traffic level in RPS to set. Omit to trigger a random spike instead. Server-capped at 10000 RPS in demo mode. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| id | No | Simulation ID |
| status | No | Updated simulation status |
| traffic | No | New traffic level in RPS after injection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since all annotations are false (not read-only, not idempotent, not destructive), the description carries the full burden of behavioral disclosure—and it succeeds. It reveals that omitting traffic causes a random 2×–5× spike, that RPS is capped at 10000, that changes only affect metrics after simulation.step, and that the tool can return NO_ACTIVE_SIMULATION without a valid session. There is no contradiction with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core operation and every clause carries decision-relevant information. It is slightly dense, especially the final session/security caveats, which could benefit from bulletizing, but overall it is efficiently structured and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with an output schema, no required parameters, and false annotations, the description covers invocation variants, side effects, error cases, and the likely next step. An agent has everything it needs to select and call the tool correctly without consulting external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; however, the description adds substantial meaning beyond the schema. It explains when to omit traffic, the internal random flag, when to pass simulationId for fresh sessions, the current-simulation default, the NO_ACTIVE_SIMULATION error, and why the ID is not a durable share link. This far exceeds the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Change the traffic load') and immediately states the tool's demo-simulation context. It then explicitly says what not to use it for, naming simulation.metrics and simulation.step, which clearly differentiates it from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('use it to stress-test the architecture before stepping') and names the alternative tools for reading metrics and advancing time. It also tells the agent what to do next (simulation.step) and how to handle the session-sensitive simulationId, leaving no ambiguity about correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, errorBreakdown when available, per-resource status (id, name, status, cpuPercent, routedRps, availabilityState, isRoutable, and recoveryBlockedReason when provided), and the last 10 metrics-history entries. Pass responseMode: 'full' to get the complete simulation object 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.metrics or simulation.get until healthy. 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 and free to repeat. The likely next tool is simulation.step or simulation.inject_traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| responseMode | No | Response detail level. 'compact' (default) returns principal current metrics, errorBreakdown when available, per-resource status (id, name, status, cpuPercent, routedRps, availabilityState, isRoutable, and recoveryBlockedReason when provided), and only the last 10 metrics-history entries — keeps polling cheap for agent loops. 'full' returns the complete simulation object (all resource characteristics and connections) plus the entire metrics history. | 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. |
| Name | Required | Description |
|---|---|---|
| metrics | No | Metrics history — bounded to the last 10 entries in compact mode, full history in full mode |
| traffic | No | Current traffic level in RPS |
| errorRate | No | Latest error rate (%) |
| resources | No | Per-resource status summary (compact mode) |
| latencyP50 | No | Latest 50th-percentile latency in ms |
| latencyP95 | No | Latest 95th-percentile latency in ms |
| simulation | No | Complete simulation state (full mode only; absent in compact mode and when status is not_found/access_denied) |
| throughput | No | Latest effective requests per second |
| costPerHour | No | Latest estimated cost in USD/hr |
| currentStep | No | Current simulation time step |
| simulationId | No | ID of the queried simulation |
| errorBreakdown | No | Validated additive error contributors from the latest metrics entry, in percentage-point units |
| gpuUtilization | No | Latest GPU utilization (%) — present only on GPU inference simulations |
| idleGpuFraction | No | Latest share (0-1) of the GPU bill that is idle/standby capacity — present only on GPU inference simulations |
| tokensPerSecond | No | Latest inference throughput in tokens/second — present only on GPU inference simulations |
| idleGpuCostPerHour | No | Latest USD/hr of GPU spend funding idle/standby capacity (HA overhead) — present only on GPU inference simulations |
| costPerMillionTokens | No | Latest self-hosted inference cost in USD per million tokens (null when no tokens are being processed) — present only on GPU inference simulations |
| metricsHistoryLength | No | Total number of metrics-history entries (compact mode returns only the last 10) |
| resilienceDiagnostics | No | Bounded resilience diagnostics from the latest step (compact mode). Absent when the resilience model did not run. |
| retryAmplificationFactor | No | Latest retry amplification factor (attemptedRps / originalRps). Values > 1.0 = amplification risk. null = model ran but no traffic. Absent = resilience model disabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by revealing behavior such as compact-by-default responses, the last-10-history-entry limit, NO_ACTIVE_SIMULATION behavior on fresh sessions, 30-minute anonymous capability lifetime, recovery progress fields, and GPU/inference-specific response additions. It also explicitly labels the operation as read-only and free to repeat, complementing the idempotentHint and readOnlyHint annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but information-dense and well-organized: it leads with the core purpose, then covers usage boundaries, response modes, recovery behavior, GPU special cases, session handling, and next steps. It earns its length for a complex tool, though a few statements are repeated from the parameter schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema presence, and detailed annotations, the description covers everything an agent needs to call the tool correctly: prerequisites, session handling, response modes, recovery polling, GPU inference fields, and next-tool routing. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already have detailed descriptions, so the baseline is 3. The tool description adds meaningful context beyond the schema by explaining the default compact behavior, the omitted-ID current-simulation default, fresh-session consequences, and the full response mode use case, which justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Read') and resource ('latest metrics and resource states') for a temporary anonymous demo simulation, and explicitly distinguishes itself from simulation.step by noting it should not be used to move the simulation forward. This makes it unambiguously different from 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('inspect current state and metrics history without advancing time'), what not to use it for ('do not use it to move the simulation forward'), and names the alternative (simulation.step). It also gives practical guidance on session handling, polling during recovery, and identifies the likely next tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recover one reversible failed resource in a temporary anonymous demo simulation. 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 61 tools and unlimited simulations.
| Name | Required | Description | Default |
|---|---|---|---|
| resourceId | No | ID of the failed resource to recover | |
| resourceName | No | Exact case-insensitive name of the failed resource to recover | |
| 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. |
| Name | Required | Description |
|---|---|---|
| simulationId | No | |
| recoveryState | No | |
| previousHealth | No | |
| stepsToHealthy | No | |
| recoveryProgress | No | |
| resolvedResourceId | No | |
| simulationIdSource | No | |
| resolvedResourceName | No | |
| deactivatedFailureIds | No | |
| stepsToHealthyIsLowerBound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry only four boolean hints, so the description carries the burden — and it delivers. It discloses that recovery is partial (selected resource only, applicable instance_down/database_overload failures only), stateful across steps (parked/cooling_down/healthy progression), and permanent-failure behavior (instance_kill removes the resource irreversibly). It also discloses session-dependent behavior (fresh sessions need explicit simulationId or get NO_ACTIVE_SIMULATION) and the 30-minute anonymous TTL. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized: scope first, then preconditions, then behavior and limits, then next-step guidance, then session handling. Every sentence except the final authentication pitch carries operational weight; the auth sentence is borderline promotional but does convey anonymous-mode limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a stateful recovery tool: preconditions, parameter provenance, partial-effect behavior, the permanent-failure exclusion, follow-up workflow, session semantics, and the NO_ACTIVE_SIMULATION error case are all covered. With an output schema present, the recoveryProgress return details do not need to be spelled out further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a solid description, so baseline is 3. The description adds value by clarifying that resourceId and resourceName are alternative selectors ('provide resourceId or resourceName') and by telling the agent exactly where to source them from (create/step/metrics outputs). This exceeds the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb (recover), a precise scope (one reversible failed resource), and the environment (temporary anonymous demo simulation). It clearly differentiates from siblings: the opposite operation is simulation.inject_failure, and the explicit instance_kill exclusion further pins down what this tool does and does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition and ordering ('Lower traffic to a serviceable level first'), tells the agent where to obtain parameter values (resourceId/resourceName from simulation.create, simulation.step, or simulation.metrics), and routes the follow-up action ('The likely next tool is simulation.step'). It also states a when-not case: instance_kill cannot be recovered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
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.
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.
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.
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.