Skip to main content
Glama
Sign In

Loadster

by com.loadster
OverviewDiscussionsAdmin

Update Scenario

update_scenario
Destructive

Update an existing scenario. Each of name, populations, and tags is optional: a field left out keeps its stored value. Populations sent replace the whole list, never merging into it, so to change one, send the others alongside it, each with the id get_scenario reported, or they are dropped and the ones you send are new populations. The same save rules and summary as create_scenario apply.

Input Schema

NameRequiredDescriptionDefault
nameNoThe new scenario name. Leave it out to keep the current name.
tagsNoTag names; a name the team doesn't have yet becomes a new tag. Omit to keep the current tags; send [] to clear them.
projectIdYes
scenarioIdYes
populationsNoThe Populations, in order. Each needs a name, the scriptId of a script in this project, and stages — { target, duration, ramp } segments that run for duration milliseconds and reach target bots by the end, each starting from where the previous stage left off. Optional per population: id (send back the id get_scenario reported to keep a population's identity), engineId (an id from list_engines; defaults to the account's default region; loadEngineId is its deprecated alias), iterations, iterationsPerUser, aggressionMultiplier, and playbackOptions with connectionBps (bits per second), hostnameOverrides, and variableOverrides. Read get_documentation topic 'load-test-scenarios' for what stages and ramps do; list_engines carries the account's stage bounds and bot caps.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / name / description
      Previous value: -"The new scenario name."New value: +"The new scenario name. Leave it out to keep the current name."
    • changedInput schema / properties / populations / description
      Previous value: -"The Populations, in order. Each needs a name, the scriptId of a script in this project, and stages — { target, duration, ramp } segments that run for duration milliseconds and reach target bots by the end, each starting from where the previous stage left off. Optional per population: id (send back the id get_scenario reported to keep a population's identity), loadEngineId (an id from list_engines; defaults to the account's default region), iterations, iterationsPerUser, aggressionMultiplier, and playbackOptions with connectionBps (bits per second), hostnameOverrides, and variableOverrides. Read get_documentation topic 'load-test-scenarios' for what stages and ramps do; list_engines carries the account's stage bounds and bot caps."New value: +"The Populations, in order. Each needs a name, the scriptId of a script in this project, and stages — { target, duration, ramp } segments that run for duration milliseconds and reach target bots by the end, each starting from where the previous stage left off. Optional per population: id (send back the id get_scenario reported to keep a population's identity), engineId (an id from list_engines; defaults to the account's default region; loadEngineId is its deprecated alias), iterations, iterationsPerUser, aggressionMultiplier, and playbackOptions with connectionBps (bits per second), hostnameOverrides, and variableOverrides. Read get_documentation topic 'load-test-scenarios' for what stages and ramps do; list_engines carries the account's stage bounds and bot caps."
    • addedInput schema / properties / populations / items / properties / engineId
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "projectId",
-  "scenarioId",
-  "name",
-  "populations"
-]New value: +[
+  "projectId",
+  "scenarioId"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / tags
      Added value: +{
+  "description": "Tag names; a name the team doesn't have yet becomes a new tag. Omit to keep the current tags; send [] to clear them.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description earns credit beyond that by spelling out the exact destructive mechanic: populations replace the whole list, never merge, and unsent ones are dropped. It also points to create_scenario's save rules and summary so the agent knows validation behavior carries over.

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?

Front-loaded with the core statement, then progressively deeper semantics. The middle sentence about populations is long and clause-stacked ('each with the id get_scenario reported, or they are dropped...') but every clause carries distinct information, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the destructive replace-list trap, id preservation, and delegates return/summary behavior to create_scenario. For a 5-parameter destructive mutation with no output schema, the main risk an agent faces is dropping populations, and that is addressed; permissions and failure modes are not.

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?

With 60% schema coverage, the description adds genuine meaning: fields are optional-keep, populations are replace-not-merge, and id must be the value get_scenario reported to preserve identity. The schema itself already documents tags and population internals richly, so the description complements rather than duplicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Update an existing scenario') and the rest distinguishes it from create_scenario by referencing shared save rules. It is clearly an update tool, though it never explicitly contrasts with delete_scenario or duplicate-like siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage context: omitted fields keep stored values, and to change a single population you must resend the others with ids obtained from get_scenario. That is a real workflow rule the agent would otherwise get wrong. No explicit when-not-to-use guidance exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Loadster toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources