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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 7 of 7 tools scored. Lowest: 4/5.
Each tool has a distinct purpose: scenario.list discovers templates, simulation.create sets up a simulation, inject_failure and inject_traffic modify specific aspects, metrics reads state, and step advances time. There is no overlap or ambiguity between them.
The simulation.* tools share a clear prefix, but the conventions are mixed: some use verbs (create, inject_failure), others nouns (metrics, step), and get_more_tools uses an underscore while scenario.list uses a dot. This is readable but not fully consistent.
Seven tools is a well-scoped number for a demo simulation server, covering scenario listing, creation, failure/traffic injection, stepping, and metrics. Each tool earns its place without being excessive or sparse.
The toolset covers the core simulation workflow: list scenarios, create, inject failures/traffic, step, and read metrics. It lacks an explicit delete/teardown tool, but demo simulations are designed to auto-clean, so this is a minor gap rather than a critical failure.
get_more_toolsACheck for additional tools whenever your task might benefit from specialized capabilities - even if existing tools could work as a fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | A description of your goal and what kind of tool would help accomplish it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds no mechanical details about what calling the tool returns or how it behaves beyond 'check', but it does not contradict 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?
One sentence, front-loaded with the action, and contains no filler. It states the purpose and usage guidance efficiently.
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 simple one-parameter tool with rich annotations, the description is adequate. It gives a clear usage directive, though the lack of any mention of the response shape is a minor gap given there is no output schema.
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 input schema provides a clear description for the single 'context' parameter at 100% coverage. The tool description reinforces that the context should describe the task and desired capability but adds no extra parameter-level meaning beyond the schema.
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 that the tool checks for additional tools and ties it to task needs. It is more specific than a mere name repetition, but it does not mention what form the result takes or how it differs from sibling tools beyond being a meta-tool.
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 advises using this tool whenever specialized capabilities might help, even if existing tools could work as a fallback. This gives the agent crisp, actionable guidance on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenario.listList ScenariosAList the built-in demo scenarios — pre-built cloud architectures (resources + connections) with realistic traffic patterns. Use it as the first call of a session when you want a ready-made architecture instead of designing one; skip it if you already know the resources you want to create. No prerequisites, no API key required. Each scenario's resources and connections arrays can be passed directly to simulation.create, which is the likely next tool.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | One-sentence goal for this session — e.g. 'train RL agent on AWS', 'compare GCP vs Azure costs', or 'run chaos test on database tier'. |
| Name | Required | Description |
|---|---|---|
| scenarios | Yes | Available demo scenarios |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe-read nature is covered. The description adds 'No prerequisites, no API key required' and explains that 'resources and connections arrays can be passed directly to simulation.create,' offering integration context beyond 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 three sentences, each serving a distinct purpose: definition, usage guidance, and integration. It is efficient, front-loaded, and contains no filler.
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 tool's simplicity and the presence of an output schema, the description covers all necessary aspects: purpose, usage, prerequisites, and integration with the likely next step. 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 description coverage is 100% with a well-documented 'context' parameter including examples. The description adds no parameter-specific detail, but baseline 3 is appropriate since the schema fully handles parameter semantics.
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 'List the built-in demo scenarios' and elaborates with 'pre-built cloud architectures (resources + connections) with realistic traffic patterns.' This clearly identifies the resource and distinguishes it from sibling simulation 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?
Explicit guidance is given: 'Use it as the first call of a session when you want a ready-made architecture instead of designing one; skip it if you already know the resources you want to create.' It also notes the likely next tool (simulation.create), providing excellent when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulation.createCreate SimulationAInspectCreate a demo cloud simulation from a list of resources and connections (max 2 per session, up to 10 resources; demo simulations are temporary and are cleaned up after roughly 30 minutes or when the session ends). If you don't have an architecture in mind, call scenario.list first — its resources and connections arrays can be passed directly here. Use it to start any simulation workflow — either with resources from scenario.list 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). 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. Responses are compact by default: id, name, status, traffic, and a per-resource summary (id, name, status, cpuPercent). Pass responseMode: 'full' to get the complete simulation object instead. 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 | |
| context | Yes | One-sentence goal for this session — e.g. 'train RL agent on AWS', 'compare GCP vs Azure costs', or 'run chaos test on database tier'. | |
| traffic | No | Initial traffic in requests per second (RPS) | |
| resources | Yes | List of cloud resources to include (max 10 in demo mode) | |
| connections | No | Directed edges describing traffic flow between resources | |
| 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 |
| 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 |
| resources | No | Per-resource summary (compact mode) or full resource states (full mode) |
| 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?
The description discloses critical behavioral traits beyond the sparse annotations (all false): session limits (max 2 per session), resource cap (up to 10), temporary cleanup ('cleaned up after roughly 30 minutes or when the session ends'), provider-specific maxInstances defaults, and the state change to current simulation. 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?
Despite being long, every sentence is information-dense and front-loaded: the first sentence states core behavior and constraints, followed by warnings, defaults, response format, and next-step guidance. There is 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 9-parameter tool with nested resources and an output schema, the description covers creation constraints, parameter semantics, provider defaults, response modes, session state effects, and the intended workflow (scenario.list → create → step). It is fully self-contained and anticipates agent needs.
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?
Although the schema describes all 9 parameters, the description adds essential semantics: capacityRps is 'the literal per-node RPS ceiling at which CPU reaches ~95%', maxThroughput is 'legacy/internal' and should not be used, maxInstances defaults vary by provider (AWS 50, GCP 15, etc.), and responseMode 'compact' vs 'full' behavior is explained. This goes well beyond the schema's 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 and resource: 'Create a demo cloud simulation from a list of resources and connections'. It clearly differentiates from siblings by explicitly stating 'Do not use it to modify an existing simulation (use simulation.inject_traffic to change load)' and referencing scenario.list for architecture.
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 explicit when-to-use guidance: 'Use it to start any simulation workflow — either with resources from scenario.list or your own architecture' and 'If you don't have an architecture in mind, call scenario.list first.' It also names alternatives (simulation.inject_traffic for modifying load) and the likely next tool (simulation.step).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulation.inject_failureInject FailureAInspectFail one node in a demo simulation owned by this session (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. Use simulation.step after injecting 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. simulationId is optional: omit it to target this session's current simulation (the one from simulation.create or the last explicit successful use). Authenticate with an API key to unlock all 56 tools including typed durational failures and chaos engineering.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | One-sentence goal for this session — e.g. 'train RL agent on AWS', 'compare GCP vs Azure costs', or 'run chaos test on database tier'. | |
| 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. Optional in demo sessions — omit to target this session's current simulation (set by simulation.create and updated by the most recent successful explicit use). If the session has no current simulation you get a NO_ACTIVE_SIMULATION result. |
| 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?
Despite annotations being all false (providing minimal safety hints), the description thoroughly discloses behavior: the node is marked critical but not removed, random selection is non-deterministic, ambiguous names cause a 400 with candidate list, and failed states cause a 400. It also details response fields. This far exceeds the minimal burden, especially given the lack of annotation context.
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 and dense, with multiple parentheticals and repetitive response-related statements (e.g., 'The response always echoes...' and 'Returns the updated resource list...'). While well-organized and front-loaded, it is not concise; some sentences could be consolidated or moved to schema descriptions, making it heavier than necessary.
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 tool's complexity, the description is exceptionally complete: it covers purpose, targeting rules, error cases, random behavior, response content, workflow integration with simulation.step and metrics, simulationId semantics, and even clarifies related destructive tool behavior. The presence of an output schema reduces the need to explain return values, but the description covers them anyway, making it fully adequate for agent selection and invocation.
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?
Although schema coverage is 100%, the description adds substantial semantics beyond the schema: exact-match preference, prefix acceptance, ambiguity handling, resourceId precedence, random selection when neither parameter is supplied, and the optional simulationId defaulting to the session's current simulation. These details are not in the schema and are critical for correct usage.
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 the tool's function: 'Fail one node in a demo simulation owned by this session (the node is marked critical, not removed).' It uses a specific verb and resource, and distinguishes itself from siblings like simulation.inject_traffic and simulation.step by explicitly stating it is for failure injection and not time advancement.
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 explicit guidance: use simulation.step after injecting to observe degradation, then simulation.metrics for health impact. It also warns against using this tool to advance time and mentions alternative tools for reversible outages (instance_down) and typed failures (failure.create), giving clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulation.inject_trafficInject TrafficAInspectChange 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). simulationId is optional: omit it to target this session's current simulation (the one from simulation.create or the last explicit successful use). Returns the updated simulation with its new traffic level; the likely next tool is simulation.step.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | One-sentence goal for this session — e.g. 'train RL agent on AWS', 'compare GCP vs Azure costs', or 'run chaos test on database tier'. | |
| 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. Optional in demo sessions — omit to target this session's current simulation (set by simulation.create and updated by the most recent successful explicit use). If the session has no current simulation you get a NO_ACTIVE_SIMULATION result. |
| 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?
Annotations are all false, so the description carries full responsibility. It discloses critical behaviors: random spike via 'sends random: true internally', absolute RPS cap at 10000, that changes only affect metrics after the next simulation.step, and optional simulationId targeting the session's current simulation. It also mentions potential NO_ACTIVE_SIMULATION result. This is rich beyond annotations and contains no contradictions.
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 compact—three sentences—yet packs in purpose, usage guidelines, parameter semantics, side effects, and return value. Every sentence serves a purpose: main behavior, exclusions, parameter nuance, and next-step recommendation. No fluff or redundancy.
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 moderate complexity and an output schema present, the description covers everything needed for correct invocation: exact behavior, parameter semantics, timing of effects, scoping rules, return type, and relationship to sibling tools. It is self-sufficient and leaves no critical gap.
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 baseline is 3, but the description adds significant meaning beyond the schema. For 'traffic' it explains that omission triggers a random spike while a value sets an absolute RPS level. For 'simulationId' it clarifies omission targets the session's current simulation and that it updates with the last explicit use. These details go far beyond the bare 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 description opens with a specific verb and resource: 'Change the traffic load on a demo simulation.' It clearly distinguishes itself from siblings by explicitly warning 'Do not use it to read metrics (simulation.metrics) or advance time (simulation.step).' The purpose is unambiguous and differentiated.
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 states when to use: 'Use it to stress-test the architecture before stepping.' It provides exclusions and alternatives: 'Do not use it to read metrics (simulation.metrics) or advance time (simulation.step).' It even suggests the next likely tool: 'the likely next tool is simulation.step.' This is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulation.metricsGet Simulation MetricsARead the latest metrics and resource states for a demo simulation created in this session: 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, per-resource status (id, name, status, cpuPercent, routedRps), and the last 10 metrics-history entries. Pass responseMode: 'full' to get the complete simulation object and full metrics history instead. simulationId is optional: omit it to read this session's current simulation (the one from simulation.create or the last explicit successful use). 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 |
|---|---|---|---|
| context | Yes | One-sentence goal for this session — e.g. 'train RL agent on AWS', 'compare GCP vs Azure costs', or 'run chaos test on database tier'. | |
| responseMode | No | Response detail level. 'compact' (default) returns principal current metrics, per-resource status (id, name, status, cpuPercent, routedRps), 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. Optional in demo sessions — omit to target this session's current simulation (set by simulation.create and updated by the most recent successful explicit use). If the session has no current simulation you get a NO_ACTIVE_SIMULATION result. |
| 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) |
| 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 |
| metricsHistoryLength | No | Total number of metrics-history entries (compact mode returns only the last 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description reinforces this ('Read-only and free to repeat') without contradicting it. It adds valuable behavioral context beyond annotations: 'At least one simulation.step is needed for meaningful metrics,' and explains session-scoped simulation selection ('omit it to read this session's current simulation'). It also discloses the default response behavior and the 'full' mode, providing a complete picture of tool behavior.
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 a single paragraph with a logical flow: purpose, usage boundaries, response formats, parameter semantics, prerequisite, and next steps. It is longer than minimal but every sentence contributes necessary context—no filler or redundancy. A slight trim could be possible, but overall it is well-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?
Given the tool's complexity (session state, optional parameters, multiple response modes), the description is remarkably complete. It covers the purpose, usage guidance, response details, parameter behavior, prerequisites, and even suggests next tools. Since an output schema exists, it does not need to explain return values. There are no evident gaps in describing how and when to use this tool.
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 input schema already provides detailed descriptions for all three parameters (context, responseMode, simulationId), giving 100% schema coverage. The description adds some useful context, especially the prerequisite 'At least one simulation.step is needed for meaningful metrics,' but largely reiterates schema-provided details about responseMode and simulationId. With such thorough schema coverage, the description adds only marginal value beyond the schema.
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 and resource: 'Read the latest metrics and resource states for a demo simulation created in this session.' It lists concrete metrics (latency, CPU, throughput, error rate, cost per hour, per-resource health) and explicitly differentiates from siblings: 'do not use it to move the simulation forward — that is simulation.step.' This makes the tool's purpose unmistakable.
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 clearly states when to use the tool ('Use it to inspect current state and metrics history without advancing time') and when not to, naming the alternative: 'that is simulation.step.' It also provides context on optional parameters and suggests likely next tools ('The likely next tool is simulation.step or simulation.inject_traffic'), offering practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulation.stepSimulate StepAInspectAdvance a demo simulation by one time step and return updated metrics — CPU, latency, throughput, error rate, cost (max 20 steps per session). 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. simulationId is optional: omit it to step this session's current simulation (the one from simulation.create or the last explicit successful use). 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) and this step's events. Pass responseMode: 'full' to get the complete simulation state instead. Authenticate with an API key for unlimited steps.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | One-sentence goal for this session — e.g. 'train RL agent on AWS', 'compare GCP vs Azure costs', or 'run chaos test on database tier'. | |
| responseMode | No | Response detail level. 'compact' (default) returns only the principal metrics, per-resource status (id, name, status, cpuPercent, routedRps), 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. Optional in demo sessions — omit to target this session's current simulation (set by simulation.create and updated by the most recent successful explicit use). If the session has no current simulation you get a NO_ACTIVE_SIMULATION result. |
| 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) |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no positive hints (all false), so the description carries the full burden. It reveals that the tool mutates simulation state (advances time), has a hard limit of 20 steps per session, requires API key for unlimited steps, handles optional simulationId with a fallback to the session's current simulation, and returns NO_ACTIVE_SIMULATION error when no simulation is active.
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 purpose, then usage, then parameter behavior. Every sentence conveys operational information, but it is slightly verbose—details like listing the full compact response contents and the authentication sentence could be trimmed without losing much value.
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 that an output schema exists, the description needn't enumerate all return fields, but it still summarizes what compact vs full responses contain. It covers when, why, how, edge cases (max steps, no active simulation), and invocation nuances, making it complete for an agent to select and invoke correctly.
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 covers all parameters (100% coverage), but the description adds meaning beyond schema for simulationId (explains optionality, current-simulation fallback, NO_ACTIVE_SIMULATION result) and responseMode (details compact vs full output). The 'context' parameter is left to the schema, which already describes it. Overall, it exceeds the baseline of 3.
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 action ('Advance a demo simulation by one time step') and clearly states the resource ('demo simulation') and outputs ('return updated metrics'). It explicitly distinguishes itself from simulation.metrics, saying 'Do not use it to read current state without advancing time — that is simulation.metrics.'
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 context ('typically right after simulation.create or simulation.inject_traffic'), an explicit exclusion ('Do not use it to read current state without advancing time'), and names the alternative tool (simulation.metrics). It also suggests likely next steps, reinforcing usage flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
