Skip to main content
Glama

Cloud World Model

by ai.cloudworldmodel

Get Simulation Metrics

simulation.metrics
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
responseModeNoResponse 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
simulationIdNoSimulation 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
NameRequiredDescriptionDefault
metricsNoMetrics history — bounded to the last 10 entries in compact mode, full history in full mode
trafficNoCurrent traffic level in RPS
errorRateNoLatest error rate (%)
resourcesNoPer-resource status summary (compact mode)
latencyP50NoLatest 50th-percentile latency in ms
latencyP95NoLatest 95th-percentile latency in ms
simulationNoComplete simulation state (full mode only; absent in compact mode and when status is not_found/access_denied)
throughputNoLatest effective requests per second
costPerHourNoLatest estimated cost in USD/hr
currentStepNoCurrent simulation time step
simulationIdNoID of the queried simulation
errorBreakdownNoValidated additive error contributors from the latest metrics entry, in percentage-point units
gpuUtilizationNoLatest GPU utilization (%) — present only on GPU inference simulations
idleGpuFractionNoLatest share (0-1) of the GPU bill that is idle/standby capacity — present only on GPU inference simulations
tokensPerSecondNoLatest inference throughput in tokens/second — present only on GPU inference simulations
idleGpuCostPerHourNoLatest USD/hr of GPU spend funding idle/standby capacity (HA overhead) — present only on GPU inference simulations
costPerMillionTokensNoLatest self-hosted inference cost in USD per million tokens (null when no tokens are being processed) — present only on GPU inference simulations
metricsHistoryLengthNoTotal number of metrics-history entries (compact mode returns only the last 10)
resilienceDiagnosticsNoBounded resilience diagnostics from the latest step (compact mode). Absent when the resilience model did not run.
retryAmplificationFactorNoLatest retry amplification factor (attemptedRps / originalRps). Values > 1.0 = amplification risk. null = model ran but no traffic. Absent = resilience model disabled.

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Cloud World Model toolsInspect
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